How to Implement Snapshot Voting for Gas-Free Asset Governance

Snapshot is an off-chain, gas-free voting platform that has become the standard for DAO governance. It allows communities to create and vote on proposals without paying transaction fees, using a simple cryptographic signature mechanism. Votes are weighted by token or NFT holdings at a specific block height, recorded on IPFS, and verified by the community. This model is ideal for frequent, low-stakes signaling and has been adopted by major protocols like Uniswap, Aave, and Yearn Finance for their governance processes.

To create a Snapshot space, you first need an ENS domain (e.g., my-dao.eth) and delegate its resolution to the Snapshot contract. The space is configured via a settings.json file hosted on IPFS, which defines the voting strategies, admins, moderators, and voting parameters. A core concept is the voting strategy, which determines voter eligibility and weight. Common strategies include erc20-balance-of (for fungible tokens), erc721-with-multiplier (for NFTs), or a custom strategy contract for more complex logic like time-locked tokens.

Here is a basic example of a space configuration file (settings.json):

jsonCopy
{
  "name": "My DAO",
  "network": "1",
  "strategies": [
    {
      "name": "erc20-balance-of",
      "params": {
        "address": "0x...",
        "symbol": "GOV",
        "decimals": 18
      }
    }
  ],
  "admins": ["0x..."],
  "symbol": "GOV"
}

This setup allows holders of the GOV token at the specified Ethereum address to vote, with their voting power equal to their token balance at the proposal's snapshot block.

Creating a proposal involves defining a title, body (often using markdown), choices (e.g., For, Against, Abstain), and a snapshot block number. The voting period is set, and voters can then cast their votes by signing a message with their wallet—no gas required. The results are calculated off-chain and displayed on the Snapshot interface. For execution, many DAOs use a multisig or a governance module (like OpenZeppelin Governor) to enact proposals that pass the Snapshot vote, creating a two-step process: off-chain signaling followed by on-chain execution.

While Snapshot is highly efficient, it introduces a trust assumption: voters must trust the space admins and the integrity of the off-chain data. Best practices include using multiple, verifiable strategies, transparently documenting proposal processes, and ensuring the snapshot block is sufficiently old to prevent manipulation. For critical treasury movements or contract upgrades, combining Snapshot signaling with a timelock-enforced on-chain execution via a contract like Compound's Governor Bravo provides a robust security model.

Implementing Snapshot voting requires a foundational understanding of decentralized governance and the specific on-chain assets you intend to govern. The core prerequisites are: a wallet with administrative rights over the asset's smart contract (e.g., the owner of an ERC-20 token contract), a basic grasp of EVM-based blockchain concepts, and familiarity with IPFS (InterPlanetary File System) for decentralized proposal storage. You do not need to write any smart contracts for the voting logic itself, as Snapshot provides this infrastructure.

The first technical step is to connect your wallet to the Snapshot interface. Use the wallet that holds the administrative keys for your governance token or NFT contract. Navigate to the 'Create a space' section. A 'space' in Snapshot is a dedicated hub for your project's proposals and votes. You will need to provide a unique space name (like yourproject.eth), a logo, and designate at least one wallet address as a space controller or admin.

Next, you must define your voting strategy by specifying the contract address of your governance token and the blockchain network it resides on (e.g., Ethereum Mainnet, Polygon, Arbitrum). Snapshot uses 'strategies' to determine voter eligibility and voting power. The most common is the erc20-balance-of strategy, which assigns voting power based on a user's token balance at a specific block number. You configure this in your space's settings, linking directly to your token's contract.

For votes to be truly gas-free and trustless, you must enable off-chain signing via EIP-712. This standard allows users to sign structured messages (their votes) with their private keys without submitting an on-chain transaction. Ensure your space settings have 'EIP-712' enabled. All proposal data and vote signatures are then stored on IPFS, creating a verifiable, immutable record that can be validated against the on-chain token snapshot if needed.

Finally, test your setup thoroughly in a staging environment before going live. Create a test proposal and simulate voting using different wallets holding your governance token. Verify that voting power is calculated correctly and that the results are displayed accurately. This setup phase is critical, as the space admins and configured strategies form the security and functional backbone of your entire governance process.

Snapshot is a decentralized, off-chain voting platform that allows token-based communities to govern without paying transaction fees. It uses a signed message-based system where users vote by signing a message with their wallet, which is then recorded on IPFS. This approach separates the signal-gathering phase from the costly on-chain execution, making governance accessible to all token holders regardless of their ETH balance. Votes are weighted by the user's token balance at a specific block height, ensuring a fair snapshot of community sentiment.

To create a space on Snapshot, you first need an ENS domain (e.g., myproject.eth) and delegate ownership of it to the Snapshot contract. The space's settings, defined in a space.json file, configure key parameters: the voting strategies (e.g., erc20-balance-of, erc721-with-multiplier), voting types (single-choice, weighted, quadratic), and proposal thresholds. For an ERC-20 token, a basic strategy might be {"name":"erc20-balance-of","params":{"address":"0x...","symbol":"GOV","decimals":18}}. This strategy will check each voter's balance at the proposal's snapshot block.

Writing a clear proposal involves structuring the body with a title, description, and choices. Snapshot supports Markdown formatting. The most critical technical detail is setting the snapshot block number. This block, typically a recent block before the proposal is created, freezes the token distribution used for vote weighting. This prevents manipulation via token buying or selling after the proposal is live. You can also set voting periods, quorum requirements, and delegation options within the proposal creation interface.

Once a voting period ends, the off-chain result is final. To move a decision on-chain, you need an executor. This is typically a multisig wallet or a DAO smart contract like a Governor from OpenZeppelin. The executor's role is to trust the Snapshot result and execute the corresponding transaction. For example, if a vote passes to transfer 1000 tokens from the treasury, a multisig signer would submit that transaction, referencing the Snapshot proposal IPFS hash as justification. More advanced setups use relayers or keeper networks to automate execution.

For fully automated on-chain execution, you can integrate with SafeSnap, a module for Gnosis Safe. It uses an oracle (like Reality.eth) to bridge the off-chain result on-chain. The process involves: 1) A successful Snapshot vote, 2) Submitting the transaction data to the Reality.eth oracle, 3) After a dispute period, the oracle confirms the result, 4) Any address can then trigger the execution on the Safe contract. This creates a trust-minimized bridge from off-chain signaling to on-chain action, removing the need for manual multisig intervention.

When implementing Snapshot, consider key security practices. Use a multisig as the space admin and executor. Verify all strategy contract addresses and test them on a testnet first. Be transparent about the execution process—will it be manual or automated via SafeSnap? Document the steps for your community. Remember, Snapshot is for signaling; the ultimate security of funds depends on the on-chain executor. This separation allows for inclusive, gas-free debate while maintaining the finality and security of Ethereum's base layer for execution.

Before creating proposals, you must establish your DAO's dedicated Snapshot Space. This is a unique namespace (e.g., yourdao.eth) that hosts all governance votes, member lists, and settings. Start by navigating to snapshot.org and connecting a wallet that holds the governance token for your project. This wallet will become the Space Controller, granting it administrative privileges to configure the space. You do not need to deploy any smart contracts for this step; Snapshot provides the infrastructure.

The core configuration happens in the Settings tab after space creation. Key initial settings include:

• Strategies: Define how voting power is calculated. The default erc20-balance-of strategy uses token balances at a specific block. You can add multiple strategies (e.g., for NFTs or delegated voting) and set their weights.
• Admins & Moderators: Assign Ethereum addresses as space admins (full control) or moderators (can edit proposals). Use a multisig or DAO treasury address as the primary admin for security.
• Voting: Set the voting delay (time before a proposal becomes active) and voting period (duration votes are open). A common standard is a 0-hour delay and a 5-day period.

You must also define the Space Network. While voting is gas-free and off-chain, the strategy that reads token balances must connect to a blockchain. For an ERC-20 on Ethereum, you would select the Ethereum network. The strategy will specify the token contract address and the snapshot block number method (typically the block when a proposal is created). Ensure your governance token is verified on Etherscan for easy discovery.

For advanced governance models, explore plugins in the Apps section. Plugins like Quit (quadratic voting), Scores (custom voting power formulas), or PoPV (proof-of-personhood) can be installed to tailor the voting mechanics to your DAO's needs. Each plugin has its own configuration parameters that integrate directly with your space's strategies.

Finally, customize the Profile and About sections. Add your DAO's logo, description, and relevant links (website, Discord, etc.). This public-facing information builds legitimacy for your space. Once saved, your Snapshot Space is live. The next step is to create and publish your first proposal, which members can then discover and vote on using their connected wallets.

In Snapshot, a voting strategy is a smart contract that returns a numerical value representing a voter's power for a specific proposal. The default erc20-balance-of strategy simply checks a user's token balance at a snapshot block. However, you can define custom strategies to implement complex governance models like: quadratic voting, time-locked token weights, delegated voting power, or multi-token governance. Strategies are defined in a JSON configuration within your space's settings.

To create a custom strategy, you must write and deploy a smart contract that implements the required interface. The primary function is getVotingPower, which takes the voter's address, a snapshot block number, a proposal ID, and optional user data, then returns a uint256 representing their voting power. For example, a contract for time-weighted voting might calculate power as tokenBalance * sqrt(lockTimeInDays). You can view reference implementations on the Snapshot Strategy Hub.

After deploying your strategy contract, you must register it with your Snapshot space. Navigate to your space's settings, select 'Strategies', and click 'Add Strategy'. You will need to provide: the contract address, the network it's deployed on (e.g., Ethereum Mainnet, Polygon), and its parameters. Parameters are defined in the strategy's JSON schema and allow for customization per proposal, such as specifying the token address for an ERC20 strategy or the multiplier for a quadratic calculation.

You can combine multiple strategies into a single proposal using strategies with weights. For instance, you could allocate 70% of voting power to a standard ERC20 token balance and 30% to a strategy that grants power based on NFT ownership or participation in a specific protocol. The total voting power for a user is the sum of each strategy's returned value multiplied by its assigned weight. This enables hybrid governance models that reflect diverse stakeholder groups.

Always thoroughly test your custom strategy contract on a testnet before deploying to mainnet and adding it to your live space. Use Snapshot's test instance at demo.snapshot.org to create a test space and verify that getVotingPower returns correct values for various addresses and scenarios. Incorrect strategy logic can lead to unfair voting outcomes or proposals that cannot be executed correctly by the off-chain voting system.

The on-chain execution bridge is the component that listens for finalized Snapshot proposals and executes their encoded actions. This requires a relayer—a trusted or decentralized service—to submit the transaction. The bridge typically consists of two key contracts: an executor contract that holds the authority to perform actions (like token transfers or parameter updates), and a verifier contract that validates the authenticity of the Snapshot proposal result. Popular frameworks for building this bridge include OpenZeppelin's Governor with a Snapshot-compatible voting module, or a custom implementation using the Snapshot X protocol.

To implement a basic bridge, you first deploy an executor contract that is owned by a multisig wallet or a timelock controller for security. This contract contains functions that can only be called by the designated verifier. Next, you deploy the verifier contract, which must be configured with the correct Snapshot space ID, IPFS hash of the proposal, and the signing strategies used. The verifier's core function is to check the proposal's final state and the validity of voter signatures against the Snapshot hub's Merkle root or via an oracle like the Snapshot Subgraph.

When a proposal reaches its end, the relayer calls the verifier contract's execute function, passing the proposal data. The verifier performs checks to ensure the proposal passed and the votes are legitimate. If validation succeeds, it calls the pre-defined function on the executor contract. For example, a proposal to transfer 1000 DAO tokens from the treasury to a grant recipient would encode a call to the executor's transferTokens function. Using a timelock between verification and execution adds a safety delay, allowing token holders to react if a malicious proposal somehow passes verification.

Security is paramount. The verifier must be immutable or upgradeable only via a separate, stringent governance process. Use EIP-712 typed structured data hashing for signature verification to prevent replay attacks. Consider implementing a quorum threshold and a minimum voting power requirement in the verifier logic, even if Snapshot handles display. For maximum decentralization, you can use a network of relayers like Gelato Network or OpenZeppelin Defender to automate execution, removing the need for a single trusted party to trigger the transaction.

Testing the full flow is critical. Use a testnet Snapshot space and deploy your contracts to a test network like Sepolia. Create a proposal, vote on it using test wallets, and simulate the relayer's call to the verifier. Tools like Hardhat or Foundry are ideal for writing integration tests that mock the Snapshot hub's response. Ensure your contracts emit clear events for successful execution and failed verifications to allow for easy monitoring and indexing by front-end applications.

With your Snapshot space created and a custom strategy deployed, you must now integrate them into your application's frontend. This involves using the Snapshot.js library to fetch proposals, connect user wallets, and cast votes. The core action is calling the client.vote method, which requires the proposal id, the voter's address, a choice (e.g., 1 for 'Yes'), and the space id. Importantly, this method generates an EIP-712 compliant signature from the user's wallet—no gas is paid because the vote data is signed off-chain and stored on IPFS via the Snapshot hub.

A robust integration includes comprehensive error handling and state management. You should check for common failure points: Is the user's wallet connected? Is the proposal in the active voting period? Has the user already voted? The Snapshot client provides methods like getProposal and getVotes to fetch this state. Use these to conditionally render UI elements, disabling the vote button if conditions aren't met. Implementing loading states while fetching data or awaiting a signature is crucial for user experience.

Thorough testing is mandatory before mainnet deployment. First, test on a testnet. Create a proposal in your Snapshot space using testnet addresses (e.g., from Goerli or Sepolia). Use the Snapshot Testnet hub at testnet.snapshot.org. Have multiple test wallets cast votes to ensure your strategy correctly calculates voting power from your asset contract. Second, simulate the full flow: connect wallet, load proposals, cast a vote, and verify it appears correctly on the Snapshot interface. Monitor the browser console and network tab for any errors from the Snapshot API or your strategy contract.

Finally, verify the integrity of the vote data. After a successful vote, Snapshot returns a receipt containing the IPFS hash of the vote payload. You can use this to retrieve and verify the signed message. Additionally, use the Snapshot GraphQL API to programmatically query the proposal results, ensuring your frontend's displayed tally matches the on-chain data resolved by your strategy. This end-to-end validation confirms that your gas-free governance system is fully operational and secure.

Implementing Snapshot voting successfully requires integrating several key components. Your governance strategy defines the voting power source (e.g., token holdings, delegation, or a custom strategy like erc20-balance-of). The voting interface is built using Snapshot's SDK or Hub API, allowing users to connect wallets and cast off-chain signatures. Finally, a relayer or executor is needed to listen for proposal results and execute the approved transactions on-chain, often using a multisig or a specialized contract like the OpenZeppelin Governor.

For next steps, consider these practical actions to enhance your implementation. First, audit your strategy and execution logic, especially if using custom code. Second, implement event listening and alerting to monitor for new proposals and finalized votes. Third, explore advanced Snapshot features like vote delegation, quadratic voting, or privacy-preserving methods such as zkSnap. Testing your full workflow on a testnet like Goerli or Sepolia before mainnet deployment is critical.

The primary advantage of this architecture is cost-free participation, which maximizes voter turnout. However, you must manage the execution risk—the gap between the off-chain vote and the on-chain action. Ensure your executor is secure, has sufficient gas funds, and follows the vote outcome deterministically. For ongoing governance, establish clear processes for proposal creation, discussion (e.g., on Discord or forums), and post-execution verification.

To dive deeper, consult the official Snapshot documentation for the latest API specs and strategy examples. Review real-world implementations from protocols like Uniswap or Aave. For on-chain execution patterns, study the SafeSnap module which integrates Snapshot with Gnosis Safe multisigs. Continuously monitor for new EIPs and layer-2 solutions that may further reduce the cost and complexity of trust-minimized execution.