Snapshot Interoperability

The custom strategy is the core security module. It defines how voting power is calculated from cross-chain data. A bug or malicious logic in this code can subvert the entire vote. Key audit points include:

• Data source integrity: Verifying the authenticity of messages from the source chain.
• Math correctness: Ensuring calculations for balances, delegation, and time-weighted logic are accurate.
• Failure modes: Defining behavior if the bridge or oracle fails (e.g., revert vote, use last known state). Thorough auditing and formal verification of these strategies is non-negotiable.

Snapshot votes are signed off-chain, but the data they reference (e.g., token balances) is on-chain and subject to chain reorganizations. If a source chain experiences a re-org after a vote is cast but before it's executed, the voter's eligibility or voting power may change, invalidating the vote signature. Strategies must account for this by:

• Referencing block numbers with sufficient finality (e.g., Ethereum's 64+ blocks).
• Implementing challenge periods or using finalized state proofs where possible.

The core Sybil resistance of a token-based DAO can be diluted if the interoperable strategy is poorly designed. Attackers may exploit differences in tokenomics or security models between chains. Considerations include:

• Double-counting prevention: Ensuring the same underlying asset (e.g., a bridged token) cannot vote on multiple chains simultaneously.
• Cost-of-attack analysis: The cost to acquire voting power may be lower on a chain with weaker security or cheaper tokens.
• Delegation consistency: Managing delegate registries that may differ across connected chains.

For votes that trigger on-chain execution (via Snapshot X or similar), the execution path becomes a critical attack surface. This involves:

• Multisig or relayer security: The entity or smart contract that broadcasts the winning transaction must be highly secure and decentralized.
• Timelock alignment: Execution delays must be synchronized across all affected chains to prevent front-running or inconsistent state changes.
• Payload validation: Ensuring the calldata for the cross-chain execution is correctly derived from the vote outcome and cannot be tampered with in transit.

Voters must sign messages with the private key that holds voting power, which may be spread across multiple chains. This creates UX and security challenges:

• Cross-chain signature requests: Wallets must safely handle signing requests for actions on a different chain than the one currently active.
• Key fragmentation: Voting power may be held in different wallets on different chains, requiring multiple signatures or complex key aggregation.
• Phishing risks: Increased complexity can lead to user confusion and phishing attacks mimicking cross-chain voting interfaces.

Allows DAOs to create governance proposals for actions on any supported blockchain. A single proposal can bundle actions across multiple chains, such as a treasury reallocation involving assets on Ethereum, Arbitrum, and Polygon. This is enabled through EIP-712 typed data signing and integrations with cross-chain messaging protocols.

The core mechanism enabling cross-chain voting power aggregation. Developers create custom voting strategies that query on-chain data from any network. Common strategies include:

• ERC-20 Votes: Tally token balances across multiple chains.
• ERC-721: Count NFT holdings for membership-based voting.
• Delegation: Respect token delegation on the native chain (e.g., Compound, Uniswap).

After a Snapshot vote passes, the approved actions must be executed on their respective chains. This relies on integrations with cross-chain messaging protocols like:

• Gnosis Safe's Zodiac Bridge
• Connext
• Axelar These protocols translate the off-chain vote result into a verifiable, executable on-chain transaction, often requiring a multisig or relayer network for finalization.

Each DAO configures its Snapshot Space to define its governance parameters across chains. Key settings include:

• Networks: The list of supported blockchains (e.g., Mainnet, Arbitrum, Optimism).
• Strategies: The plugins that determine voting power for each network.
• Admins: The multisig or contract allowed to update settings. This configuration allows a single Space to govern a multi-chain treasury and protocol.

A prime example of Snapshot Interoperability in production. The Uniswap DAO uses a single Snapshot space to govern its deployment across Ethereum, Polygon, Arbitrum, and Optimism. Their voting strategy aggregates UNI token balances across all these chains, allowing tokenholders to vote on proposals affecting the entire multi-chain protocol with a single, unified vote.

Successful interoperability depends on specific technical foundations:

• Chain Indexers: Reliable RPC nodes and indexers (like The Graph) for each supported network to query token balances.
• Signature Verification: The Snapshot hub must verify EIP-712 signatures are valid for the voter's address on the correct chain.
• Execution Security: The separation between off-chain voting and on-chain execution introduces a trust assumption in the chosen cross-chain bridge or executor.

A governance model where proposals, voting, and execution can span multiple independent blockchains. Snapshot interoperability is a foundational technology for this, allowing a DAO on one chain to manage assets or protocols on another. Key implementations include:

• Omnichain DAOs: A single DAO treasury and membership governing assets across multiple chains.
• Delegated Execution: Voting occurs on a primary chain, with the resulting instructions relayed to a target chain via a bridge or message protocol.

Cryptographic proofs that verify the state of one blockchain (like a finalized vote tally) for consumption by another system. These are the core data packets for interoperability. Common types include:

• Merkle Proofs: Prove the inclusion of a transaction (e.g., a vote) in a specific block.
• Zero-Knowledge Proofs (ZKPs): Succinctly prove the validity of a state transition (e.g., a correct vote count) without revealing all underlying data, enhancing privacy and efficiency.

The general category of protocols that facilitate communication between blockchains, which snapshot data relies upon. This includes both bridges and messaging layers. Critical considerations for governance are:

• Security Models: Ranging from optimistic to cryptoeconomic to externally verified.
• Data Authenticity: Ensuring the message containing the snapshot is an accurate and untampered representation of the source chain's state.

The separation of the governance signaling layer from the execution layer. Snapshot interoperability is a key enabler, allowing users to vote in a single, familiar interface while actions are performed across diverse environments. Benefits include:

• Improved UX: Voters interact with one frontend and token standard.
• Reduced Fragmentation: Consolidates voting power that is spread across multiple chains.
• Execution Flexibility: The same vote can trigger actions on Ethereum, L2s, and other ecosystems.

Two prominent generic messaging protocols that enable snapshot interoperability by allowing arbitrary data, including governance proofs, to be passed between chains.

• Wormhole: Uses a network of Guardian nodes to attest to message validity.
• LayerZero: Employs an Ultra Light Node model with independent Oracle and Relayer services. Both are widely integrated by cross-chain governance platforms like Stargate Finance and various DAO tooling providers to execute decisions across ecosystems.