# 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](./settlement-desk.md)** — 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](./settlement-desk.md), step 2.)

```json
{
  "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](./doorstep.md)** →