Cross-Chain State Verification
The Problem: Smart Contracts Cannot Read Other Chains
Smart contracts can only access data on their own chain. A contract on Arbitrum cannot query an Ethereum balance. A contract on Starknet cannot check an Optimism storage slot. A contract on Base cannot verify that a transaction was included on Ethereum Mainnet three hours ago.
This is a fundamental constraint of blockchain architecture. Each chain maintains its own state, and there is no native mechanism for one chain's contracts to verify another chain's data.
Yet cross-chain data access is essential for a growing number of applications: lending protocols that need to verify collateral on a different chain, governance systems that need to check token holdings across networks, compliance checks that require a view of activity spanning multiple chains, and any application where the source of truth lives on a chain other than the one executing the logic.
Cross-chain state verification is the infrastructure that closes this gap.
How Cross-Chain State Verification Works Today
Most cross-chain data access today relies on one of three approaches, each with its own trust model:
Bridges and relayers. A relayer watches for events on the source chain and submits them to the destination chain. Security depends on the honesty of the relayer set or a multisig committee. If the relayer is compromised or colludes, the destination chain accepts false data. Bridge exploits have resulted in billions of dollars in losses across the industry.
Oracles. An oracle network observes on-chain data, signs an attestation, and delivers it to the destination chain. The consuming contract trusts that the oracle's signers reported the data accurately. This works for many use cases but introduces a trust assumption on the signer set.
Messaging protocols. Cross-chain messaging systems (LayerZero, Axelar, Wormhole, Chainlink CCIP) pass arbitrary messages between chains. Verification varies by protocol but typically relies on external validators, optimistic fraud windows, or decentralized oracle networks. These systems are powerful and general-purpose, but they add an attestation layer between the source data and the consuming contract.
All three approaches share a common property: the consuming contract does not verify the source data directly. It trusts that an intermediary reported it correctly.
A Different Approach: Cryptographic State Verification
Storage Proofs offer a fundamentally different trust model. Instead of relying on an intermediary to attest that data is correct, a Storage Proof lets the destination contract verify the data itself using cryptographic inclusion proofs anchored to block headers.
Ethereum and EVM-compatible chains store all state (account balances, contract variables, transaction receipts) in Merkle Patricia Tries. Every block header commits to the root of these tries. A Storage Proof traces the Merkle path from the trie root to the specific value being verified, proving that the value was present in the source chain's state at a given block height.
Zero-knowledge proofs compress this verification so that it can be checked on-chain efficiently, without the destination contract processing the full trie data.
The result: the consuming contract on the destination chain verifies the source chain's data using math, not trust. The data is either correct or the proof is invalid. There is no signer, no relayer, and no committee in the path.
How Herodotus Enables Cross-Chain State Verification
Herodotus provides managed infrastructure for generating, delivering, and verifying Storage Proofs across chains. The system consists of three components:
Storage Proof API. Request a proof for any supported data type (account balance, storage slot, block header property, transaction receipt) on a given source chain and block number. The API handles proof generation, scheduling, and cost mutualization.
Historical Block Hash Accumulator. On-chain commitments (built with STARK proofs and Merkle Mountain Ranges) that cover every Ethereum block hash back to genesis. This extends the verifiable window far beyond the EVM's native 256-block limit, enabling cross-chain verification of historical state at any depth.
Satellite contracts. On-chain verification and read interfaces deployed on destination chains. When a proof is ready, the consuming smart contract reads the verified value from the Satellite contract with the same trust guarantees as reading native on-chain state.
Developers do not need to understand cryptography, run provers, or operate relay infrastructure. The API abstracts the proof pipeline. The developer requests a proof, and the destination contract consumes a verified result.
What You Can Verify Across Chains
Herodotus Storage Proofs support cross-chain verification of:
Account state. Balance, nonce, code hash, and storage root of any account on a supported source chain.
Storage slot values. Any contract variable at a known slot index, including ERC-20 balances, mapping entries, governance snapshots, and struct fields.
Block header properties. Timestamp, block number, state root, transactions root, gas used, base fee per gas, and more.
Transaction and receipt data. Transaction inclusion, log events, and receipt status.
Supported origin chains include Ethereum Mainnet, Starknet, Optimism, Base, and ApeChain. Supported destination chains include Starknet, Arbitrum, Base, Optimism, ApeChain, World Chain, and others. Testnets are available for development.
Use Cases
Cross-chain lending. Verify that a borrower holds sufficient collateral on Ethereum before issuing a loan on Arbitrum or Base. No bridge deposit required. No oracle attestation needed.
Cross-chain governance. Confirm token holdings on Ethereum at a specific snapshot block, then allow the holder to cast a vote on Starknet or another L2 without transferring tokens.
Proof of reserves. Demonstrate on-chain that an entity held specific assets on a source chain at a specific time. Useful for exchanges, stablecoin issuers, and any protocol that needs provable reserve attestation.
Asset bridging verification. Verify that assets were locked on the origin chain before minting equivalent assets on the destination chain, using cryptographic proofs instead of relayer attestations.
Cross-chain identity and credentials. Prove that an address meets specific criteria (balance thresholds, activity history, contract interactions) on one chain, then use that proof to unlock access on another.
FAQ
How is this different from a cross-chain bridge?
A bridge moves assets or messages between chains, typically through a relayer or validator committee that attests to events on the source chain. Storage Proofs do not move assets. They prove that specific state exists on the source chain so that a contract on the destination chain can act on that information trustlessly. The trust model is cryptographic, not social.
How is this different from a cross-chain messaging protocol?
Messaging protocols (LayerZero, Axelar, Wormhole, Chainlink CCIP) pass arbitrary messages between chains and use various attestation mechanisms to verify them. Storage Proofs verify source-chain state directly via Merkle inclusion proofs and zero-knowledge proofs, with no external attestation layer. The two approaches serve different use cases: messaging is general-purpose, while Storage Proofs are optimized for trustless state reads.
Can I verify historical state, not just the current block?
Yes. The Herodotus Historical Block Hash Accumulator covers every Ethereum block since genesis. You can verify state from any historical block, not just the most recent 256.
What if I need to compute over cross-chain data, not just read it?
Storage Proofs verify that specific data exists. If you need to run computations over that data (aggregations, time-weighted averages, multi-block analytics), the Herodotus Data Processor (HDP) provides a provable runtime on top of Storage Proofs.
Which chains are supported?
See the documentation for the full deployment matrix of supported origin and destination chains.
Start Verifying Cross-Chain State
Herodotus Storage Proofs are live on mainnet. Explore the Storage Proof API documentation, access the console, or contact the team for integration support.