A record the chain cannot fake, about a state you never have to show.

Why zero-knowledge proofs matter

A blockchain is a machine for replacing trust with verification. But verification has always had a price: to check something, you had to see it. Every balance, every transfer, every piece of state was laid bare so that anyone could recompute it. Transparency and privacy pulled in opposite directions, and for fifteen years privacy lost.

A zero-knowledge proof breaks that trade. It is a short piece of data that convinces a verifier that a statement is true, while revealing nothing beyond the fact that it is true. Three properties define it. Completeness: an honest prover always convinces the verifier. Soundness: a dishonest prover cannot convince the verifier of a false statement, except with a probability so small it never happens in practice. Zero knowledge: the verifier learns nothing it could not have produced itself.

Put those together and something new becomes possible. You can prove that a value is well formed without saying what it is. You can prove that two hidden values are equal without opening either. You can prove that a history is unbroken without publishing the history. And crucially, the proof can be checked by a smart contract in a few hundred thousand gas, by anyone, forever. A proof does not care who wrote it, who runs the chain, or whether the validator set is whitelisted. It is either valid or it is not.

That last point is why zero-knowledge proofs matter specifically for young chains. The people operating a chain are a trust assumption. Proofs are not. Where a chain asks you to believe its operators, a proof lets you check instead.

The problem on Robinhood Chain

Robinhood Chain is an Ethereum Layer 2 on the Arbitrum stack. Its security model is optimistic: state roots are posted to Ethereum, and if a posted root is wrong, a validator submits a fraud proof and the bad root is rejected. The catch is who is allowed to do that. Today the fraud proof system is not permissionless. Only whitelisted validators may dispute a state root, and there is no forced inclusion path if the sequencer censors a transaction. Users trust a small permissioned set to keep the chain honest.

Call it the trust tax: the gap between "the chain is honest" and "I can check that the chain is honest." zkThunder is built to narrow that gap with proofs rather than promises.

Layer one: anchoring

Every proof covers a block window, a contiguous range of at most 2048 blocks. For each window the protocol produces an artifact committing to the state before and after, hashes it, wraps the hash in a signed message, and writes an immutable record on chain. The rules make the chain of records rigid:

• Sequence numbers are strictly monotonic. The first record is seq 1. Nothing can be inserted, skipped, or replayed.
• Windows tile perfectly. Each window starts exactly one block after the previous one ended, from block 1 onward.
• Each proof hash can be anchored exactly once.
• Every record is signed over a 98 byte message that binds it to this exact chain, this exact contract, this exact window, and this exact sequence position. A signature captured in one context is worthless in any other.

The result is an unbroken, independently checkable lineage. The contract recomputes the signing message itself and recovers the signer with ecrecover; the same construction runs in the browser on the main page, and the two are compared byte for byte every time you press verify.

Layer two: the zero-knowledge layer

State roots on zkThunder are never published in plaintext. Each becomes a Pedersen commitment: the root and a random blinding factor are combined into a point on the secp256k1 curve. The commitment is perfectly hiding, meaning an observer of the chain learns nothing about the root even with unlimited computing power, and computationally binding, meaning the prover cannot later open it to a different value.

Each anchor carries three non-interactive zero-knowledge proofs, made non-interactive with the Fiat-Shamir transform over keccak256 and domain separated so a proof for one purpose can never be reused for another:

• A proof of opening for the incoming commitment: the prover knows a root and blinding behind it, without revealing either.
• A proof of opening for the outgoing commitment.
• A Chaum-Pedersen equality proof: this window's incoming commitment hides the same root as the previous window's outgoing commitment. Two different commitments, one hidden value, linked without opening.

The verifier contract checks all three on chain. Scalar multiplication on secp256k1 is done with the ecrecover trick, which lets a contract compute the address of a curve point combination in a single precompile call; each proof equation becomes an address equality between a point built with one affine addition and the precompile's output. Valid bundles pass. Change one byte and the contract rejects it, and you can watch that happen on the main page.

Trustless anchoring

The original lineage rests on one trusted party: the aggregator whose signature every anchor carries. The trustless lineage removes it. Every EVM chain exposes the hashes of its last 256 blocks to contracts, so the anchoring contract demands the actual block header of each window's end block, checks that it hashes to the chain's own record of that block, and extracts the real state root from it. The anchor must then carry a zero-knowledge proof that its commitment opens to exactly that root, and that its incoming commitment opens to the previous window's root. Nobody signs anything. Anyone may anchor. The chain itself vouches for every root, and the proofs bind the record to it.

One design choice that is easy to misread: the verifier contract is a pure function that is handed the roots as arguments, so on its own it would confirm an opening to any root at all. That is deliberate. It is stateless math, and calling it directly proves nothing and records nothing. The anchoring contract is the only thing that writes a record, and it never takes a root from the caller: it takes the end root from the header it has just checked against the chain's own block hash, and the previous root from its own storage. A forged header cannot match the chain's hash, so a made-up root is rejected before any proof is examined.

Two honest notes. Because the roots come from public headers, they are stored publicly in this mode; the proofs guarantee the commitments genuinely correspond to them, which is what makes the records usable by anyone downstream. And anchoring must happen within about six minutes of a window's end, since that is how long block hashes remain readable on chain; each anchor simply covers everything since the last one, so a lineage that is anchored regularly never has gaps.

What is actually live

This is not a plan. These contracts are deployed on Robinhood Chain mainnet:

• ProofAnchor, the signed lineage0x54fE3b5A866190BF733104AB1c45d15405F27B16
• LineageVerifier, the on-chain ZK verifier0xDF3dD7eee2E2FD5e36900b882aa9473E72d56320
• PublicProofs, the permissionless registry0x537819C42002691fD62e00bc251055587F51F502
• RangeVerifier, hidden-value range proofs0x003f80FF939dA662759ed7047D1a988e5a0E79A2
• TrustlessAnchor, the permissionless lineage0x6DF5BcE4799EdF35C98b5727aa25a7F2b67479a4
• BoundLineageVerifier, binds commitments to real roots0x9207ecf9ef5749ab39e17b610b1af974a03bd422

Source code is verified on the explorer for every contract. The verifier is wired: every anchor must carry a valid zero-knowledge bundle or the transaction reverts. The anchored windows of the signed lineage are on the explorer, each carrying a bundle the contract checked:

• seq 1, blocks 1 to 64, zkVerified0xea51a5dc7b2ec9616a2c118eac7760134c2c0ad7c68b64101cb817f5c7d9a101
• seq 2, blocks 65 to 128, zkVerified0xbb1cb362ddbbc6199c6ccc3d74b7fea5b4f1918ca7150aa07246fc714941870b
• seq 3, blocks 129 to 192, zkVerified0xc2030fe245ce58ccbb5e8c74a6b3defdd2a372a565d4cb9c92067cdb9adacd80
• seq 4, blocks 193 to 256, zkVerified0x3052171a9178482faa528365a1b6213edd8c49921a447471680a5f868d64d300

The contracts pass a lifecycle test suite on a real EVM: registration and escrow, anchoring, every rejection rule, key rotation, the verifier hook, and the proof bundles themselves, which are generated fresh by the real prover at test time and must verify both in the contract and in an independent implementation. A 17 assertion conformance suite runs in your browser on the main page and finishes by asking the deployed contract for its own answer. The proof generator runs in your browser too: a full bundle takes under half a second. A relayer is funded and pays the gas when you record a proof for free.

Live right now, read by your browser from the chain and the relay:

What it does not hide, and does not yet prove

Honesty about limits is part of the design. The proofs establish that the commitment structure is honest and that the lineage is unbroken. They do not yet prove that a state transition was computed correctly. In the signed lineage the truth of the roots inside a record still rests on the aggregator key; in the trustless lineage it rests on the chain's own block hashes. Retiring that last trust is the zkVM tier on the roadmap: a program re-verifying each window's data inside SP1 or RISC Zero, checked by the same pluggable verifier slot. It is the expensive step, and it is what the treasury exists to fund.

Three smaller limits are stated plainly. The on-chain verifier compares 160 bit point addresses rather than full curve coordinates, the shortcut the ecrecover trick imposes; a full-coordinate check is next on the roadmap and will mean redeploying the verifiers. The relayer is a single funded wallet run by the project; if you would rather not trust it, the wallet button records your proof from your own address and depends on nobody. And every anchor, every verification and every relayed record on mainnet costs real ETH, which is what the treasury exists to pay for.

How to try it

1. Open the main page and press Run verification. Seventeen assertions run locally, then your browser cross-checks the live contract.
2. Scroll to Prove it yourself and press Run the whole demo. Your browser turns two secrets into hiding commitments, generates the same bundle the protocol anchors, the deployed verifier accepts it, and a corrupted copy is rejected. The secrets never leave the tab.
3. Do the same in Range: a hidden balance is proven to be at least a public threshold, and an inflated claim on the same proof fails.
4. Press Record on-chain, with your wallet or for free. Your proof becomes a permanent transaction on a public explorer.
5. Scroll to Lineage. Every trustless anchor is listed; press audit on any row and your browser re-checks the record against the chain.

Nothing is stored anywhere but your browser. No accounts, no analytics.

Live on mainnet: the token

Everything above runs on Robinhood Chain mainnet. Every anchored window, every verification, and every relayed proof is a real transaction paid in real ETH, and the protocol only keeps running as long as someone pays for it.

The zkThunder token carries a 3% tax on buys and sells, routed to the prover treasury. The treasury is the bridge from testnet to mainnet. It pays for mainnet deployment of all three contracts, continuous anchoring of Robinhood Chain's state window after window, the relayer that keeps the free button working where every submission costs real ETH, and the zkVM tier that turns lineage proofs into full transition proofs. Without a funded treasury, a verification protocol on mainnet stops the day its operator's wallet runs dry.

Prover treasury, Robinhood Chain mainnet: 0x1F1149377E750719e429B3ce943d98641AC0c6ed

Glossary

Block window

A contiguous, inclusive range of blocks, at most 2048 long. Windows tile the chain perfectly from block 1.

Commitment

A curve point that hides a value and binds the prover to it. Pedersen commitments are perfectly hiding and computationally binding.

Proof of opening

A zero-knowledge proof that the prover knows the value and blinding behind a commitment.

Equality proof

A zero-knowledge proof that two commitments hide the same value, without revealing it.

Domain separation

Binding a signature or proof to its exact context so it cannot be replayed elsewhere.

Aggregator

The key that signs anchoring messages. Rotatable with zero downtime from a scheduled sequence number.

Relayer

A project-funded wallet that submits visitors' proofs to the registry and pays the gas, rate limited to one per visitor per day.