Snapshot Voting

Voters cast their ballots by signing a message with their wallet, eliminating transaction fees. This is achieved through off-chain signature verification, where votes are recorded on IPFS or Arweave, not directly on the blockchain. This dramatically increases participation by removing cost barriers.

• Mechanism: Uses EIP-712 for structured message signing.
• Result: Enables large-scale, frequent governance without gas cost concerns.

Snapshot allows DAOs to define custom logic for calculating voting power, known as voting strategies. These strategies can pull data from on-chain sources at a specific block number (the snapshot block).

• Common Strategies: Token balance, delegated balances, ERC-721 ownership (1 NFT = 1 vote).
• Example: A strategy could combine a user's veToken balance with their staked LP token balance for a composite score.

The platform supports multiple proposal formats and voting mechanisms to suit different governance needs.

• Single-choice voting: Choose one option.
• Approval voting: Vote for multiple options.
• Quadratic voting: Voting power scales with the square root of tokens used, reducing whale dominance.
• Ranked-choice voting: Rank options in order of preference.

Snapshot integrates with on-chain delegation and vote-locking mechanisms to align long-term incentives. Voters can delegate their voting power to representatives or lock tokens to gain boosted voting power.

• Delegation: Uses contracts like the OpenZeppelin Governor's delegate function.
• Vote Escrow: Strategies can read from systems like veToken models (e.g., veCRV) where longer lock-ups grant more voting power.

As a signaling layer, Snapshot's results are not self-executing. They are designed to be consumed by other systems, creating a governance stack.

• On-chain Execution: DAOs use tools like SafeSnap to bridge off-chain votes to on-chain execution via a reality.eth oracle.
• Data Source: Votes and strategies are stored on decentralized storage (IPFS), making the process transparent and verifiable.

While gasless, Snapshot relies on the security of the underlying blockchain for Sybil resistance. The integrity of a vote depends on the voting strategy accurately reflecting token ownership at the snapshot block.

• Core Security Assumption: An attacker cannot acquire a majority of the governance tokens at the specified block height.
• Limitation: It is a signaling tool; final on-chain execution requires separate verification.

Snapshot voting uses off-chain message signing to record governance preferences without on-chain transactions. Voters connect their wallets (e.g., MetaMask) and sign a message containing their vote choice, which is stored on IPFS (InterPlanetary File System). This makes voting gasless, removing a major barrier to participation. The final vote result is a verifiable tally of these signed messages, with the token snapshot (a record of token balances at a specific block) used to determine voting power.

A voting strategy defines how a user's voting power is calculated. The most common is the token-weighted strategy, where power equals the number of governance tokens held in a wallet at the snapshot block. Advanced strategies include:

• Quadratic Voting: Power = sqrt(token balance), reducing whale dominance.
• Delegation: Users delegate voting power to representatives.
• Multi-token Strategies: Power derived from balances in multiple tokens (e.g., UNI + staked UNI). Strategies are flexible and defined per proposal in the space's settings.

Snapshot supports various proposal formats to suit different governance needs:

• Single Choice: Vote for one option (e.g., Yes/No/Abstain).
• Approval Voting: Select multiple approved options.
• Quadratic Voting: Allocate voting credits across options, with cost increasing quadratically.
• Ranked Choice: Rank options in order of preference.
• Weighted Voting: Distribute a set number of voting points among choices. Each system is chosen by the space admin to best capture community sentiment.

While Snapshot votes are off-chain, they often trigger on-chain execution. A common pattern is the Snapshot → Timelock → Execution workflow:

1. A proposal passes on Snapshot.
2. A multisig or designated governor contract (e.g., OpenZeppelin Governor) validates the result.
3. After a timelock delay for review, the encoded transaction (e.g., treasury transfer, parameter change) is executed on-chain. Tools like Gnosis Safe Snapshot Module and Tally automate this bridge, making off-chain signaling binding.

A Snapshot Space is a dedicated page for a DAO or project. Admins configure:

• Admins & Moderators: Who can create proposals and manage settings.
• Voting Strategies & Symbols: Which tokens confer power.
• Validation Rules: Criteria a proposal must meet before posting (e.g., minimum token balance).
• Plugins: For enhanced functionality like proposal discussions or delegation. Spaces are often verified with a ENS domain (e.g., snapshot.org/#/ensdomain.eth) to establish authenticity.

Snapshot's security model relies on the integrity of the token snapshot and the security of voters' private keys. Key considerations:

• Snapshot Block: A malicious admin could theoretically choose a historical block where token distribution favored a certain outcome.
• Sybil Attacks: Mitigated by the cost of acquiring the underlying governance token, not by Snapshot itself.
• Result Finality: Off-chain results are not inherently enforceable; they require a trusted execution layer (multisig, smart contract) to enact. Best practice is to use a well-publicized snapshot block and transparent execution processes.

A primary risk is vote buying or flash loan attacks, where an actor temporarily acquires a large amount of governance tokens to sway a proposal's outcome. Since Snapshot uses a static token snapshot, it does not account for transient ownership, allowing attackers to borrow tokens, vote, and return them, all without a long-term economic stake.

• Mechanism: An attacker uses a DeFi lending protocol to borrow tokens, takes the on-chain snapshot, votes on Snapshot, and repays the loan.
• Impact: Governance decisions can be hijacked by actors with no skin in the game, leading to malicious proposals.

Snapshot's security model depends on the integrity of its off-chain infrastructure, including the Snapshot hub, IPFS, and the voting strategists who tally results. This creates central points of failure.

• Data Availability: Proposal and vote data are stored on IPFS and indexed by the Snapshot hub. Corruption or loss of this data can invalidate results.
• Strategist Risk: A malicious or compromised strategist could manipulate vote calculations. The system relies on community trust in these off-chain actors.

Snapshot votes are signaling mechanisms only; they do not automatically execute on-chain actions. This separation creates a coordination gap and a timelock attack vector.

• Post-Vote Risk: After a vote passes, a malicious party could front-run or block the manual execution transaction.
• Multisig Reliance: Execution typically requires a multisig wallet or trusted team, re-centralizing power and creating a single point of failure for implementation.

Snapshot's default one-token-one-vote model is susceptible to Sybil attacks if the underlying token is cheaply acquirable. While weighted voting helps, it does not solve identity-based issues.

• Limitation: It measures token weight, not unique human identity. A wealthy actor can split funds across many addresses to appear as broader support (whale fragmentation).
• Mitigation: Projects sometimes integrate proof-of-personhood systems (e.g., BrightID) or delegation to trusted entities to improve Sybil resistance.

The specific block number chosen for the token snapshot is a critical and manipulable parameter. Actors can exploit the timing of the snapshot.

• Block Manipulation: A whale could accumulate tokens just before the snapshot block is mined and sell immediately after, minimizing market risk while maximizing voting power.
• Proposal Timing: Proposers can set snapshot blocks during periods of low voter attention or liquidity to reduce opposition.

Custom voting strategies that pull data from smart contracts introduce validation and oracle risks. A strategy's logic defines what "counts" as a vote.

• Logic Bugs: A flawed strategy contract could miscalculate voting power, leading to incorrect outcomes.
• Oracle Dependency: Strategies relying on external price oracles (e.g., for LP token voting) are vulnerable to oracle manipulation, allowing attackers to artificially inflate their voting weight.