Scope fence – read before use
A PASS verdict proves one narrow thing: the pasted proof is internally well formed under the selected pinned
ProofSpec, and the Merkle root recomputed from its own leaf and inner operations equals the root hash you supplied. It does not tell you the root hash is the right one. A proof is only as good as the root it is checked against, so the root must come from a source you already trust, such as a light-client header you verified separately or a chain state you queried yourself. This page cannot fetch or validate a root for you, by design, because it never opens a network connection. The ProofSpec is never read from the pasted proof: it is chosen from three build-time-pinned constants, which is the structural fix for the October 2022 forged-membership finding VSA-2022-103, where a proof carrying its own spec could declare a forged shape legal.
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Verify a Proof
Proof, root and key
A
CommitmentProof envelope ({"exist": ...} or {"nonexist": ...}) or a bare proof object. Field names follow proofs.proto, so a response copied straight out of a gRPC or REST query pastes in unchanged. Byte fields may be base64 or 0x-prefixed hex; enums may be names or numbers.The key whose presence or absence you are checking. It is also carried inside the proof; supplying it here is what binds the verdict to the key you actually care about.
The Three Pinned Presets
ProofSpec constants, transcribed from the cosmos/ics23 reference implementation
| Field | iavl | tendermint | smt |
|---|
There is no free-text spec input on this page and no custom-spec path in the code. That is deliberate. A
ProofSpec supplied alongside the proof it constrains can simply declare a forged shape legal, which is the shape of the VSA-2022-103 finding, so the spec is always one of the three constants above, chosen by you rather than by the proof.What Each Check Means
Reading the result rows
| Check | What a failure means |
|---|---|
| Leaf shape accepted by spec | The leaf operation's hash, prehash and length settings, or its prefix, are not the ones the selected preset requires. A proof from a different tree shape produces this. |
| Inner ops accepted by spec | An inner operation's prefix or suffix falls outside the preset's bounds, its depth is out of range, or its prefix begins with the leaf prefix. That last case is the domain-separation violation VSA-2022-103 exploited. |
| Key matches the proof | The key you supplied is not the key this proof is about. |
| Root recomputes to the supplied root | Hashing the leaf and walking the inner operations produces a different root. The proof does not belong to that state. |
| Key strictly between the neighbours | For a non-existence proof, the claimed key is not strictly inside the gap the two neighbour proofs describe. A non-strict comparison here would let someone prove the absence of a key that is present. |
| Neighbours leave no gap | The left and right proofs are not adjacent leaves, or the single-sided proof is not actually the leftmost or rightmost leaf, so an unproven key could sit between them. |
The verdict row at the bottom of a result is the authoritative one: it is the return value of the same
verifyExistence and verifyNonExistence functions shipped in chaingraph/kernels/ics23-verify.mjs, which this page carries inline so it stays a single self-contained file. The rows above it attribute a failure to a step; they never override the verdict.