A receipt is a stack of separate claims, and each one rests on something different. This page goes layer by layer: the Groth16 seal, the interpreter guest, the kernel digest, the journal, inputs the caller attests to, and the anchor legs. For each it says what you are relying on and what someone controlling that piece could and could not fake. It then counts the estate's live nodes on a four-stage ladder, and closes with the post-quantum position. Every count is read from the estate inventory, and every sentence about the proof system comes from the proof-system publisher's own documentation at the pinned version.
Six layers, from the cryptographic seal down to the anchors that date the artifact. A reader can check each one without an AINumbers server.
The proof stack has three circuits: a RISC-V circuit and a recursion circuit, both STARKs, and a Groth16 circuit. A composite receipt is a vector of STARKs, one per segment. A succinct receipt is a single STARK for the whole session, formed by aggregating the composite receipt with the recursion circuit. A Groth16 receipt is a single Groth16 proof for the whole session, formed by verifying a succinct receipt inside the Groth16 circuit over the BN254 curve. The estate's seal check uses the Groth16 receipt.
| Rests on | What it means |
|---|---|
| BN254 pairing security | The STARK-to-SNARK prover relies on the security of the BN254 pairing, the Knowledge of Exponent assumption and the integrity of the Groth16 trusted setup ceremony. |
| The trusted setup | The publisher ran a trusted setup ceremony for its Groth16 prover and verifier, securing the STARK verify circuit. It used the Hermez rollup powers of tau with 2^23 powers, on open-source ceremony software coordinated with the PSE team. A new RISC-V circuit does not need a new setup. |
| If an attacker controlled it | The Groth16 layer is sound only if the ceremony was run with integrity, which is the publisher's own stated assumption. Its documents give no detail here on the ceremony's contributors or date, so this page makes no claim about either. |
The estate pins rustc 1.96.0, cargo-risczero 3.0.5, r0vm 3.0.5, risc0-zkvm ^3.0.5 and risc0-groth16 3.0.4 (compute-proof PROVENANCE.md). A fake receipt carries no proof and exists for development mode only.
Name the three circuits behind a Groth16 receipt and list the assumptions the STARK-to-SNARK step relies on.
Most sealed nodes run on a single universal interpreter guest, so they share one image ID; the rest use a handful of separate images. Across 700 sealed live nodes the inventory finds 5 distinct image IDs. This page never says one image ID covers every node: the private-input profile nodes and a few others each carry their own.
What a shared image ID tells you: the same program bytes ran for all of those nodes. What it does not tell you: which kernel the guest was handed, which is the next layer. The exact per-group split is printed by node scripts/zk-trust-inventory.mjs.
Run the estate inventory and report how many distinct image IDs the sealed live nodes use.
Because the guest is shared, the seal alone says a pinned interpreter ran something. The kernel digest binds that something to a specific kernel source. A seal over the right image ID but the wrong kernel digest proves the wrong program, so a checker compares the digest in the receipt against the kernel it expects.
An attacker who could swap the kernel source before sealing would get a valid seal over the swapped program. The digest comparison is what lets a reader catch a swap after the fact.
Explain why a valid seal over the universal guest is not enough without the kernel digest comparison.
The journal, the output the program committed to, is public by default: anyone holding the receipt reads the inputs and the result. Only nodes under the private-input profile commit to a salted hash instead of the raw value. And some inputs are not computed in the program at all. A caller-attested input is a value the caller supplies and the program takes as given.
Today 2 live nodes are caller-attested, and the inventory names each one:
| Node | What is attested |
|---|---|
| art-124 | The signature check. The sealed policy core receives a signature_verified result from the caller; it proves the policy applied to that result, not that the signature is valid. |
| art-235 | The rural or underserved area determination. It runs off census-block and county datasets that cannot be evaluated inside the kernel, so the area test takes a caller-supplied boolean. |
An attacker controlling the caller can feed a false attested value and still get a genuine seal, because the seal covers the program run and not the truth of what was handed in. The node pages declare this boundary rather than assuming it away.
List the caller-attested nodes from the estate inventory and say what each one takes on the caller's word.
An anchor binding is evidence that an artifact's bytes existed by a point in time. It does not say the computation was right. The legs depend on different things, so an attacker has to defeat each one separately.
| Leg | It depends on |
|---|---|
| RFC 3161 token | A timestamp authority's signature chained to a root the verifier pins. A classical signature, so it inherits that scheme's exposure window. |
| OpenTimestamps | SHA-256 Merkle aggregation committed in Bitcoin proof-of-work. No signature anywhere in the attestation path. |
| Witnessed log checkpoint | A public transparency log plus independent witness cosignatures. A second story would need the witnesses to sign a second head. |
Full treatment, with the published anchors you can verify offline, is on the anchors explainer.
For each anchor leg type, state what an attacker would have to control to forge it.
Stage counts come from the inventory, never typed in by hand. The post-quantum section says only what the publisher and NIST say.
Each live node sits on one rung. Aggregate counts only are shown here, apart from the caller-attested nodes named in step 4.
| Stage | Meaning | Live nodes |
|---|---|---|
| S0 | Source only: no seal yet | 2 |
| S1 | Sealed | 459 |
| S2 | Sealed plus a formal-verification evidence vector | 1 |
| S3 | Sealed plus a chain contract | 240 |
Of 702 live nodes, 700 carry a seal. 3 have a formal-verification evidence vector and 240 sit in a chain with a contract; each node is placed on its highest rung. Reproduce the numbers with node scripts/zk-trust-inventory.mjs --summary.
Run the estate inventory in summary mode and report the live node count at each of S0, S1, S2 and S3.
Groth16 over BN254 is not post-quantum. The publisher's security model lists the STARK-to-SNARK prover as not quantum safe and says the translator is vulnerable to quantum attack because it depends on elliptic curve cryptography. The same table lists the two STARK provers, the RISC-V and recursion circuits, as quantum safe, resting on the Random Oracle Model and the Toy Problem conjecture.
So the estate keeps the succinct STARK receipt alongside the Groth16 seal. The seal is the compact form a verifier checks today; the STARK receipt is the form that does not rest on pairings.
The anchor legs in step 5 differ here as well: an OpenTimestamps proof carries no signature to attack, while an RFC 3161 token carries a classical one.
State which receipt layers the proof-system publisher marks quantum safe and which it does not.