Ethereum Storage Proofs
What Are Storage Proofs?
Storage Proofs are cryptographic proofs that specific data existed on the Ethereum blockchain at a specific point in time. They let any smart contract, on any chain, verify a fact about Ethereum's state without relying on an oracle, a relayer, or any trusted third party. Trust comes from the math, not from intermediaries.
A Herodotus Storage Proof is a fusion of three cryptographic primitives:
- Inclusion Proofs confirm the presence of specific data within cryptographic data structures like Merkle trees and Merkle Patricia Tries, ensuring that the data in question genuinely exists within a dataset such as Ethereum's state.
- Proofs of Computation validate the execution of a multi-step verification workflow, attesting to the validity of one or multiple elements in extensive datasets such as the entire Ethereum blockchain or a rollup.
- Zero-Knowledge Proofs streamline the amount of data a smart contract needs to interact with. They allow smart contracts to confirm a claim's validity without processing all of the underlying data.
Together, these three layers enable on-chain data access across chains and across time, all while preserving the inherent security of the blockchain base layer.
Herodotus builds managed infrastructure for generating, delivering, and verifying Storage Proofs at scale.
Why Storage Proofs Matter
Smart contracts operate under strict constraints. They can only read data that exists on their own chain, in the current block. They cannot natively query another chain's state, look up a historical balance, or verify what happened 10,000 blocks ago.
Today, most applications that need cross-chain or historical data rely on oracles or off-chain relayers. These introduce trust assumptions: someone signs the data, someone relays it, and the consuming contract trusts that the data is accurate.
Storage Proofs replace this trust model entirely. Instead of trusting a signer, the consuming contract verifies a cryptographic proof tied to an Ethereum block header. The data is either correct or the proof is invalid. There is no middle ground.
This matters for cross-chain applications, historical data verification, compliance checks, proof-of-reserves systems, governance, and any use case where the integrity of on-chain data is not optional.
How Ethereum Storage Proofs Work
Ethereum's state is organized into three trie structures per block: the State Trie (account data), the Storage Trie (contract variables), and the Receipts Trie (transaction outcomes). Each trie's root hash is committed in the block header.
A Storage Proof traces a Merkle path from the trie root down to the specific leaf node containing the value you want to verify. By reconstructing this path and checking each hash along the way, a verifier confirms that the value was included in the trie at that block height. A zero-knowledge proof then compresses this verification so that smart contracts can confirm it on-chain without processing the full trie data.
For recent blocks (within the last 256), Ethereum's EVM exposes block hashes directly via the BLOCKHASH opcode. For anything older, the block hash is no longer accessible on-chain. This creates a hard boundary: without additional infrastructure, smart contracts cannot verify historical state beyond roughly one hour.
Herodotus solves this with a Historical Block Hash Accumulator. Using STARK proofs and Merkle Mountain Ranges (MMRs), Herodotus maintains a verified on-chain commitment to every Ethereum block hash back to genesis. This extends the verifiable window from 256 blocks to the entire chain history.
With the accumulator in place, any Storage Proof can be anchored to any historical block, verified on any supported destination chain, and consumed by any smart contract.
What You Can Prove
Herodotus Storage Proofs support verification of the following Ethereum data types:
Account properties: balance, nonce, code hash, storage root.
Block header properties: parent hash, state root, transactions root, receipts root, timestamp, block number, gas used, base fee per gas, and others.
Storage slot values: any contract variable stored at a known slot index, including ERC-20 balances, mapping entries, and struct fields.
Transaction and receipt data: transaction inclusion, log events, and receipt status.
These proofs work across supported origin and destination chains, including Ethereum Mainnet, Starknet, Optimism, Base, Arbitrum, ApeChain, and World Chain, with testnets available for development.
Storage Proof API
The Herodotus Storage Proof API is a managed service that abstracts the complexity of proof generation and verification. Developers do not need to understand cryptography, run provers, or manage accumulator infrastructure.
The workflow is straightforward: request a proof for a specific account, slot, or block header property on a given chain and block number. The API handles scheduling, proof generation, cost mutualization, and delivery. When the proof is ready, it can be consumed by a smart contract on the destination chain via the Herodotus Satellite contract interface.
The API supports webhook notifications for async workflows and multiple proof modes to fit different latency and cost requirements.
Storage Proofs focus on trustless data access: proving that specific on-chain data exists and is authentic. For developers who need to go further and run verifiable computations over that proven data, such as aggregations, time-weighted averages, or multi-block analytics, the Herodotus Data Processor (HDP) provides a programmable compute layer built on top of Storage Proofs.
Common Use Cases
Cross-chain lending and collateral verification. Prove that an address holds sufficient collateral on Ethereum before issuing a loan on another chain.
Governance. Verify token holdings at a past snapshot block to enable cross-chain or historical-state voting without requiring token transfers.
Proof of reserves. Demonstrate on-chain that an entity held specific assets at a specific time, with no reliance on third-party attestation.
Historical balance verification. Confirm that an address maintained a minimum balance over a defined period, useful for credit scoring, loyalty programs, or tiered access.
Trustless oracle replacement. Replace signed oracle feeds with proof-based reads for any data that already exists on-chain.
FAQ
What is the difference between Storage Proofs and an oracle?
An oracle is a service that signs and relays data, introducing a trust assumption on the signer. Storage Proofs are cryptographic proofs anchored to block headers. The verifier checks the math directly and does not need to trust any intermediary.
Can I verify data from any historical Ethereum block?
Yes. Herodotus maintains a Historical Block Hash Accumulator that covers every block back to Ethereum's genesis. Standard EVM contracts can only access the last 256 block hashes natively.
Which chains are supported?
Storage Proofs can originate from Ethereum Mainnet, Starknet, Optimism, Base, ApeChain, and their respective testnets. Proofs can be delivered and verified on Starknet, Arbitrum, Base, Optimism, ApeChain, World Chain, and others. See the documentation for the full deployment matrix.
Do I need to understand zero-knowledge proofs to use the API?
No. The Storage Proof API handles proof generation and verification. You interact with a REST API and consume verified values from on-chain Satellite contracts. No cryptography expertise is required.
How do Storage Proofs relate to eth_getProof (EIP-1186)?
eth_getProof is an Ethereum RPC method that returns a raw Merkle proof for an account or storage slot. It is useful for off-chain verification but does not solve cross-chain delivery, historical block access beyond 256 blocks, or on-chain consumption by smart contracts. Herodotus Storage Proofs build on these primitives and extend them with accumulator infrastructure, managed proof generation, zero-knowledge compression, and on-chain verification contracts.
What is the difference between Storage Proofs and a ZK coprocessor?
Storage Proofs focus on trustless data access: cryptographically proving that specific on-chain data exists and is authentic. A ZK coprocessor adds a compute layer on top, allowing you to run verifiable programs over that data. Herodotus offers both: Storage Proofs for data access, and the Herodotus Data Processor (HDP) for provable computation over proven data.
Start Verifying On-Chain Data
Herodotus Storage Proofs are live on mainnet and available through the Herodotus Cloud console. Explore the Storage Proof API documentation or contact the team for integration support.