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 verify the tally without trusting the organizers. It is the signaling layer that sits above a DAO's discussion forum and below its treasury. (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)

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). 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 brings proposals, voting-power computation and execution into smart contracts while keeping the familiar Snapshot interface. It runs on Starknet and EVM chains (Ethereum, Optimism, Polygon, Arbitrum) and uses storage proofs to verify a voter's token balance trustlessly across chains — pushing computation onto Starknet to make voting and proposing far cheaper than executing the same logic directly on Ethereum L1. (Snapshot X docs)

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 is the ecosystem's answer to 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.