Compute proofs

Groth16 receipts: what they are, and where ours live

Every proof-bearing kernel on this site ships the cryptographic receipt for its own published result next to its own code, in a public repository, under a CC BY 4.0 license. This page walks through what a receipt contains, what the proof inside it establishes, what it does not, and three ways to verify one without taking our word for anything.

Where the receipts live

In the open, next to the thing they attest

A receipt here is not a badge or a summary page. It is a JSON object embedded in the same published shard file that carries the node's metadata, input and output schema references, and conformance fixtures. The whole set lives in the public repository, one file per node, so the receipt for any result and the logic that produced it can be read side by side. For example, the receipt for the Basel 3.1 reporting delta node sits inside its node file, under the audit_signature.compute_proof key.

receiptFormat
groth16-bn254: the Groth16 proving scheme (Groth, EUROCRYPT 2016) instantiated over the BN254 elliptic curve. The same receipt format carries a system: risc0 field naming the zkVM that produced it.
Why this one Groth16 proofs stay small and cheap to verify no matter how much computation they attest, and BN254 verification is cheap enough for a smart contract to run.
imageId
A SHA-256 digest identifying the exact guest program binary the zkVM executed. This is the identity the seal is bound to: a receipt made by a different binary carries a different imageId.
Binding each imageId is also published in the node's compute_images list, and the coverage gate refuses a receipt whose imageId is missing from that list.
seal
The Groth16 proof itself, base64-encoded: a few hundred bytes of cryptographic material that verifies against the zkVM vendor's published verifying key. It is a compressed proof of valid execution, not a dump of the computation.
Verified against the RISC Zero verifying key, which our in-browser verifier and the on-chain recipe both pin. A seal verifies or it does not; there is no partial credit.
journal
The public output committed by that execution. It carries the digest of the kernel source that ran (kernel_digest) and the output payload itself, which the coverage gate requires to equal the node's published output byte for byte.
Checked a journal that commits an error instead of a result fails the gate, because a valid seal over a failed run would prove only that the failure happened. This failure mode is real and was observed once, in August 2026, and the check that rejects it is structural since then.
What the seal establishes

This output was computed by this program, and you can check that

Verifying a receipt is a local cryptographic check: given the seal, the journal, and the imageId, anyone can confirm that the seal is a valid Groth16 proof, under the published verifying key, for an execution of that exact guest binary that halted normally and committed exactly this journal. Running the check requires no trust in us, in the server that served the page, or in the deployment pipeline. That is the property the receipt is for: the published result came out of running the published logic, rather than being typed in by hand.

Because the proofs are succinct, the check is cheap in every direction: a browser does it in milliseconds, and a smart contract can do it on-chain, since Ethereum has shipped cheap BN254 pairing checks natively since EIP-196 and EIP-197 went live in the Byzantium hard fork (October 2017). Our on-chain verification recipe uses exactly that path, one read-only call against the zkVM vendor's deployed verifier contract.

Publishing every receipt in a versioned public repository puts them where tampering is visible, the same transparency pattern Certificate Transparency standardized for certificates (RFC 9162) and SLSA standardized for build provenance. The deploy side of that pattern, which binds the served bytes of this site to a named commit and workflow run, is described on the Methods page.

The honest boundary

What a receipt does not establish

Read this next to any receipt claim

A receipt proves that the committed output came from executing the committed program. Whether that program's logic is a correct model of the regulatory rule it cites is a different question, answered by the specification, fixtures, and property evidence described on Methods and the mechanical verification page. A proof over wrong logic still proves that the wrong logic ran correctly.

A receipt is also about the past: it attests one execution of one binary. Whether the bytes the site serves today still match the bytes the receipts attest is checked separately, by the deploy manifest and a recurring live smoke against the served MCP endpoint, not by the receipt.

Verify one yourself

Four ways to check a receipt yourself

In the browser no network
Open the Verification Desk and drop in any node's JSON file. Its compute-proof layer verifies the BN254 seal with a self-contained reference verifier vendored from the same code the suite ships, entirely in your browser.
Good for checking a receipt you have already downloaded, with zero setup and zero network calls.
On-chain one eth_call
The receipt verification recipe walks through checking a receipt against RISC Zero's deployed on-chain verifier with a single read-only eth_call, using any Ethereum RPC endpoint.
Good for a trust root outside our infrastructure entirely: the verifier contract is the vendor's, not ours.
From the repository CLI
Clone the repo and run node scripts/check-compute-proof-coverage.mjs. The gate replays the structural checks for every receipt in the estate and fails against its committed ratchet baseline if any regress.
Good for auditing the whole set at once, or the coverage gate's own behavior: the script is public, commented, and tested.
The normative text SPEC.md
Section 18 of the OpenChainGraph specification defines what a compute-integrity receipt must contain, where it lives, and which checks make one malformed. The spec, its version history, and every gate that enforces it are in the same public repository.
Good for knowing exactly which rule a check enforces, rather than taking this page's word for it.
Open the Verification Desk Browse the receipt files ↗ Read the methods overview

Sources: Groth, On the Size of Pairing-based Non-interactive Arguments, EUROCRYPT 2016. EIP-196 and EIP-197, BN256 curve and pairing precompiles, live since October 2017. RISC Zero proof system documentation, dev.risczero.com, receipt model of journal plus seal, accessed September 2026. RFC 9162, Certificate Transparency Version 2.0, December 2021. All statements on this page are as of September 2026.