Snapshot

Snapshot is the most widely used voting platform in DAO governance – so ubiquitous that “taking a vote” in most DAOs means opening a Snapshot proposal. Built by Snapshot Labs and launched in 2020, it lets a community poll its token holders off-chain: votes are cryptographic messages signed with a member's wallet and stored on IPFS, so voting costs no gas and anyone can recompute the tally from the published ballots; accepting and ordering those ballots is a service Snapshot Labs runs, described below. It began as the signaling layer that sits above a DAO's discussion forum and below its treasury, and since 2024 it has also run binding on-chain votes, first through its own Snapshot X protocol and, from March 2026, for DAOs on OpenZeppelin Governor. (Snapshot docs)

How off-chain voting works

A DAO creates a “space” – its governance home – and configures a strategy that tells Snapshot how to read voting power (typically the balance of a governance token, snapshotted at a fixed past block so votes cannot be inflated by tokens bought after the proposal opens). Members then vote by signing a structured message; nothing touches the chain, so there is no gas fee and no on-chain footprint. The signed ballots and the final result are pinned to IPFS, making the vote publicly auditable but non-binding by default – Snapshot records what the community wants, it does not itself move funds. (voting guide)

Off-chain does not mean serverless. Snapshot's 2023 description of its architecture traces a vote (Snapshot Labs): the signed message goes to the sequencer, a server Snapshot Labs runs, which asks Snapshot's Score API for the voter's power at the proposal's block, read from archive nodes. The sequencer then pins the message to IPFS through several pinning services at once, writes it to the MySQL database behind the public GraphQL hub, and returns a receipt signed with its own key.

Every accepted action gets an incrementing ID, so the whole history can be replayed in order. A receipt makes a dropped or altered vote provable; it cannot force the sequencer to accept one. The same write-up named decentralising the sequencer as Snapshot's next step. By September 2026 that had not happened: the sequencer and hub code now live in Snapshot's sx-monorepo, and their standalone repositories, last changed in May 2026, are archived.

Voting strategies

Snapshot's flexibility comes from its pluggable strategies. A space can weight votes by plain token balance (one-token-one-vote), by quadratic rules, by delegated power, or by more exotic measures (LP positions, NFT holdings, vote-escrow locks). The community writes the strategies: 427 existed in March 2023 (Snapshot Labs), and Snapshot's scoring service held more than 500 in September 2026 (score-api). A second kind, validation strategies, decides who may vote or propose at all; the first, added in November 2022, checks Gitcoin Passport stamps (see Sybil resistance).

A strategy is not the same thing as a voting type, and Snapshot's documentation is careful to separate them: the strategy computes an individual's voting power, while the type “calculates the outcome of the proposal”. Snapshot ships six types – single choice, weighted, approval, quadratic, ranked choice (instant runoff) and basic (voting types) – and which one a space picks changes outcomes rather than presentation; see ranked and alternative ballot methods. This is why Snapshot underpins so many different governance models without each DAO needing to write its own tallying code.

The same flexibility is the platform's sharpest failure mode, because a space's strategy list is configuration rather than code, nothing validates it against the contracts it names, and a wrong entry does not error: it returns a number that looks like a result. The clearest worked example on the public record belongs to GenomesDAO, whose space applies erc721-with-multiplier to an address that is not an NFT collection but an 18-decimal Aerodrome LP token.

The strategy reads balanceOf as a count of items, so one holder's 5.18 LP tokens were credited as 6.1 sextillion votes and carried a 2024 proposal whose tally exceeds the entire token supply by a factor of 6.1 trillion. It has stood unremarked for two years because that ballot happened to be unanimous. The audit costs one division: a published tally larger than the token’s total supply is a misconfigured strategy, not a turnout record, and the check belongs in every reading of DAO metrics and analytics.

The division has a precondition that is easy to miss, and getting it wrong manufactures the same defect it is meant to detect. A tally is a measurement at a block, so the supply it is divided by has to be read at that block. Run over all 46 Snapshot spaces this wiki cites – 35 of which expose an ERC-20 address the check can resolve at all – the naive form of the audit, dividing by supply as of today, returns three results above 1. Only one is real. Aura’s space appears to have recorded a tally 3,454× its voting token’s supply, because vlAURA is a sixteen-week lock whose supply has since collapsed from 39,116,888.51 to 7,804.22; read at the proposal’s own snapshot block the ratio is 0.689, an ordinary turnout.

Balancer appears to have recorded 19×, because its mainnet leg is a contract-call strategy nested inside with-delegation and exposes no ERC-20 to divide by, so an address-based reading silently collapses the denominator onto six L2 BAL bridge balances worth 1.7% of supply; against BAL’s real 72,373,419.35 the ratio is 0.330. Both false positives are avoidable with one extra argument: eth_call takes a block number, and historical reads are keyless on eth.drpc.org, eth.merkle.io or rpc.mevblocker.io – though not on ethereum-rpc.publicnode.com, which serves current state freely and refuses archive requests without a token. Applied correctly, the corpus is clean: the GenomesDAO ballot above is the only misconfigured tally among the spaces this wiki cites.

From signaling to execution

Because a Snapshot vote is off-chain, it must be carried out somewhere. The dominant pattern is a two-stage flow: a Snapshot “temperature check” establishes consent cheaply, then the result is executed by a Safe multisig – often wired automatically through Zodiac / SafeSnap, which lets a passed Snapshot proposal trigger an on-chain transaction under an optimistic challenge window. UMA retired oSnap, the other bridge of this shape, on 15 December 2025; the Reality-based route is unaffected. This keeps day-to-day voting gasless while preserving a real on-chain outcome. (on-chain vs off-chain voting)

Snapshot X: on-chain voting

To close the trust gap in that hand-off, Snapshot Labs built Snapshot X, a fully on-chain voting protocol that puts proposals, vote counting and execution into smart contracts behind the familiar Snapshot interface. It announced the project in January 2022, then called StarkVote and built with StarkWare, for release in the second quarter of that year (Snapshot Labs), and launched it on 9 September 2024 (Snapshot Labs). It runs on Starknet and on EVM chains (Ethereum, Optimism, Polygon and Arbitrum); voting on one chain and executing on another works only from Starknet.

Voting power comes from storage proofs supplied by Herodotus, which let a contract on Starknet verify any value stored in an Ethereum contract. A holder votes with tokens that stay on Ethereum, and the power can come from NFTs or any other contract variable, not only from tokens with the ERC20Votes extension that Governor requires. Snapshot put the cost of a vote at 10–50 times below Ethereum's and of a proposal at 200 times below. A relayer called Mana submits signed votes on-chain for spaces that sponsor gas, so voting stays free for the voter.

A space combines three kinds of pluggable strategy: voting strategies compute power; proposal validation strategies decide who may propose; and execution strategies decide when a proposal passes and how it executes, whether on Ethereum from Starknet, through a timelock or through a Safe module. A space may run several execution strategies, such as a normal path and an emergency path with a higher quorum. OpenZeppelin and ChainSecurity audited the contracts. Starknet's own governance was the first large deployment (see Starknet).

Governor DAOs on Snapshot

On 19 March 2026, two days after Tally announced it was shutting down, Snapshot added native support for OpenZeppelin Governor and Governor Bravo, the contracts that Snapshot's own 2024 announcement said carry most on-chain voting. A Governor DAO can now take a proposal from temperature check to on-chain vote to execution inside Snapshot. ENS and Uniswap were live at launch (Snapshot), and ENS's space listed executable proposals created in September 2026 when read on the 19th.

The features are the ones Tally provided, plus Snapshot's gas relay. On-chain votes cost the voter nothing once anyone tops up the space's relayer account with ETH. A delegates dashboard ranks voting power and carries delegate statements. An execution builder composes the calls a proposal will make, loads contract interfaces from Sourcify and simulates the result with Tenderly before the vote, and a DAO can serve the whole interface from its own domain. Tally's DAOs could move with their proposals, votes and delegate statements intact. The integration was free for six months to DAOs that got in touch before April 2026, and then costs $6,000 a year as Snapshot Pro, with no execution fees. The code is MIT-licensed, frontend, indexer and SDK alike, and Snapshot says it collects no analytics and no IP addresses.

Snapshot's own advice divides the two on-chain options by what the DAO needs: Governor for one token, one vote with delegation and timelock execution; Snapshot X for voting power drawn from several tokens or sources, several quorum and execution rules, several treasuries, and control over who may propose.

Agents: the Snapshot MCP server

Snapshot Labs publishes a Model Context Protocol server that lets an AI assistant read Snapshot's governance data and act for a user. It began as a standalone repository in March 2026, moved into Snapshot's sx-monorepo in May, and runs as a hosted endpoint at mcp.snapshot.box or self-hosted. It exposes six tools: snapshot-query runs any GraphQL query against the Snapshot API, snapshot-schema returns that schema, snapshot-whoami reports the connected identity, and snapshot-vote, snapshot-propose and snapshot-follow write on the user's behalf.

A delegated key signs those writes, not the user's own. Over HTTP, connecting through OAuth mints a per-session alias wallet held with Coinbase's CDP, and the user has to authorize that alias on snapshot.box before any vote goes through. The server reads each proposal's voting type and privacy mode from Snapshot and applies them itself, and re-casting a vote on the same proposal replaces the earlier one (Snapshot MCP README).

Strengths and criticisms

Snapshot's strength is friction: free, fast, verifiable polling drove its near-universal adoption. Its most-cited weakness is the flip side – classic off-chain votes are signaling, not binding execution, so a DAO still relies on trusted signers (or a SafeSnap-style bridge) to honour the result, and the same low friction that boosts turnout also makes vote-buying and delegate apathy easy. Snapshot also ships one privacy lever, a space-level shielded voting setting that encrypts ballots to Shutter's threshold key and reveals them at close; measured across the flagship spaces it is used almost exclusively for elections (private and shielded voting). Snapshot X and Snapshot's Governor support answer the first critique; the second is inherent to token voting itself.

How Caper approaches this

Caper collapses the signaling-then-execution split that Snapshot spans, but it does not collapse governance into a single act. A Caper proposal is voted on-chain and, where the winning option carries an action, executed on-chain – there is no separate off-chain poll to later ratify, and no multisig standing between the vote and the outcome. What stands between them is a market rather than a signer: a passing ballot earns the right to open the market window, and the action executes at the end of it only if the caper's time-weighted price over that window is at or above the baseline locked at the trigger (trigger_proposal and resolve_proposal, contracts/logic/src/lib.rs). A ballot won by a DEBATE option never reaches the window at all – the contract refuses to trigger one, so the proposal is terminal at the tally and nothing executes.

The two also defend the ballot differently, and the difference runs opposite to what a Snapshot reader would assume. A Snapshot space reads voting power at a past block, so tokens bought after a proposal opens carry no weight. A caper reads the voter's own balances live, in the transaction that casts the ballot, and freezes only the circulation figure the weight is divided by, at proposal creation. Buying during the voting period therefore raises the balance the weight is computed from against a denominator that cannot grow with it, and the trade mints the soulbound vote tokens the same weight depends on. The trade-off is the mirror image of Snapshot's: Caper gives up gasless polling and snapshot-block finality to make the ballot itself enforceable.

References

• Snapshot, Documentation.
• Snapshot Labs, Snapshot X (on-chain voting protocol).
• Tally, On-chain vs off-chain voting.
• a16z crypto, DAO governance FAQ.
• Snapshot Labs, Snapshot – the technical architecture (March 2023).
• Snapshot Labs, Introducing Snapshot's onchain voting protocol: Snapshot X (September 2024).
• Snapshot, Decentralized Coordination: The Future of Enterprise (January 2026) – space and voter counts.
• Snapshot, Snapshot is now home for Governor DAOs (March 2026).