How to Implement Snapshot Voting Across Multiple Networks

Snapshot is the leading off-chain voting platform for DAOs, enabling gasless, flexible governance. Its core innovation is the separation of the voting signal from on-chain execution. A multi-chain strategy is essential for protocols deployed across networks like Ethereum, Arbitrum, and Polygon, as it allows a single, unified community to govern assets and parameters on all chains from one voting interface. This guide explains how to structure your space, configure voting strategies, and manage proposal execution across a fragmented deployment.

The foundation of multi-chain governance is the voting strategy. A strategy is a piece of logic that defines how voting power is calculated. For a single-chain DAO, this is often a simple ERC-20 or ERC-721 balance check. For multi-chain, you must aggregate balances across networks. Snapshot supports this through multi-strategies. You can create a custom strategy that queries token balances from the same contract address on multiple EVM chains (e.g., checking $GOV token holdings on Ethereum Mainnet and Optimism) and sums them to produce a single, cross-chain voting power score for each voter.

Implementing a custom multi-chain strategy requires writing a JavaScript function for the Snapshot strategy playground. The function uses the Snapshot.js utilities to make multicall queries to the token contract on each specified chain. Here is a simplified example:

javascriptCopy
async function strategy(space, network, provider, addresses, options) {
  const scores = await Promise.all(
    options.addresses.map(async (chainAddress) => {
      const multi = new MultiCall(provider, chainAddress);
      const calls = addresses.map((address) => [
        options.address, 'balanceOf', [address]
      ]);
      const response = await multi.all([calls]);
      return response[0].map((b) => b / 1e18);
    })
  );
  return scores.reduce((a, b) => a.map((v, i) => v + b[i]), Array(addresses.length).fill(0));
}

This function fetches balances for a list of addresses from the token contract (options.address) on multiple chain RPC endpoints (options.addresses), normalizes the decimals, and sums the results.

After deploying your strategy, you must configure your Snapshot space settings. In the space's settings, you select your custom multi-strategy and define the network parameters (chain IDs, contract addresses). Crucially, you also configure the execution layer. This involves setting up a Safe Snapshot Transaction Builder or similar plugin for your multisig (like a Gnosis Safe on each chain). When a proposal passes, the approved transaction data is relayed to the respective multisig on the target chain for execution. This decouples the cheap, fast voting from the potentially expensive and slower on-chain execution.

Key considerations for a production system include voting power synchronization (handling token bridges and staking derivatives), proposal lifecycle management (defining timelocks and execution windows per chain), and security. Always use a validation strategy to restrict proposal creation to authorized addresses, often a multisig or a governance module. For maximum resilience, consider using a cross-chain messaging protocol like Axelar or LayerZero for automated execution, moving beyond manual multisig relay, though this introduces smart contract risk to the execution step.

Successful implementations include Convex Finance (governing incentives across Ethereum and sidechains) and Aave (managing risk parameters on multiple networks). Start by testing your strategy extensively on Snapshot's testnet (https://testnet.snapshot.org) and use a staging space. The final system creates a seamless experience: a community member votes once in Snapshot using their aggregate token balance, and the resulting instructions are executed on the appropriate chains, maintaining coherent governance over a multi-chain ecosystem.

Implementing a multi-chain Snapshot strategy requires a foundational understanding of the Snapshot architecture and its core components. At its heart, Snapshot is an off-chain, gasless voting platform that uses signed messages to record votes. The critical elements are the Space (your DAO's voting hub), Strategies (the logic that calculates voting power), and Proposals. For cross-chain governance, you must write a custom strategy that can query and aggregate a user's token holdings or other credentials from multiple blockchain networks. This setup assumes you have a deployed token contract on at least two networks and basic familiarity with JavaScript/TypeScript and the Snapshot developer docs.

Your primary development tool will be the Snapshot Strategy Template. Clone the official repository from GitHub (snapshot-labs/snapshot-strategies) to use as a starting point. The key file you will modify is src/strategies/your-strategy-name/index.ts. A strategy must export an author, version, and an asynchronous strategy function. This function receives the space name, network ID, addresses, and snapshot block number, and must return a Promise that resolves to an object mapping voter addresses to their calculated voting power. For multi-chain logic, you will need to import and use network-specific providers or SDKs like ethers.js or viem.

The core technical challenge is aggregating data from multiple Remote Procedure Call (RPC) endpoints. Your strategy function must connect to different networks based on the provided network parameter (e.g., '1' for Ethereum Mainnet, '42161' for Arbitrum One). You will typically use a library like ethers to create multiple provider instances. A basic pattern involves defining a network configuration object mapping chain IDs to their RPC URLs, then looping through them to fetch token balances via the ERC-20 balanceOf function at the specified snapshot block. Remember to handle errors for individual network calls to ensure one failing RPC doesn't break the entire voting power calculation.

After writing your strategy, you must test it locally before submitting to Snapshot. Use the npm run test command in the strategy repository, which will run your code against mock data. For more realistic testing, you can use the Snapshot Playground at https://snapshot.org/#/playground. Here, you can paste your strategy code, specify a space, network, and addresses, and see the calculated scores. This step is crucial for verifying that your multi-chain queries return the correct aggregated balances. Ensure your strategy correctly handles edge cases like addresses with zero balance on some chains.

Once tested, you need to make your strategy available for your DAO's Space to use. Fork the snapshot-strategies repository on GitHub, add your strategy in a new directory under src/strategies/, and submit a Pull Request to the upstream repository. After the Snapshot team reviews and merges it, the strategy will be available to all Spaces. Alternatively, for immediate or private use, you can host the strategy file yourself on a public URL (like GitHub Gist or IPFS) and enter that URL directly in your Space's settings under the 'Strategies' section. Your Space can then create proposals that use this new multi-chain voting power strategy.

To begin, navigate to snapshot.org and connect your wallet. You will need to be the owner of the wallet that holds the governance token for your DAO. Click "Create a space" and enter a unique identifier, which will become your space's URL (e.g., yourdao.eth or yourdao.snapshot.org). This name is permanent, so choose carefully. You'll then be prompted to set basic information like a display name, avatar, and a cover image to brand your governance portal.

The core of your space's configuration is the Strategies and Networks settings. Strategies define how voting power is calculated. For multi-chain governance, you must add a strategy for each network where your token resides. For example, if your GOV token exists on Ethereum Mainnet and Arbitrum, you would add two erc20-balance-of strategies. Each strategy is configured with the token's contract address and the corresponding blockchain network ID (e.g., 1 for Ethereum, 42161 for Arbitrum). Snapshot will aggregate voting power from all specified chains.

Next, configure the Voting settings. You must select a voting system; single-choice and weighted are common for straightforward proposals. Set the quorum (the minimum total voting power required for a proposal to be valid) and the vote duration (typically 3-7 days). It's critical to align these parameters with your DAO's governance charter. For security, enable vote validation to prevent duplicate voting across chains and consider setting a proposal threshold to restrict proposal creation to members with a minimum token balance.

Finally, you must define the Admins and Moderators. Admins have full control over space settings and strategies. It is a best practice to use a multisig wallet or a DAO treasury address as the admin, not a single private key, to enhance security. Moderators can edit proposal content and pin discussions. Once all settings are complete, review them thoroughly and publish the space. Your Snapshot Space is now live and ready to accept its first cross-chain proposal.

The core challenge of cross-chain voting is proving a user's token holdings on a source chain (e.g., Ethereum) to a voting contract on a destination chain (e.g., Arbitrum). This requires a verifiable, trust-minimized data bridge. The standard approach uses Merkle proofs and a centralized oracle or light client bridge to relay state. First, a snapshot of token balances is taken on the source chain at a specific block height. This data is aggregated into a Merkle tree, where each leaf contains a user's address and balance. The Merkle root is then published and made available for verification on the destination chain.

On the destination chain, the voting contract must verify user-submitted proofs. A user constructs a Merkle proof from the snapshot data, which includes their leaf node (address + balance) and the sibling hashes needed to recompute the root. The contract hashes the user-provided leaf and uses the proof to calculate a resulting root. It then checks this computed root against the authorized snapshot root stored in the contract. This cryptographic verification ensures the balance claim is authentic without the destination chain needing direct access to the source chain's state.

Key implementation details involve managing the snapshot root. Typically, a multi-sig wallet or a decentralized oracle network like Chainlink is responsible for posting the root to the destination chain contract. Security depends entirely on the trustworthiness of this root publisher. For higher security, projects can implement a light client relay (e.g., using IBC or LayerZero's Ultra Light Node) that validates block headers, allowing the destination chain to verify the inclusion of the state root itself. The voting contract function might look like this:

solidityCopy
function voteWithProof(bytes32[] calldata proof, uint256 balance) public {
    bytes32 leaf = keccak256(abi.encodePacked(msg.sender, balance));
    require(MerkleProof.verify(proof, snapshotRoot, leaf), "Invalid proof");
    _castVote(msg.sender, balance);
}

Considerations for multi-token governance add complexity. If voting power is derived from multiple tokens or across multiple chains, you must create a unified Merkle tree or use separate verifications. One method is to create a combined snapshot where each leaf encodes the user's address and a packed struct of balances (e.g., balanceTokenA, balanceTokenB). Alternatively, you can run separate verification steps for each asset and sum the validated balances in the voting contract. This requires careful design to prevent double-counting or manipulation across different proof submissions.

Finally, you must handle edge cases and stale data. Implement a snapshot expiry mechanism to invalidate old roots and prevent replay attacks. Clearly communicate the snapshot block number to users, as balances taken from a different block will produce invalid proofs. For a production system, consider using established libraries like OpenZeppelin's MerkleProof and auditing the entire flow—from snapshot generation and root publication to proof verification and vote tallying. This ensures the cross-chain governance mechanism is both functional and resistant to manipulation.

A voting strategy in Snapshot is a smart contract that defines how a user's voting power is calculated for a specific proposal. For multi-chain governance, you need a strategy that can query and combine data from several networks. The strategy contract implements a single function: getVotingPower. This function takes parameters like the voter's address, the snapshot block number, and the proposal's network ID, then returns an integer representing their voting power. Strategies are deployed on the same chain where the Snapshot space is hosted, typically Gnosis Chain (xDai) or Ethereum Mainnet for gas efficiency and reliability.

To build a cross-chain strategy, you must design a data-fetching logic that can operate across networks. A common pattern involves using Chainlink's CCIP or specialized oracle networks like Pyth or Witnet to fetch on-chain state (e.g., token balances) from remote chains. Alternatively, you can use a multi-sig relayer or a light client bridge to verify proofs of state from other chains. Your getVotingPower function would call these oracles or verify submitted proofs to retrieve the user's balance on Ethereum, Arbitrum, and Polygon, then sum them to produce a total. This requires careful handling of different token decimals and ensuring data freshness via the snapshot block.

Here is a simplified Solidity example for a strategy that sums balances of the same ERC-20 token (GOV) deployed on three networks. It uses a mock oracle interface for demonstration. The key is that the main logic resides on one chain but pulls verified data from others.

solidityCopy
interface ICrossChainOracle {
    function getBalanceAtBlock(address user, uint256 blockNumber, uint256 chainId) external view returns (uint256);
}

contract MultiChainVotingStrategy {
    ICrossChainOracle public oracle;
    address public govToken;
    uint256[] public chainIds; // e.g., [1, 42161, 137] for Eth, Arbitrum, Polygon

    function getVotingPower(
        address voter,
        uint256 snapshotBlock,
        bytes calldata
    ) external view returns (uint256) {
        uint256 totalPower = 0;
        for (uint i = 0; i < chainIds.length; i++) {
            totalPower += oracle.getBalanceAtBlock(voter, snapshotBlock, chainIds[i]);
        }
        return totalPower;
    }
}

After developing and auditing your strategy contract, deploy it to the desired network. You must then register it with your Snapshot space. Navigate to your space's settings on snapshot.org, go to the "Strategies" section, and add a new strategy. Provide the contract address, ABI, and necessary configuration like the chainIds array. Once added, you can select this custom strategy when creating a new proposal. Voters' power will be calculated by Snapshot's off-chain indexer, which calls your contract's getVotingPower function, enabling seamless multi-chain voting without users needing to bridge assets.

Consider these critical factors for production use: gas costs for on-chain verification, data latency from oracles, and security of the cross-chain data source. An insecure oracle can manipulate vote outcomes. For maximum decentralization, consider using optimistic verification schemes or zero-knowledge proofs of state, though these are more complex to implement. Always test your strategy thoroughly on testnets like Sepolia and Goerli using Snapshot's test interface. Properly implemented, a custom multi-chain strategy unlocks governance for fragmented token holdings, increasing voter participation and ensuring decisions reflect the true cross-chain community.

A Snapshot proposal is defined by a JSON object containing metadata, voting parameters, and the core proposal text. For cross-chain voting, the strategies array is critical. Instead of a single strategy like erc20-balance-of, you will use a multi-chain strategy such as multichain or a custom one that aggregates voting power from specified contracts across different networks. The proposal's network field must be set to 1 (Ethereum Mainnet) as Snapshot's hub, but the strategies will pull data from the L2s or sidechains you define. Here is a basic proposal schema for a vote spanning Ethereum and Arbitrum:

jsonCopy
{
  "space": "your-dao.eth",
  "type": "single-choice",
  "title": "Proposal: Fund New Grants Round",
  "body": "This proposal allocates 50,000 USDC from the treasury to fund Q4 grants.",
  "choices": ["Yes", "No", "Abstain"],
  "start": 1698768000,
  "end": 1699372800,
  "snapshot": 1698767500,
  "network": "1",
  "strategies": [
    {
      "name": "multichain",
      "params": {
        "strategies": [
          {
            "name": "erc20-balance-of",
            "network": "1",
            "params": {
              "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
              "symbol": "USDC",
              "decimals": 6
            }
          },
          {
            "name": "erc20-balance-of",
            "network": "42161",
            "params": {
              "address": "0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8",
              "symbol": "USDC",
              "decimals": 6
            }
          }
        ]
      }
    }
  ],
  "plugins": {}
}

Before submitting a live proposal, you must test it thoroughly. The most effective method is to use Snapshot's local test suite or fork a network locally. First, clone the Snapshot Hub repository and follow the setup instructions to run a local instance. This allows you to simulate proposal creation and voting without spending gas or affecting live spaces. Use a tool like Hardhat or Foundry to fork the mainnet and your target L2 (e.g., Arbitrum) at a specific block number. This creates a local environment where you can mint test tokens to addresses and verify that the multi-chain strategy correctly calculates voting power from both networks.

With your local Snapshot hub and forked networks running, you can create a test proposal using the same JSON structure. Use the Snapshot.js SDK or direct API calls to your local hub endpoint (http://localhost:3000). The key is to ensure the snapshot block number in your proposal exists on your local fork. Cast test votes from addresses that hold tokens on the forked chains and verify the voting power snapshot is accurate. Check the proposal results to confirm the multi-chain aggregation works. This process validates your strategy configuration and reveals issues like incorrect network IDs, contract addresses, or decimal handling before a real deployment. Always test edge cases, such as voters holding tokens on only one of the chains.