Skip to main content
A verdict is only worth as much as your trust in whoever produced it — unless it’s provable. Every Chance verification carries a receipt that anyone can re-check from scratch, trusting no one in the middle. Not “trust our dashboard” — recompute every claim in your own browser.

​
Four stages

1

Run — the flight recorder

As the judge works, every step is appended to an append-only hash chain. Change, delete, or reorder one byte and the final root changes completely. The chain head — the transcript root — commits to the entire decision.
2

Run + Sign — inside the enclave

The whole judge loop — the model call to OpenRouter, the transcript hash chain, and the signature — runs inside a hardware-isolated SEV-SNP enclave (a TEE). The judge key is released to the enclave and never leaves it; the signed digest binds the run, its transcript root, its output, and the enclave’s own code measurement; and each signature ships with a Microsoft Azure Attestation (MAA) token. So a valid receipt proves this exact measured code made the model call and produced this verdict — not merely that someone signed it.
3

Anchor — the public record

The signed commitments are written to a public blockchain (RunRegistry on Base). The record includes the enclave measurement, so the onchain anchor itself attests which measured code held the signing key — permanent, timestamped, and neutral.
4

Verify — don't trust, recompute

Anyone re-derives every claim from the published transcript, in the browser: recompute the hash chain, recover the signer, RS256-verify the MAA attestation against Microsoft’s live keys, and ask the chain whether the commitments are anchored. No trust in Chance is required at any step.

​
The attestation is verified, not asserted

The browser check isn’t a badge we render — it’s a real cryptographic verification you can read and reimplement:
  • Signature. The MAA token is RS256-verified against Microsoft’s published signing keys (fetched live from the attestation service — CORS-enabled, so the browser does it directly, no Chance server in the loop).
  • Hardware + code. The token must attest a genuine, non-debuggable AMD SEV-SNP enclave whose code measurement (x-ms-sevsnpvm-hostdata) matches the expected, published value — pinning which code held the key.
  • Binding. The measurement is committed into the judge-signed digest and stored onchain, so the anchor and the attestation agree on the same enclave.
A hand-crafted token, a valid token from a different attestation service, or one whose measurement doesn’t match all fail — visibly.

​
What the receipt contains

Every verdict response includes a proof object:
​
transcriptRoot
string
Root of the hash-chained transcript of the whole run.
​
signature
string
The judge’s signature over the run digest.
​
judge
string
The judge address that signed.
​
hostdata
string
The attested enclave code measurement bound into the digest and the onchain record.
​
attested
boolean
true when the judge key ran inside an attested TEE.
​
anchorTx
string
The onchain anchor transaction (with an explorer link).
​
transcriptUri
string
URL of the full transcript. Owner-only: authenticate as the run’s account (API key via x-api-key, or signed in in the browser) — the URI is committed into the public onchain anchor, so the URL itself grants nothing.

​
What is and isn’t guaranteed

Chance proves the decision is tamper-evident, that the model call and the signing happened inside genuine measured enclave hardware — the receipt proves this exact code produced this verdict — and that the measurement is anchored onchain, all checkable by you, trusting no one. Two honest limits: it does not prove the decision was wise (garbage in, provable garbage out — the intent you submit is what’s being checked against), and it trusts the model provider — the enclave proves it made the call and committed the exact response it received, not that the provider didn’t quietly serve a different model.