Guided Tours

Tour: Proof & Compute

Two zipcoin-derived capabilities, both Grade A on-chain reads: a trusted-setup artifact pinned by SHA-256 (content-addressed, append-only) and a play-key's metered compute credit drawn down against EIP-712-signed receipts. This tour assumes you've done Settlement Desk — the import, the heading rule, the vocab-sync, and the fail-closed preview all work the same way here, so we focus on what's new.

1. Import

⋯ More → Import JSON → this tree. (Note: headings are text + role:"heading" — see the heading gotcha in Tour 1, step 2.)

{
  "type": "box",
  "direction": "column",
  "children": [
    { "type": "text", "content": "Proof & Compute", "role": "heading" },
    { "type": "text", "content": "Trusted-setup pin", "role": "heading" },
    { "type": "slot", "bind": "proof-setup", "argValues": { "registry": "0x4444444444444444444444444444444444444444", "id": "0x0000000000000000000000000000000000000000000000000000000000000000" } },
    { "type": "text", "content": "Compute credit (play-key)", "role": "heading" },
    { "type": "slot", "bind": "compute-credit", "argValues": { "vault": "0x5555555555555555555555555555555555555555", "playKey": "0x6666666666666666666666666666666666666666", "assetDecimals": "6", "fracDigits": "2" } },
    { "type": "text", "content": "Trust, declared on-chain", "role": "heading" },
    { "type": "slot", "bind": "trust-facets", "argValues": { "subject": "0x5555555555555555555555555555555555555555" } }
  ]
}

2. The trusted-setup pin — what's Grade A, and what isn't

proof-setup reads a SetupPinRegistry: the pin's existence, its pinner, and its URI are on-chain truth — Grade A for the read. What it does not prove is that the pinned digest is the real setup; that rests on the pinner. The teeth are the ≤ C companion artifact-verify: the client fetches the artifact, SHA-256s it, and compares to the pinned digest. ChainRender renders the on-chain pin honestly and names the pinner; it never says "trusted," only "matches the on-chain pin" (or not).

registry — your deployed SetupPinRegistry.
id — the content-addressed pin id, keccak256(abi.encode(sha256, uri)).

To add the ≤ C verification next to it, add an artifact-verify slot with { expectedSha256, uri }. Its grade badge will read ≤ C by construction — that's the honest split, not a downgrade of your app.

3. Compute credit — escrow is on-chain, the compute is not

compute-credit reads a ComputeCreditVault: funded / spent / remaining for a play-key — Grade A. The provider can only draw down against the play-key's EIP-712-signed usage receipts, so it can never overcharge, and the play-key withdraws any unspent balance at any time. The compute being paid for is off-chain (attested, ≤ C) — the card says so. ChainRender renders the credit, never the compute.

vault — your deployed ComputeCreditVault.
playKey — the scoped play-key address whose credit to show.

When you wire the real draw-down, sign receipts with the SDK's usageReceiptTypedData(...) helper so the domain + type match the vault's DOMAIN_SEPARATOR and USAGE_RECEIPT_TYPEHASH exactly.

4. Preview, deploy, grade

Same as Tour 1: with placeholder addresses the slots render "unavailable" (fail-closed); set the Interpreter + RPC in the config bar; then deploy ProofBadgeResolver, ComputeCreditResolver, and TrustDisclosureResolver (ownerless, once per chain) and seed a SetupPinRegistry with a pin and a ComputeCreditVault with a funded play-key. Replace the 0x4444…, 0x5555…, 0x6666… placeholders and preview again — the pin and the credit render live, Grade A.

Next: Doorstep →