The proof
What a zkVM proves, what it does not, and how a seal says whether its checks were proven or signed.
Two ways to trust an answer
A check produces an answer: pass or fail, with evidence. There are two ways to believe it.
Signed. The auditor ran the check on their machine and signed the answer. You trust the auditor's key, and the stake behind it. If the auditor lied, the stake pays.
Proven. The check ran inside a zkVM, which produced a receipt. The receipt is a mathematical statement: this program, with this hash, ran on an input with that hash, and produced this output. Anyone can verify it in milliseconds, including a smart contract. You trust nothing but the arithmetic.
Every seal carries a field, proven, with one of those two words. The site shows it under the score. The two are never shown as the same thing.
Status. Every seal today is
signed. The zkVM path is the next milestone; this page describes what it will and will not add.
What the zkVM proves
The program inside the zkVM is the checks: parse the artifact, walk the AST, scan the opcodes, decide. Its inputs are the compiled artifact and the on-chain bytecode. Its outputs are the eight answers and the bytecode hash.
The receipt commits to three things: the program (so it cannot be swapped for one that always says pass), the rule set (which is the program's identity), and the bytecode hash (so the answers cannot be reused for other code). It does not contain the input, the source, or the artifact. That is the whole point: the proof says the checks ran on something with this hash, and the something stays private.
What the zkVM does not prove
That the source matches the chain. The match is done outside the proof, by compiling and comparing. To prove it inside, the compiler would have to run inside the zkVM, which is possible and expensive, and is on the roadmap after the checks themselves. Until then the match is signed.
Check 07. The fork simulation runs a full EVM against live state. Proving it means proving an EVM execution, which is what zkEVMs do, at a cost far above the other seven. It stays signed for the foreseeable future and the seal says so per check.
The review. A language model's output cannot be proven in any practical sense. The review is an opinion, signed, and labelled.
Why bother, if the stake already pays
Because a stake is a promise and a proof is a fact. A stake can be too small for the damage, or the vote that takes it can be captured. A proof cannot be wrong about what it proves. The two are layered: proof where the question is mechanical, stake where it is not.
And because a proof travels. A wallet on another chain, a launchpad with no relationship to the auditor, a contract that wants to gate on "sealed 8 of 8" can verify a receipt without asking anyone. A signature only tells them whom to ask.
The road
- Checks 01 to 06 and 08 inside a general-purpose zkVM (SP1 or RISC Zero), receipt stored on the seal,
proven: zkvm. - A verifier contract on Robinhood Chain that accepts the receipt before writing a seal to the registry.
- The compile-and-match step inside the zkVM, so the link from source to chain is proven too.
- Check 07 through a zkEVM, if and when the cost makes sense.