From receipt to verify() calldata

A published compute-integrity receipt is one JSON object carrying four facts: the program that ran, the output it committed, the Groth16 seal over that commitment, and the parameter set the proof was made under. Only three of them cross the chain boundary.

The envelope is the OpenChainGraph standard's §18 compute proof: type ZkVmReceipt, system risc0, receiptFormat groth16-bn254, plus imageId, seal and the journal. The imageId is the SHA-256 identity of the exact guest program that ran in the zkVM; the journal is the output the guest committed; the seal is the 256 byte Groth16 proof binding the two together. The deployed verifier consumes the imageId, a digest of the journal, and the seal. Everything else on this page exists to get those three exactly right.

Here is a published §18 receipt in JSON. Name which of its members the deployed RISC Zero verifier consumes, and what each one binds the proof to.

The verifier never sees the journal object; it sees one SHA-256 digest. The bytes that get hashed are the canonical JSON of the journal: RFC 8785 (JCS), encoded UTF-8, keys sorted at every nesting depth, no insignificant whitespace. Hash any other serialization and an honest receipt fails, which is how you know you hashed the right bytes.

Serialization is not a technicality. The published worked example on this page is the one receipt in the estate corpus whose journal carries unsorted nested keys, so the stored-order bytes and the canonical bytes genuinely differ, and only the canonical digest verifies on-chain. That is the standard's §18.7 byte contract, and the deployed contract agrees with it: the recipe page shows both directions recorded live against the router.

Compute the RFC 8785 canonical serialization of this journal object. Report the UTF-8 byte length and the SHA-256 digest, and show the canonical JSON itself.

Base64-decoded, the seal is exactly 256 bytes: three elliptic curve points of a Groth16 proof over the BN254 curve. On the wire it travels with a 4 byte selector in front, 73c457ba, which routes the call to the verifier implementation whose parameters match how the proof was made. The joined 260 bytes are what the call carries.

The selector is derived from the verifier parameters (the risc0 control root, the BN254 control id, the Groth16 verifying key digest) rather than from a crate version string. The estate's receipts are proven with cargo-risczero 3.0.5 against the parameter set risc0-ethereum shipped as its 3.0.0 verifier generation, whose selector is 0x73c457ba. Before verifying you can confirm the routing live with a one word getVerifier call; the recipe page shows that step too.

Decode this base64 seal to raw bytes, confirm the length is exactly 256, and prepend the risc0 v3.0.x selector 73c457ba to form the 260 byte on-chain seal.

Read this label twice:

• Proof validity only. A pass says the seal is a valid Groth16 proof of this exact journal under this exact program id, on the implementation selector 73c457ba routes to. It is the same check an on-chain settlement would rely on.
• Not rule correctness. The journal is the tool's committed output; whether the policy it applied is the right policy is a judgment about rule text and its publication, which no cryptographic proof can carry.
• Availability is an operator promise. The routed implementation sits behind an emergency stop proxy whose guardian can permanently disable it if a critical vulnerability is proven. For this deployed version, whether the verifier is up depends on an operator; it is not a protocol fact.
• Freshness and endorsement are separate checks. Compare the journal against the tool's current published output for the same inputs, and take the imageId from the published receipt corpus, and never from the party whose receipt you are auditing.

Given this verified receipt, draft the two sentences a report should carry: what the on-chain pass establishes, and the two things it deliberately does not claim.