Storage proofs are cryptographic proofs that a specific piece of data existed in a blockchain's state at a specific block height. They let any verifier confirm onchain facts without trusting an intermediary. The proof is self-contained: you check the math, not the messenger. No oracle, no relayer, no multisig bridge required.
​

At its core, a storage proof ties a particular storage slot value to a block's state root through an unbroken chain of hash commitments. If the hashes verify, the data is real. If anything was tampered with, the verification fails. This cryptographic guarantee is what separates storage proofs from conventional data feeds, where you are trusting whoever signed the message rather than the math behind it.
​

The concept extends naturally to cross-chain contexts. Chain B can verify that a specific address held a specific balance on Chain A at block 19,000,000, as long as it has access to Chain A's block header. That single property unlocks a category of applications that were previously impossible without a trusted bridge or oracle service.
​

For a broader grounding in how blockchains use cryptographic proofs generally, see What Is a Cryptographic Proof? ZK Proofs and Blockchain Verification.
​

External reference: The Ethereum documentation on the Merkle Patricia Trie provides the formal specification underlying Ethereum storage proofs.
​

Every Ethereum block header contains a state root, a single 32-byte hash that commits to the entire world state of the network at that moment. The world state is a mapping from account addresses to account states. Each account state includes its nonce, balance, code hash, and a storage root. The storage root commits to all of that contract's storage slots. This nesting of commitments is what makes storage proofs possible.
​

The data structure behind all of this is the Merkle Patricia Trie, a variant of a trie data structure where every internal node is identified by the hash of its children. Because the trie is content-addressed, any change to any leaf value bubbles up through every ancestor node all the way to the root. This means the root hash is a fingerprint for the entire dataset at that instant.
​

A storage proof for a single slot has three components:

A verifier follows the proof path by hashing each node and confirming that the hash matches the pointer in its parent. Starting from the trusted state root (which came from a trusted block header), the verifier walks down to the target leaf. If every hash checks out, the slot value is proven. The computation is deterministic and stateless: any party can run it with no external calls.
​

The eth_getProof RPC method on Ethereum nodes returns exactly this structure. It outputs the account proof array and the storage proof array in RLP-encoded form, ready to be submitted to a verifier contract onchain.
​

This architecture is specific to Ethereum's design. Other chains use different state commitment schemes. Solana uses a different account model entirely. Bitcoin does not have a world state trie in the same sense. Cross-chain storage proof systems therefore require chain-specific adapters for each network whose state they want to prove.
​

External reference: EIP-1186 (eips.ethereum.org/EIPS/eip-1186) standardized the eth_getProof interface and defines the exact proof format.
​

Cross-chain communication has historically depended on either trust or latency. Optimistic bridges assume honesty and punish fraud after the fact. Multisig bridges require a quorum of signers to attest that something happened on another chain. Both models introduce an attack surface that is external to the chains themselves. Storage proofs change the trust model: the only thing you need to trust is the source chain's consensus.
​

The mechanism works like this. A user wants Chain B to act on a fact from Chain A. Instead of asking a relayer to sign an attestation, the user submits Chain A's block header to a header oracle on Chain B, then submits the storage proof for the relevant slot. The verifier contract on Chain B checks the proof against the header. If it passes, Chain B accepts the fact as true. The relayer's honesty is irrelevant because the cryptography enforces correctness.
​

The bottleneck is getting the block header onto Chain B in a trustworthy way. If Chain B naively trusts whoever posts the header, you have just moved the trust assumption one level up rather than eliminating it. There are three approaches to solving the header oracle problem:

Once the header oracle is solved, the cross-chain use case is straightforward. A governance contract on an L2 can verify that a user held voting tokens on Ethereum mainnet at a snapshot block. An L2 yield contract can verify that a user deposited into an L1 vault. A cross-chain NFT gate can verify that a user owns a specific token ID on a different chain without any bridge transaction.
​

For context on how chains currently communicate without storage proofs, see What Is Cross-Chain Messaging? How Chains Communicate. For more on bridge architectures and their tradeoffs, see What Is a Blockchain Bridge? Cross-Chain Transfers Explained.
​

External reference: The Ethereum roadmap documentation covers how cross-chain light client support is planned as part of the broader scaling architecture.
​

Native Merkle Patricia Trie proofs are correct but expensive to verify onchain. A typical account plus storage proof requires 5 to 15 trie nodes per level, each involving keccak256 hashes. Verifying this onchain costs between 100,000 and 500,000 gas depending on trie depth, which is prohibitive for high-frequency use cases. ZK storage proofs compress this cost by replacing the raw proof path with a succinct ZK proof of correct Merkle inclusion.
​

The approach works by writing the Merkle proof verification logic as an arithmetic circuit and then generating a SNARK or STARK proof that the circuit executed correctly on the given inputs. The onchain verifier only needs to check the ZK proof, which costs roughly 200,000 to 300,000 gas regardless of how deep the trie was. For trie depths greater than a few levels, this is already cheaper than native verification, and it becomes dramatically cheaper as depth increases.
​

The tradeoff is proof generation time and infrastructure cost. Generating a ZK proof of a Merkle inclusion currently takes seconds to tens of seconds on modern hardware, depending on the proving system and circuit complexity. For latency-sensitive applications this can be a bottleneck. The field is moving quickly, with recursive proof aggregation allowing many storage proofs to be bundled into a single onchain verification call, amortizing the fixed cost across many queries.
​

ZK storage proofs also enable something native proofs cannot: proving a statement about stored data without revealing the data itself. A privacy-preserving eligibility check could prove that a user's balance exceeded some threshold at a block height without disclosing the actual balance. This is relevant for KYC-adjacent applications where the goal is to verify a predicate rather than expose raw state.
​

The ZK proof systems most commonly used for storage proofs are Plonk, Groth16, and STARKs. Plonk and Groth16 are SNARKs with small proof sizes and fast onchain verification but require a trusted setup. STARKs require no trusted setup and have transparent verification but produce larger proofs. The choice between them involves tradeoffs in setup assumptions, proof size, and verifier cost that each protocol has made differently.
​

For a deeper explanation of ZK proof fundamentals and how they interact with blockchain verification, see What Is a Cryptographic Proof? ZK Proofs and Blockchain Verification.
​

External reference: The Axiom documentation provides a concrete description of how ZK circuits are built over Ethereum's Merkle Patricia Trie for onchain queries.
​

Storage proofs solve a narrow but important problem: verifying historical onchain state on a different chain, at a different time, without a trusted intermediary. That narrow capability unlocks several application categories that previously required bridges or oracles. The following use cases are live or in active development on mainnet today.
​

Cross-chain governance. Token-based governance typically requires that voters prove token ownership at a snapshot block. When the governance contract and the token live on different chains, this has historically required bridging the token or using a trusted attestation service. With storage proofs, a voter submits a proof of their L1 token balance at the snapshot block directly to the L2 governance contract. No bridge transaction. No attestation signer. The proof is the vote credential.
​

Trustless oracles. Price oracles on DeFi protocols have been a persistent attack surface because they rely on external parties to post data. A storage proof oracle replaces the signer with a proof. If an onchain TWAP value or reserve balance exists in a contract's storage on one chain, it can be proven on another chain without any intermediary. The verifier trusts the source chain's consensus, not a data provider's signature.
​

Cross-chain NFT ownership gating. NFT-gated applications often need to verify that a user holds a specific token on Ethereum mainnet before granting access on an L2. Storage proofs allow the gating contract on the L2 to verify ERC-721 ownership at a specific block without the user bridging the NFT. The NFT stays on mainnet. The proof travels as calldata.
​

Cross-chain yield and reward distribution. Protocols that distribute rewards based on historical participation often need to verify past state. A storage proof can confirm that an address had a specific deposit balance in an L1 vault at a past block, enabling permissionless reward claims on an L2 without any relayer infrastructure. This pattern is increasingly relevant to stablecoin automation platforms that need to coordinate yield logic across multiple chains.
​

Fraud proof systems. Optimistic rollups use fraud proofs to challenge invalid state transitions. Storage proofs are a component of some fraud proof designs because they allow challengers to prove what the L1 state was at the time of a disputed L2 batch. For more on how fraud proofs work as a broader category, see What Are Fault Proofs in Blockchain.
​

External reference: Snapshot's storage proof voting research documents one of the earliest production uses of cross-chain storage proofs for governance.
​

Several protocols have productized storage proof infrastructure. They differ in the chains they support, the proving system they use, the latency they offer, and the trust assumptions they make for the header oracle component. Understanding these differences matters when choosing which protocol to integrate.
​

Herodotus. Herodotus is the most widely referenced storage proof protocol in the Ethereum ecosystem. It provides storage proof access to Ethereum L1 and L2 historical state from StarkNet and other EVM chains. Its architecture relies on accumulator contracts that ingest and verify block headers onchain, giving downstream contracts a trustless reference point for proof verification. Herodotus has demonstrated proving of arbitrary Ethereum storage slots from StarkNet contracts and is the primary infrastructure layer that StarkNet applications use when they need to read Ethereum mainnet state.
​

Axiom. Axiom focuses on ZK-verified historical queries against Ethereum. Developers submit queries specifying what historical data they need, and Axiom generates a ZK proof of the answer and delivers it onchain. The query interface abstracts away the raw proof mechanics, so application developers interact with a query API rather than constructing Merkle proofs directly. Axiom V2 supports queries over account data, storage slots, transactions, and receipts from any historical Ethereum block.
​

Relic Protocol. Relic provides trustless access to historical Ethereum state through a combination of onchain block hash accumulation and Merkle proof verification. It focuses on EVM-to-EVM use cases, allowing contracts on L2s to verify facts about past Ethereum state. Its block hash oracle stores a running accumulator of Ethereum block hashes that any verifier contract can reference.
​

StarkNet native storage proofs. StarkNet has built storage proof primitives directly into its ecosystem. Because StarkNet uses STARKs for its own proof system, it is well-positioned to verify STARK-based storage proofs at relatively low cost. StarkWare has published research and tooling around proving Ethereum storage slots from within Cairo contracts, and Herodotus is the main infrastructure layer for this. The StarkNet ecosystem has the most mature storage proof tooling as of early 2026.
​

Succinct's SP1 and Telepathy. Succinct Labs built Telepathy as a ZK light client that verifies Ethereum consensus (the Beacon Chain sync committee) onchain, providing a trustless block header oracle. SP1 is their general-purpose zkVM that can be used to build storage proof circuits. Together they form a full stack for ZK-verified cross-chain state proofs.
​

External reference: The Herodotus developer documentation provides the most complete public description of a production storage proof system's architecture and API.
​

Storage proofs are one of three main architectures for bringing external chain data into a smart contract. Oracles and bridges solve overlapping but distinct problems. The table below captures the key differences across five dimensions that matter for application design.
​

Storage proofs are the right choice when the application requires cryptographic certainty about historical onchain state and can tolerate the latency and cost of proof generation. Oracles are the right choice when the data source is offchain (price feeds, weather data) or when latency requirements are tight. Bridges are the right choice when the goal is to move assets or messages in real time rather than verify historical state.
​

Many applications combine all three. A cross-chain yield protocol might use a bridge for asset transfers, an oracle for real-time price data, and storage proofs for historical balance verification. Each tool fills a different part of the trust and latency spectrum.
​

For a detailed comparison of bridge architectures specifically, see What Is a Blockchain Bridge? Cross-Chain Transfers Explained.
​

External reference: Li.Fi's bridge aggregator research compares trust models across bridge designs in more depth.
​

No. Storage proofs can only verify data that was committed to a chain's state trie at a specific block. If a value was never written to a storage slot, there is no proof of its existence to generate. They are a tool for verifying historical onchain state, not for proving facts about the real world or offchain systems.
​

Only chains that use a Merkle or hash-based state commitment scheme and whose block headers are accessible to the verifying chain. Ethereum and its L2 ecosystem are the best-supported. Chains with different state models, like Solana or Bitcoin, require custom proof adapters and are less mature in terms of available tooling.
​

A raw Merkle Patricia Trie proof can be fetched from a full node in milliseconds using eth_getProof. The bottleneck is block finality on the source chain and header delivery to the destination chain. End-to-end latency in production systems is typically 10 minutes to a few hours. ZK proof generation adds seconds to minutes on top of that depending on the circuit and hardware.
​

For single queries, native storage proofs are often more expensive in gas than a bridge relay. ZK proofs reduce this but still cost 200,000 to 300,000 gas per verification. The economics improve with aggregation: a ZK proof that covers 100 storage queries costs the same to verify as one that covers a single query. High-frequency use cases benefit from batching.
​

A state proof is the broader category. It proves something about the chain's state root, which could include account balances, nonces, or code hashes. A storage proof is a subset that specifically proves the value of a contract storage slot within that state. All storage proofs are state proofs, but state proofs also cover account-level data that lives outside contract storage.
​

Methodology: Written from first-principles knowledge of Ethereum state architecture, Merkle Patricia Tries, ZK proving systems, and production storage proof protocols as of April 2026. No live data sources were required; all figures cited (gas costs, proof sizes) reflect published benchmarks from Axiom, Herodotus, and EIP specifications.
​