When a contract on Ethereum needs data from Base, the usual solution is to send it across a bridge. Wormhole, LayerZero, and Base's native messenger make different tradeoffs about what must be trusted, but the object crossing the bridge is fundamentally the same: a message prepared on Base and delivered to Ethereum.
That model works when a contract on Base knows which fact Ethereum will need and sends it explicitly. It is less useful when Ethereum needs to reason over activity that nobody packaged into a message—for example, every address that traded in a pool during a reward period.
Storage proofs let Ethereum verify facts from Base without waiting for a contract to send them, but only one fact at a time. They can prove that a particular slot or event exists; they cannot prove that a returned set is complete with no omissions. A user can show, I did X. A protocol cannot safely conclude, Here is everyone who did X.
That is the gap we set out to close. This past weekend, a contract on Ethereum mainnet verified that a sequence of consecutive Base blocks had been indexed completely and correctly, and that the sequence was a real, finalized stretch of Base itself. It can now execute against that data without trusting anyone to report what happened. Verification cost about $0.25, and the transaction can be viewed here.
What this unlocks
Once an Ethereum contract can act on a complete set of Base events, cross-chain rewards, accounting, governance, reconciliation, and audits no longer have to begin with a trusted off-chain index. The applications include:
- Ethereum contracts paying for activity on Base. Reward programs on Base are commonly paid from calculations performed by off-chain engines. Merkl alone distributes on the order of $90K a day this way, but the payment contracts cannot check whether the underlying activity was indexed completely. An Ethereum distributor can instead pay from verified Base pool events. The proving infrastructure exists; what remains is a relatively small consumer contract.
- Base contracts reading complete Ethereum history. Every Base block already records the latest Ethereum block hash, so bringing the Ethereum verifier to Base is primarily a port rather than a new proof system. Base applications can then read verified L1 staking, restaking, or tokenized-asset registry activity without an oracle committee.
- L1 protocols reconciling their L2 deployments with fewer trust assumptions. Protocols such as Aave, Uniswap, and Lido bring fees, votes, and positions from L2 back to Ethereum through bridge infrastructure. Aave, for example, requires several bridges to agree before accepting a message. A proof-based read replaces that agreement with a proof checked against Base's own settlement.
- Rollups reading one another through Ethereum. Since Base and Arbitrum both settle on Ethereum, Ethereum can serve as a common anchor for verified reads between them. This is particularly relevant now that Base sits outside native Superchain interoperability, although this use remains a design rather than a deployment.
The timing is notable. Coinbase launched tokenized stocks on Base this week, beginning with Apple, Nvidia, Meta, and Alphabet for non-US users. The B20 standard emits events for every transfer, mint, burn, and freeze, and lending markets, issuers, and auditors will depend on indexed versions of that activity. Our demonstration filtered for Uniswap events, but proving a complete set of tokenized-stock events uses the same machinery.
The proof
The contract verified Base blocks 49,994,153 through 49,994,160, filtering for Uniswap v4 Swap and ModifyLiquidity events. The window contained 15 matches, and the proof establishes that those 15 are the complete set. Proving took about 43 minutes on one GPU, verification cost about $0.25, and the full run used approximately $25 of compute.
This is the same completeness proof we already run on Ethereum, adapted to a rollup. The adaptation required a new way to anchor the block history and support for a receipt type that appears on Base but not Ethereum.
Anchoring the proof to Base
A completeness proof is only useful if the verifier knows it covers the real blocks. An Ethereum contract can check Ethereum block hashes directly, but it does not execute Base blocks and cannot do the same for Base.
What Ethereum does hold is the state root Base finalizes through its dispute game. Our proof computes that root from the blocks it covers, and the verifier requires it to match the finalized root in Base's registry on Ethereum. A proof describing a fabricated version of Base therefore fails.
The completeness proof provides the same guarantees as it does for an Ethereum window, while the anchor inherits the guarantees of Base's dispute game: today, a trusted-hardware prover, a ZK proof, and roughly five days to finality. Those are the same assumptions behind a Base-to-Ethereum withdrawal, but they are not Ethereum consensus.
Supporting Base deposit receipts
Every Base block begins with a deposit receipt carrying information from Ethereum. Unlike an ordinary Ethereum receipt, it has two additional fields after the logs: a nonce and a version byte.
Our circuit hashes every receipt and checks its encoded length, but it had been built on the assumption that logs were always the final field. It therefore rejected Base deposit receipts because they contained bytes it could not account for. Supporting them required adding the two fields to the length calculation and receipt hash, which is checked against the commitment in the Base block. The update also handles the roughly 0.45% of Base blocks whose deposit receipts contain logs.
What's next
The circuits do not otherwise care which EVM chain produced the receipts. Other OP-stack chains require no further circuit changes, while chains outside that family need an appropriate filter and anchor contract. An Ethereum contract that pays from a verified Base window is now a deployment away, and a Base verifier that reads Ethereum is largely a port of what we already have.
The larger opportunity is to stop treating cross-chain data as a message that one party sends and another accepts. Once contracts can verify complete history from another chain, they can make decisions from that history directly.
If you are building something on Base or Ethereum that moves money based on the other chain's data — tokenized stocks included — and would rather verify that data than trust it, we would like to hear from you.