Storage Proofs for Onchain Governance

How Snapshot X verifies Ethereum voting power

Onchain governance gives DAOs a verifiable record of proposals, votes, and execution that anyone can inspect and recompute. The trade-off has been cost: most governance tokens live on Ethereum L1, where voting directly is expensive enough to push participation offchain.

Snapshot X is a fully onchain voting protocol that brings proposals, voting power computation, and execution into smart contracts while preserving the user experience of the original Snapshot. The primitive that makes this practical for Ethereum-based voting power is Storage Proofs.

The problem: voting power lives on another chain

A DAO may want to run governance on Starknet while its governance token lives on Ethereum. The voting contract on Starknet cannot natively ask Ethereum how much voting power an address held when the proposal started. Blockchains do not read each other's state.

The common workaround is an offchain indexer that computes voting power and reports the result. That works for signaling, but adds a trust assumption.

A Storage Proof lets a contract verify that a specific piece of state existed on another chain at a specific block, without trusting an intermediary. Herodotus Storage Proofs add managed proof generation, historical block access, and onchain verification infrastructure on top of this primitive.

For governance, that means a DAO can verify Ethereum voting power without users bridging tokens.

How Snapshot X uses Storage Proofs

Snapshot X uses Storage Proofs in its Starknet implementation to compute voting power from Ethereum state. The integration calculates voting power from Ethereum mainnet or Sepolia contracts.

At a high level, the flow has five stages:

Proposal opens. The Snapshot X space records the proposal start timestamp.
Timestamp is anchored to an Ethereum block. The corresponding L1 block becomes the checkpoint for voting power.
Operator submits a Storage Proof. The storage root of the voting power source contract is storage proven on the destination chain.
Voter submits a Storage Proof. When voting, the user includes a Storage Proof of their balance at the checkpoint block, which Snapshot X verifies onchain.
The vote is counted. If verification succeeds, voting power is taken from the proven Ethereum state and recorded onchain.

The voting system no longer relies on an indexer to define the electorate. The electorate is derived from proven source-chain state. The exact mechanics, including the supported governance token formats and the verification flow, are documented in the Snapshot X protocol documentation.

The voter experience

For the voter, the experience stays close to offchain voting:

No bridging. Voting power is proven from Ethereum state at the proposal checkpoint. Tokens stay where they are.
No Starknet wallet. Snapshot X has voters sign with their Ethereum wallet, then relays the signed transaction to Starknet through Mana, the Snapshot X transaction relayer.
No gas on the voting chain. DAOs that sponsor relaying fees keep voting gasless from the user's perspective.

Together, these make binding onchain governance compatible with the offchain UX people already know.

Scaling to large electorates

Production deployments avoid generating a Storage Proof per voter, which would be impractical at scale. Instead, a single Herodotus Storage Proof is generated for the contract's storage root at the checkpoint, which is verified and saved onchain, anchoring the Ethereum state. Individual voter balances are then verified against this saved storage root as they cast their vote by including a standard MPT proof from the RPC. The result is that proving cost per vote stays flat regardless of how many addresses participate.

The pattern is documented in the Herodotus voting smart contract example.

What Storage Proofs cover for governance

Storage Proofs are a general-purpose data access primitive. For governance specifically, the data that typically matters is:

ERC-20 token balance at a proposal checkpoint.
Delegated voting power on ERC20Votes/ERC721Votes governance tokens.
Owner of an ERC-721 token.
A custom contract storage slot used by a DAO's voting strategy.

Beyond governance, Storage Proofs cover account balances, storage slot values, block header data, and transaction receipts across Ethereum, Starknet, and other supported chains. See the Storage Proof API documentation for the full coverage matrix.

Snapshot X voting strategies that use Storage Proofs

Snapshot X exposes two voting strategies built on Storage Proofs, both available on Starknet:

EVM slot value. Reads any storage slot on an EVM chain (ERC-20 balance, ERC-721 ownership, custom slot) and verifies it on L2 with a Storage Proof.
OZ Votes storage proof. Verifies delegated voting power on ERC20Votes/ERC721Votes tokens. Refer to the Snapshot X docs for the supported OpenZeppelin format details.

Setup involves pointing the strategy at the Ethereum contract address and slot index. Herodotus provides Storage Slot Explorer as a helper for locating slot indices.

Storage Proofs versus a ZK coprocessor in governance

Storage Proofs answer one question: did this data exist onchain at this block? For most governance strategies, that is enough. The contract needs to know whether an address had a token balance, delegated voting power, or NFT ownership at the checkpoint.

A ZK coprocessor adds a programmable compute layer on top, answering: what is the result of running this program over verified onchain state? That matters for governance rules with aggregations or multi-step logic, like time-weighted voting power, multi-chain balance aggregation, historical participation scores, or eligibility computed across many storage slots. In the Herodotus stack, Storage Proofs provide the trustless data layer, and the Herodotus Data Processor (HDP) is the programmable compute layer built on top.

Snapshot X is a clean example of the first category: Storage Proofs make source-chain voting power verifiable on the voting chain, no additional computation needed.

Snapshot X in production

Starknet used Snapshot X for its first onchain governance vote on mainnet, held September 10 to 13, 2024. The vote ran through the Starknet Governance Hub and used Herodotus Storage Proofs to authenticate STRK voting power at a defined snapshot date, including support for users holding STRK on Ethereum.

This is the pattern Storage Proofs were designed for: the source of truth remains Ethereum state, computation and voting happen in a lower-cost environment, users do not bridge tokens, and the governance system does not rely on a server to report voting power. The proof connects the two.

Security and audits

Both sides of the integration have been independently audited.

Snapshot X has completed three public audits: Snapshot X EVM by ChainSecurity (July 2023), Snapshot X Starknet by OpenZeppelin (October 2023), and Snapshot X EVM Cairo by Security Clan (June 2025). All three reports are available in the Snapshot X protocol documentation.

The Herodotus contracts that underpin the integration on Starknet have been audited by ChainSecurity, including the Cairo libraries used for proof verification. ChainSecurity has also published a public technical review of Herodotus' Merkle Mountain Range implementation.

FAQ

Why does Snapshot X use Storage Proofs?

Most governance tokens live on Ethereum, but voting on mainnet is expensive enough to discourage smaller holders. Snapshot X runs voting on Starknet for cost efficiency and uses Storage Proofs to verify voting power against Ethereum state, avoiding both bridge dependence and trust in an offchain indexer.

Do voters need to bridge their tokens?

No. Voting power is proven from Ethereum state at the proposal checkpoint. Tokens stay on the source chain.

Do voters need a Starknet wallet?

No. Snapshot X has voters sign with their Ethereum wallet. The signed transaction is relayed to Starknet through Mana, the Snapshot X transaction relayer. DAOs that sponsor relaying fees keep voting gasless.

Which Snapshot X voting strategies use Storage Proofs?

The EVM slot value strategy and the OZ Votes storage proof strategy, both available on Starknet. The first reads any storage slot on an EVM chain. The second verifies delegated voting power on ERC20Votes/ERC721Votes governance tokens. Setup details and supported formats are in the Snapshot X documentation.

Has this been audited?

Yes, on both sides. Snapshot X has completed audits with ChainSecurity, OpenZeppelin, and Security Clan, with reports published in the Snapshot X documentation. The Herodotus Storage Proofs infrastructure has been audited by ChainSecurity. Audits are point-in-time and complement other security practices.

Can a DAO use Storage Proofs for governance without Snapshot X?

Yes. Snapshot X is one implementation. The Herodotus Storage Proof API and Satellite contracts integrate directly into any voting contract. The voting smart contract example in the Herodotus documentation shows the end-to-end pattern.

What is the difference between Storage Proofs and a ZK coprocessor for governance?

Storage Proofs verify that specific data existed onchain at a specific block, which is enough for most voting strategies. A ZK coprocessor (in the Herodotus stack, HDP) adds a verifiable compute layer for governance rules with aggregations or computation, like time-weighted voting power or multi-chain balance aggregation.

Which chains does this work on?

The Snapshot X integration is currently on Starknet, with source-chain proofs from Ethereum mainnet or Sepolia. Storage Proofs more broadly support additional source and destination chains, e.g. Base, Arbitrum, Optimism or World Chain; see the Storage Proof API documentation for the full deployment matrix.

Start building with Storage Proofs

Herodotus Storage Proofs are live on mainnet, available through the Herodotus Cloud console. Request proofs through the Storage Proof API, consume verified data through Satellite contracts, and build applications that use Ethereum state across chains and across time.

Explore the Storage Proof API documentation, learn how Satellite contracts expose verified data onchain, or review the voting smart contract example to see how historical balances power governance logic.