Snapshot Voting

Blockchain networks employ Snapshot for off-chain signaling on core protocol upgrades and resource allocation.

• Arbitrum: The Arbitrum DAO uses it to vote on grant funding and technical direction.
• Optimism: Governs its Retroactive Public Goods Funding (RPGF) rounds and protocol upgrades.
• Polygon: Community uses it for ecosystem grant proposals and partnership decisions. These votes often inform subsequent on-chain execution.

NFT communities and social DAOs leverage Snapshot for lightweight, accessible governance.

• Proof Collective (PROOF): Uses it to vote on community initiatives and fund allocations.
• Friends With Benefits (FWB): Governs event planning, treasury use, and membership criteria.
• Nouns DAO: Frequently employs Snapshot for signaling before on-chain Nouns governance votes to gauge sentiment. This allows large, token-gated communities to coordinate efficiently.

A primary use case is governing DAO treasuries and grant programs.

• Ecosystem Grants: Protocols like Arbitrum and Optimism run multi-million dollar grant rounds voted on via Snapshot.
• Budget Allocations: DAOs vote on quarterly budgets, operational spending, and contributor compensation.
• Project Funding: Individual project proposals are submitted, debated, and approved through the platform. This creates a transparent, participatory process for capital allocation.

Snapshot votes are off-chain signals, not on-chain transactions. This introduces a separation between signaling and execution.

• Gasless Voting: Enables broad participation but lacks inherent execution.
• Trusted Execution: Requires a separate, trusted process (often a multisig) to enact results on-chain.
• Data Integrity: Relies on the integrity of the Snapshot IPFS pinning service and indexers. Many protocols use it for sentiment gathering before a final, binding on-chain vote.

A Snapshot vote is a signed message expressing voter intent; it is not a direct, executable blockchain transaction. The vote result is a signal, not a command. Execution requires a separate, privileged transaction (often by a multi-sig) to implement the proposal on-chain. This creates a trust assumption in the executors and introduces potential for manipulation or delay between the signal and the execution.

Snapshot's primary sybil resistance mechanism is token-weighted voting based on a snapshot of on-chain holdings. This inherits all limitations of the underlying token's distribution:

• Whale dominance: A small number of holders can dictate outcomes.
• Airdrop farming: Voters may acquire tokens solely for governance influence without long-term alignment.
• Liquidity vs. Ownership: Tokens in DeFi pools (e.g., Uniswap LP positions) are often counted, giving voting power to transient capital. Strategies using delegation or vote escrow aim to mitigate but not eliminate these issues.

Custom voting strategies (the logic defining who can vote and with what weight) are a powerful but risky feature. A flawed or malicious strategy can compromise the entire vote. Common vulnerabilities include:

• Replay attacks: Using the same token balance across multiple proposals or spaces incorrectly.
• Oracle manipulation: Strategies relying on external price oracles (e.g., for LP tokens) can be gamed.
• Complexity bugs: Errors in custom strategy code can lead to incorrect vote weight calculations. Auditing strategies is as critical as auditing smart contracts.

Because votes are public and cast over a period (e.g., 3-5 days), vote-sniping or late-stage manipulation is possible. A well-funded actor can:

• Monitor voting trends in real-time.
• Acquire tokens or delegate votes late in the process to swing a close proposal.
• This undermines the principle of independent voter expression and can lead to strategic withholding of votes until the final moments. Some protocols use vote privacy solutions (like zkSnarks) to mitigate this, but they are not native to Snapshot.

Snapshot introduces points of centralization that contrast with blockchain's decentralized ethos:

• IPFS Pinning Services: Proposal data and votes are stored on IPFS, but availability relies on pinning services (like Pinata) which could theoretically be censored.
• Snapshot Hub: The off-chain indexer that validates signatures and tallies votes is a centralized service run by the Snapshot Labs team, though it's open-source.
• Domain & ENS Control: Each space is controlled by an ENS domain; compromising the private keys for this domain compromises the entire space's governance.

A critical non-technical limitation is voter turnout. Gasless voting lowers barriers, but participation often remains low (<10% of token holders), concentrating power in active whales or delegates. This leads to:

• Legitimacy questions: Can a proposal with 4% participation truly represent the community?
• Attack surface: Low participation makes it cheaper to acquire enough tokens to swing a vote.
• Protocol risk: Major decisions may be made without broad consensus. This is often addressed with quorum requirements and vote delegation features.

Snapshot allows DAOs to define custom voting strategies that determine vote weighting. Common strategies include:

• Token-weighted: One token equals one vote.
• Quadratic Voting: Voting power is the square root of token holdings, reducing whale dominance.
• Delegation: Voters can delegate their voting power to representatives.
• Multi-token: Voting power is derived from multiple token balances or NFTs. These strategies are executed off-chain via a customizable JavaScript function.

Snapshot voting is off-chain, meaning votes are signed messages stored on IPFS, not executed as blockchain transactions. This enables:

• Gasless participation: No transaction fees for voters.
• Flexible signaling: Quick, non-binding polls and temperature checks.
• Reduced cost: Ideal for frequent, low-stakes proposals. On-chain voting (e.g., via a governor contract) is required to execute transactions, such as treasury transfers or parameter changes, making it binding but more costly.

A standard Snapshot proposal follows a defined path:

1. Drafting & Discussion: Ideas are debated in forums like Discord or Discourse.
2. Proposal Creation: An authorized space admin creates the vote on Snapshot, defining the question, choices, voting strategy, and snapshot block.
3. Voting Period: Token holders cast their votes off-chain, typically lasting 3-7 days.
4. Execution: For signaling proposals, the result is advisory. For execution, a multisig or smart contract must enact the passed proposal's intent on-chain.

A Space in Snapshot is a dedicated hub for a DAO's governance. Admins configure:

• Strategies: How voting power is calculated.
• Validation: Rules for who can create proposals (e.g., token threshold, whitelist).
• Voting Delay & Period: Timing parameters for proposals.
• Network: The blockchain where token holdings are verified (e.g., Ethereum Mainnet, Arbitrum). Permissions are managed via a multisig wallet or a dedicated admin address, centralizing setup while decentralizing voting.

The snapshot block is a specific blockchain block number used to determine token balances for a vote, preventing last-minute token buying (vote buying). Key aspects:

• Balances are read from this historic block, locking in eligible voters.
• It provides a point-in-time record, a core sybil resistance mechanism.
• Without it, voters could borrow or transfer tokens to manipulate outcomes. The block is set by the proposal creator and is immutable once the vote begins.

Snapshot is often paired with on-chain execution frameworks to create a complete governance stack. Common pairings include:

• Gnosis Safe: A passed Snapshot vote signals a multisig to execute a transaction.
• Governor Bravo (Compound): Proposals can be created on-chain after passing a Snapshot temperature check.
• Zodiac & Reality.eth: Modules like the Reality Module bridge Snapshot votes to on-chain execution via decentralized oracles that verify vote outcomes. This separates the signaling layer from the execution layer for security and efficiency.