Grain 3D Conformance Grader — App & Skill

Before you run this: what can actually move, and what cannot

The mechanism is real, and you should understand it before pointing it at anything that matters. When Grain settles an order, an autonomous on-chain transaction either releases USDC to the seller (a pass verdict) or refunds the buyer (a fail verdict). In a production deployment on mainnet that would move real value, autonomously, the moment a signed verdict lands. Settlement is one-shot and irreversible — once an order leaves the Funded state it cannot be re-settled or rolled back.

Two rules make this safe to operate, and Grain enforces both in code rather than asking you to trust it:

• Never fabricate. The grader signs a verdict only over the actual sha256 of the GLB it judged and the real predicate results. It never invents a pass, a balance, or a transaction hash. If you reproduce a settlement, read the state on-chain — never assert a value you have not verified.
• Confirm before you go live. Funding an order (fundOrder) is the explicit human/upstream gate: it pulls USDC from the buyer and commits the buyer, seller, and grader write-once. Submitting the verdict afterward is intentionally autonomous (the signed verdict is the gate), so the place to stop and confirm is before you fund a live order, not after.

See it in action: grading a bad crate, then a good crate

Call grade_asset with { assetUri, profileId: "game-ready-prop@1" } (assetUri is a URL or path to the GLB). You get back { pass, results[], predicateDigest, assetHash, verdict }, where results is one row per predicate (each { id, label, pass, actual, expected, evidence }), run in fixed id-sorted order. The profile game-ready-prop@1 runs in mode all — every predicate must pass.

Round 1 — a bad crate (over budget, open seams, no declared param)

A raw fal Rodin export: over the triangle budget, with seams the exporter left open, and — since Rodin emits no editable parameters — missing the parameter the buyer requires. pass: false → the signed verdict is fail → GrainEscrow refunds the buyer.

Round 2 — a good crate (decimated to budget, welded watertight, param attached)

After Grain decimates to budget, welds the mesh watertight, and attaches the declared accent_color parameter, every row flips to pass. pass: true → the signed verdict is pass → GrainEscrow releases payment to the seller.

* id, label and expected are exact; actual values are illustrative of the real evidence shape. Rows render in id-sorted order — that ordering is what makes predicateDigest reproducible.

Optional: the semantic row

If you also pass intent: "a game-ready wooden crate prop", an opt-in fifth predicate semantic_match renders the asset to fixed views, CLIP-scores it against the intent plus distractors, and is folded in as a hard gate — it passes only if the intent is the top match at or above the threshold (default 0.6). It is deterministic on a single pinned grader (cross-grader agreement requires pinning the render + CLIP model versions); the 4-predicate floor stays the disputeless core.

The calibration behind that threshold (default 0.6; max-F1 T ≈ 0.5–0.6) comes from honest-v0, an N=5 benchmark of visually-distinct fal Rodin assets (crate, barrel, vase, helmet, chair) — it proves the method and the deterministic floor, not the hard/confusable cases; a larger, harder set is roadmap.

When an escrowId was supplied, the result also carries verdict: { escrowId, result: "pass", assetHash, escrowAddress: 0xEEb1…78d9, chainId: 84532, graderSignature } — the exact tuple settleOnAttestation consumes (full escrow address in §06). The verdict is decided by deterministic code (and the opt-in CLIP check), never by an LLM guessing; the Grader Mind's Brain only narrates a verdict it did not decide.

Before you start

Grain orchestrates three Minds in one Circle (Requester → Generator → Grader). The platform has no Builder API to set a Mind's DNA, Tenets, or Skills, so setup is part console, part conversation. Everything below runs on testnet — no real money moves.

• A Minds (by Animoca) account. Builder beta at build.hellominds.ai; sign-in is email-based.
• Awaken each Mind via the Concierge. There is no "create Mind" API and no UI form for DNA/Tenets — you "Launch a Mind," the Concierge emails you, and you describe the role in natural language. Awaken three: a Requester, a Generator, and a Grader. Set the role DNA at creation — role-locked Minds work reliably, whereas re-tasking a default "companion" Mind by chat is inconsistent (it tends to defend its identity and refuse).
• Durably seed each role. The sanctioned path is conversational: message the Mind to invoke its own internal TENET_Update tool, framing the Grain role as an added operating tenet (not an identity replacement). Identity-level reframing ("you ARE the Grader") trips a guardrail and is refused.
• Equip the Grain Skill. The deterministic grader publishes as a Bazaar Skill (a multi-step playbook over Tools), distinct from the Mind's DNA. Build it by describing the outcome to the Mind in chat; edit it later via REGISTRY_Update / SKILL_Update. (Publish is in progress in this build.)
• Add Connections for credentials. Secrets — the grader signing key, any API keys — live platform-side in Connections. The Mind never holds the key, and the private acceptance-profile thresholds (the moat) stay out of chat and out of the public repo.
• Put all three Minds in ONE Circle. Circles are UI-only — there is no Circle-management API.
• Fund cognition on every Mind. Each reply spends cognition; a 0-balance Mind silently times out. Known bug: topping up a brand-new Mind immediately after creation can charge without minting credits — fund after the wallet registers, and hard-refresh (the balance isn't real-time).
• A funded buyer key. Holds Base Sepolia test USDC to call fundOrder and escrow an order against GrainEscrow (0xEEb15426d656dCfb76AC058D1A1e66c821cB78d9).
• A gas-paying keeper key. Holds Base Sepolia ETH to submit settleOnAttestation; it has zero fund authority. The Mind's own Base wallet (an EOA) cannot broadcast settlement.
• A chosen acceptance profile. The bundled one is game-ready-prop@1 (≤ 10k triangles, watertight/manifold, valid GLB, a required named param accent_color; plus an optional semantic_match check). The public predicate code is worthless without the private profile thresholds — keep those gitignored.

What Minds can do (and what they can't)

A Mind = Soul + Brain. The Soul holds durable DNA (permanent values, set at awakening), Tenets (editable rules; invariant ones are Guardrails), Memory, State, and a Wallet. The Brain is reasoning, auto-routed across hosted vision-capable models and separate from the Soul — so a Mind keeps its role even when the underlying model changes. Grain adds one thing the platform doesn't have: a deterministic judge.

General Minds capabilities

• Persistent identity + memory — proven live: the Grader Mind, seeded once via TENET_Update, restated its role and acceptance criteria on a later, separate call.
• Natural-language interface — you drive a Mind by messaging it; in Grain this carries the legible "why it was rejected" narration (flavor on top of the deterministic verdict, never the verdict itself).
• Equippable Skills — behavior is a layer separate from DNA: multi-step playbooks over Tools, published to the Bazaar, equippable by other Minds, editable conversationally after publish.
• Autonomous, background operation on a cognition budget — Grain leans on this: settlement releases/refunds on the signed verdict with no human approval.
• Email, Telegram, and Circles — Mind-to-Mind messaging genuinely works (a Generator Mind delivered a unique token to the Grader in a shared Circle, confirmed on the receiver side).

What your Mind can do with Grain

• Grade a delivered GLB against a named profile by calling grade_asset, and get a per-predicate report — tri_count, manifold, valid_glb, named_params — each with the measured actual, the expected threshold, and evidence.
• Re-grade the same GLB + profile anytime and get a byte-identical predicateDigest — reproducible and timestamp-free.
• Optionally add the opt-in semantic_match check by supplying an intent, folding "is this actually the right thing?" into the verdict as a hard gate.
• Sign an EIP-191 verdict bound to an escrow order so GrainEscrow.settleOnAttestation can release (pass) or refund (fail) on-chain — without trusting the counterparty, because the sign-only key can never pay itself.
• What it does NOT yet judge: production-readiness (LODs/UVs/PBR budgets), fidelity-to-reference, provenance/IP, parametric editability, and aesthetic taste — these are roadmap, not built. The same rails take a new predicate set per vertical, but only 3D is proven today.

Step-by-step guide

Six moves mirroring the connect → prompt → preview → approve → execute → monitor pattern, adapted to Grain's request → generate → grade → settle loop.

Base & USDC settlement: how a signed verdict releases money on-chain

Grain's settlement layer is a single verification-gated contract, GrainEscrow, deployed on Base Sepolia (chainId 84532) at 0xEEb15426d656dCfb76AC058D1A1e66c821cB78d9, settling USDC (Circle test USDC 0x036CbD53842c5426634e7929541eC2318f3dCF7e, 6 decimals). The lifecycle is three moves:

1. Fund. The buyer calls fundOrder(escrowId, seller, grader, amount, specHash). This pulls amount USDC in and records the order write-once: buyer = msg.sender, the seller, the grader (the only signer whose verdict counts for this order), and the specHash.
2. Grade + sign. Off-chain, the grader signs the verdict. The signature is EIP-191 personal_sign over the digest below; the runtime reproduces it byte-for-byte, so the off-chain signature is exactly what the contract recovers.
3. Settle. Anyone — in practice a keeper — calls settleOnAttestation(escrowId, result, assetHash, graderSignature). The contract recovers the signer and requires it to equal the order's recorded grader, else it reverts with bad grader sig. On pass it pays seller; on fail it refunds buyer.

digest = keccak256(abi.encode(
  "Grain settleOnAttestation",
  escrowId, uint8(result), assetHash,
  address(this),      // this exact contract
  block.chainid       // this exact chain (84532)
))
// signed EIP-191 personal_sign; recovered signer must == order.grader

• The keeper pays gas and has zero authority. Recipients are fixed on-chain, so it can't redirect funds; the runtime treats a reverted-but-included transaction as a hard failure (it waits for the receipt and throws unless status === 'success').
• The signature can't be replayed. The digest binds the verdict to this order, this result, this exact asset (assetHash), this contract, and this chain — a pass can't be replayed as a fail, asset A's signature can't settle asset B, and another instance or chain is rejected. Each binding has a dedicated test.
• Hardened. ReentrancyGuard + checks-effects-interactions (state committed before transfer) + one-shot (the Status.Funded guard means a settled order can't settle twice).

Mainnet path (roadmap, not built). On mainnet the same contract would point at bridged USDC; no mainnet deployment exists. The settlement layer is written chain-neutral behind a SettlementAdapter seam, but the EVM adapter is the only implementation — a Solana adapter is an explicit TODO.

Operating it: verify on-chain first, keep the audit trail, then revoke and stop

Everything you need to manage a live connection is verifiable on-chain — read first, trust nothing you haven't checked.

Verify status by on-chain reads

Read orders(escrowId) and the status byte: 0 None, 1 Funded, 2 Released, 3 Refunded. To confirm a settlement actually happened, watch the events — OrderReleased and OrderRefunded each carry escrowId, the recipient, the amount, the assetHash, and the settler (the keeper). Don't report a settlement off the keeper's optimism; confirm it landed in state and in an event.

Keep the audit trail

• assetHash — the sha256 of the exact GLB bytes the grader judged, baked into the signed digest and recorded in the event, so any payout is provably tied to one specific artifact.
• predicateDigest — a sha256 over the sorted, timestamp- and evidence-excluded predicate results, so re-grading the same asset later proves you got the same verdict.
• Keep the (escrowId, assetHash, predicateDigest, tx hash) tuple per order — that is your durable record.

Verify the grader, then revoke and stop

The order records the grader address whose signature is the only one honored. The public signer in this deployment is 0xB89e1Aba9c23f8227f29d3727570526e3Dd7C5Ee — the public address; the private key never leaves the grader and is never in source or logs. Because the contract has no owner, pause, or withdraw, you don't "turn off" the escrow — you stop feeding it: stop the keeper (no keeper → no settlement), stop funding new orders, and fund any future order with a rotated grader address. Drain funded orders first — stopping the keeper strands an already-funded order until a valid grader signature settles it. Released/Refunded orders are final. There is no sweep and no admin escape hatch — which is the point: no admin attack surface.

Troubleshooting