On July 31, 2026, a contract on Ethereum mainnet verified that a window of consecutive Ethereum blocks had been indexed completely and faithfully — nothing relevant left out — and that the window was a real, finalized piece of the canonical chain. The verification cost about 0.000018 ETH, and you can look at it: the transaction is public.
That sentence has a lot packed into it, so let's take it apart, because we think it points at something new.
The problem with trusting an indexer
Applications don't read the blockchain directly. They read an indexer — a service that watches the chain, pulls out the events an application cares about, and serves them up in a usable form. Almost everything you interact with in crypto sits on top of one.
The catch is that an indexer can quietly leave things out. Not maliciously, usually — a missed event, a parsing bug, a reorg handled wrong. But the result is the same: the application is now working from an incomplete picture, and nothing about that looks like an error. The numbers still add up. They're just wrong.
This matters most when money moves on the result. Reward distributions, airdrops, payouts — these are computed from indexed data, and if the indexer dropped an event, someone gets paid who shouldn't, or someone who should doesn't. The person who was skipped has no way to prove they were skipped.
Willow's whole reason for existing is to close that gap: to give you a cryptographic proof that an index is complete — that nothing relevant was omitted — rather than asking you to trust that it is.
What we did
We took that proof one step further than we ever had: we put it on Ethereum itself.
A verifier contract we deployed to mainnet checked a Willow completeness proof for a window of blocks and confirmed, on-chain, that the window was indexed with nothing left out. No trusted server in the loop. The chain checked the work.
The part that makes this sound rather than circular is the anchoring. A proof that says "I indexed these blocks correctly" is worthless if the prover also gets to pick which blocks those were — you could index an imaginary chain flawlessly. So the contract doesn't take our word for which blocks it's looking at. It reads the real block hash out of Ethereum's own recent history, using EIP-2935, and checks our proof against that. The window has to be a genuine, finalized stretch of the canonical chain, or the verification fails.
Getting there meant building a pipeline that ends in a proof small enough for a contract to check cheaply: the raw completeness proof is compressed through recursion, then wrapped into a Groth16 proof and verified on-chain by the canonical SP1 gateway. Recursion — proving that you correctly verified other proofs, so many small proofs collapse into one — is what makes the on-chain step affordable at all. We got recursion working natively in Binius64 a few weeks earlier: a real 4.3-million-gate proof recursed in about four seconds, three proofs folding into one.
Why this is a bigger deal than one transaction
Once a contract can verify that a window of Ethereum blocks was indexed completely, a set of things that weren't possible before become possible.
A contract on another chain can confirm that a set of Ethereum events really happened and that none were omitted — a bridge with cryptography underneath it instead of a trusted committee. A protocol can execute directly against indexed history rather than an API it has to trust. An auditor can check a claim about the chain's past without re-indexing the chain themselves. In each case, nobody has to take an indexer's word for anything.
We think of this as a new primitive: verifiable, complete Ethereum history that any contract can check. It's the reason we built the recursion and the on-chain verifier in the first place.
The scope, precisely
The window we verified is eight blocks. This was a demonstration that the full pipeline runs end to end against real mainnet data — not a production-scale run. Scaling it to a meaningful span of history is the engineering ahead of us.
It also proves a specific thing: completeness and anchoring. That nothing was omitted, and that the data genuinely comes from the canonical chain. It does not prove the correctness of any computation done on top of that data — a reward calculation, say. That's a separate proof, and it's on our roadmap rather than in this result.
For the test, we used real reward-input events from EigenLayer, because they're a clean example of the pattern we care about: public on-chain data where a single silently dropped event changes who gets paid.
What's next
Two things. Widening the window from a demonstration toward production, which is largely a matter of proving throughput. And proving the computation done on top of complete data, not just the completeness of the data underneath it — so that an entire distribution, not just its inputs, can be checked on-chain.
If any of this is useful to what you're building, we'd like to hear from you.