Prove the chain.
Reveal nothing.

Every so often, Robinhood Chain posts a state root to Ethereum — a single hash standing in for the entire state of the chain at that moment. Ethereum stores the hash. It does not check it. Checking is delegated to a challenge window, during which someone is supposed to notice if the root is wrong and say so.

The catch is who someone is. Only a small permissioned set of validators can raise a challenge. If all of them are offline, uninterested, or agreeable, a bad state root is accepted by default and becomes the chain’s history. Nothing about that is unusual — it is how most chains of this design work — but it means the guarantee you actually get is not “this state is correct”, it is “these particular parties did not object”.

That is a trust assumption wearing a verification costume. Oracleum replaces it with something you can check yourself: a commitment to every contiguous window of blocks, and a proof that the commitment is what it claims to be. You do not need permission to check a proof, and a proof does not care whether anyone was paying attention.

A window is a block range and two state roots: the root before the first block, and the root after the last. That pair is what makes a window meaningful — it says “starting here, applying these blocks, you end up there”. A commitment to one root alone would be a snapshot; a commitment to both is a claim about a transition.

Windows must be strictly contiguous. Window n has to begin at the block immediately after window n−1 ended, and its before-root has to equal that window’s after-root. The verifier contract enforces both. This is the part that matters: you cannot anchor the convenient stretches of history and quietly skip the rest, because a skipped stretch leaves a gap the next anchor cannot cross.

A Pedersen commitment takes the thing you want to hide and a random number, and produces a single point on a curve. The random number is the important half. Because it is fresh every time, the same state roots committed twice produce two completely unrelated-looking commitments, and the commitment on its own tells an observer exactly nothing — not the roots, not their size, not whether two windows are related.

You also cannot lie later. The commitment is built from two curve points whose relationship nobody knows, because the second one is derived by hashing a fixed string onto the curve rather than being chosen. Without that relationship there is no way to find a second pair of values that opens to the same commitment. The box is sealed in both directions: you cannot see in, and the person who sealed it cannot swap the contents.

The proof is the other half. It convinces anyone that you know what is inside and that you built the commitment from the exact block range you claimed — by answering a challenge that only someone holding the real values could answer. The challenge is derived from the statement itself, so there is no verifier to collude with and no interaction to replay. One bit changes anywhere, and the answer stops fitting.

ProofAnchor stores, for each accepted window, the block range, the commitment, a hash of the proof, and the address that submitted it. Before it stores anything it checks two things: that the window begins exactly where the last one ended, and that it spans no more than 2,048 blocks. Anything else reverts. The result is that the anchor set is a chain, not a pile — you can walk it end to end and know you have not skipped anything.

Verifying does not require trusting us, running our software, or asking anyone’s permission. Read the Anchored events from the contract, fetch the proof they reference, and check it. If you also hold the state roots — because you run a node, or because you read them from Ethereum — you can recompute the commitment and confirm the anchor describes the history you observed.