A proof you cannot
check is a claim.
Every proof this site makes leaves as one JSON file with the statement it answers and the context it is bound to. Verification is a few hundred curve operations over the numbers in that file — no secret, no key, no server. Paste one below, including one you did not make here.
The bundle
{
"alg": "zecbase/bn254/v1",
"statement": "range" | "ring" | "seal" | "anchor",
"context": "chain=8453|statement=range|threshold=1000000",
"made": 1758000000000,
"publicInputs": { ... },
"proof": { ... }
}The context is not decoration. It is absorbed into the transcript before anything else, so a proof made for one chain, one threshold or one window is rejected everywhere else. Move a range proof to a bigger claim and the challenge changes; the responses no longer open.
The transcript rule
- 01Absorb the domain zecbase/bn254/v1, then the context, then the statement name.
- 02Absorb every public point, each one length-prefixed with its label, x and y as 32 bytes each.
- 03The challenge is keccak-256 of the whole transcript, read as a big-endian integer, reduced mod the group order.
- 04Responses are checked against the challenge. One flipped bit anywhere moves the challenge and breaks the check.
The generators
Binding rests on nobody knowing a discrete log between these points. G is the curve's own generator; the other two are the first curve points produced by hashing a printed label, which is a construction anyone can repeat and nobody can steer.
| base | where it comes from | x ‖ y |
|---|---|---|
| G | the curve's own generator, (1, 2) | 0x000000000000000000000000…0000000002 |
| H | keccak("ZECBASE/generator/H/v1"), first point found | 0x2f111785d21f087d7502aaf7…5b0d905b6a |
| J | keccak("ZECBASE/generator/nullifier/v1"), first point found | 0x211e259589fb3b3eb692384d…60efb3605c |
field p = 218882428718392752222464… · group order n = 218882428718392752222464… · BN254, the curve the EVM verifies at precompiles 0x06 and 0x07
What is proved
That the numbers in the bundle satisfy the statement, and that they were produced by someone who knew the hidden values. Soundness rests on the discrete log problem on BN254 and on keccak behaving like a random oracle. There is no trusted setup anywhere in it, so there is no ceremony you have to believe in.
What is not claimed
No verifier contract is deployed yet, and this page does not pretend otherwise. The arithmetic is chosen so that one can be: every check is a handful of ecAdd and ecMul calls, which is why BN254 was picked over a faster curve the EVM cannot see. When a verifier is live, its address will be printed on the token page and nowhere else.