Snapshot DAO: Gasless Off-Chain Voting Explained

Snapshot is an off-chain voting platform that DAOs use to run gasless, signature-based governance votes instead of paying for on-chain transactions. Rather than broadcasting a transaction to the blockchain every time someone casts a ballot, Snapshot has voters sign a structured message with their wallet using the EIP-712 standard, and that signature — along with the vote — is stored off-chain, typically on IPFS, rather than on the blockchain itself. Since its launch in 2020, Snapshot has become one of the most widely used governance tools in Web3, adopted by DAOs across DeFi, NFTs, and infrastructure projects to let token holders weigh in on proposals without worrying about network fees. This article explains how Snapshot's signature-based voting actually works under the hood, walks through the main voting strategies it supports — including token-weighted and quadratic voting — and looks honestly at where the platform's limitations lie.

What is Snapshot and Why Does It Matter

Snapshot is a decentralized governance platform that enables off-chain voting without broadcasting transactions to the blockchain. This fundamental design means participants pay zero gas fees regardless of how many proposals they vote on or how often they participate. The platform was built to address the core problems that plagued early on-chain voting systems: transaction costs that scale with network congestion, slow execution times, and a practical barrier that discouraged smaller token holders from participating simply because voting cost money. Before tools like Snapshot existed, DAOs had to treat every vote as an on-chain transaction, meaning each ballot carried a gas fee — a cost that could easily exceed the economic stake many voters had in the outcome, especially for smaller holders casting votes on routine proposals.

Snapshot solves this by moving the voting step off-chain entirely while preserving the transparency and cryptographic integrity that make blockchain-based systems trustworthy in the first place. Each DAO or project sets up its own governance "space" on Snapshot — commonly tied to its ENS domain — where it defines voting rules, eligible tokens, and strategies. Voting power itself is determined by token holdings at a specific block height, known as the snapshot block. This means the platform captures the state of the blockchain at one precise moment in time and uses that frozen snapshot as the basis for calculating everyone's voting power, rather than checking balances continuously as votes come in.

How Digital Signatures and EIP-712 Work

Snapshot voting relies on cryptographic signatures rather than blockchain transactions — a secure, verifiable, and completely cost-free alternative. Instead of sending a transaction that a network of validators must process, a voter signs a message containing their choice with their wallet's private key, and that signature alone is enough to prove authenticity. EIP-712 is the Ethereum standard that makes this practical and safe. Before EIP-712, wallets could only sign raw hexadecimal data, which produced an opaque string that gave users no real way to verify what they were actually agreeing to — a setup that phishing attacks could exploit. EIP-712 instead lets applications present structured, human-readable data for signing, so a Snapshot voter's wallet shows the proposal name, the chosen option, and other relevant fields in plain language before they approve anything.

The signing flow itself is straightforward: you connect your wallet to a Snapshot space, review the proposal and your intended vote, and approve a signature request. Your wallet then produces a digital signature using your private key — a value known only to you and never transmitted anywhere. Because of how public-key cryptography works, anyone can use your public address to verify that a signature was produced by your private key, but nobody can forge that signature without possessing the key itself. This is what allows Snapshot to treat a signed message with the same trust as an on-chain transaction, without ever needing to submit anything to the blockchain or pay for it.

Token-Weighted Voting

The most common voting mechanism on Snapshot is token-weighted voting, sometimes called "1 token, 1 vote." Your voting power simply equals the number of governance tokens you hold at the snapshot block — hold 100 tokens and you cast 100 votes' worth of weight; hold 10,000 and your ballot counts proportionally more. The appeal of this system is its simplicity and transparency: anyone can look at a wallet's token balance and know exactly how much influence it carries, and it mirrors the classic shareholder-voting model long used in traditional corporate governance, where ownership stake determines voting weight.

Many Snapshot spaces also support delegation under this model, letting token holders assign their voting power to another address — often a community delegate, subject-matter expert, or active contributor — without transferring custody of the underlying tokens. This helps address voter apathy, since busy holders can still have their voice represented even when they don't have time to review every proposal themselves.

However, token-weighted voting has a well-documented downside: it concentrates governance power among the largest holders. A small number of wallets holding a disproportionate share of a token supply — often early investors, founding teams, or large exchanges and funds — can dominate outcomes regardless of how the broader community feels. This dynamic is frequently described as a plutocracy problem, where governance decisions end up reflecting the preferences of the wealthiest participants rather than the collective will of everyday users, which is precisely the concern that other voting mechanisms like quadratic voting were designed to address.

Quadratic Voting

Quadratic voting represents a fundamentally different approach to governance, designed specifically to reduce the influence that large token holders can exert. Instead of your voting power scaling one-to-one with tokens, it scales with the square root of the tokens you commit to a vote. Concretely, if you commit 100 tokens to a choice, your voting power is √100 = 10 votes. Commit 10,000 tokens, and your power is √10,000 = 100 votes. Each additional vote costs more than the last — casting your first vote is comparatively cheap, but doubling your voting power requires roughly quadrupling your token commitment. This diminishing-returns curve is the entire point: it makes it mathematically expensive for any single wallet to dominate a decision.

The anti-whale effect becomes clear when you compare a concentrated holder against a distributed community holding the same total number of tokens. A whale committing 1,000,000 tokens to a vote gets √1,000,000 = 1,000 votes. But if that same 1,000,000 tokens were instead spread across 1,000 separate community members holding 1,000 tokens each, and every one of them voted, their combined voting power would be roughly 1,000 × √1,000 ≈ 31,600 votes — more than 30 times greater than the whale's, despite both groups holding an identical total token amount. This is the core mechanism-design idea behind quadratic voting: it doesn't eliminate the advantage of holding more tokens, but it dramatically shrinks the gap between concentrated and dispersed ownership, giving broad community sentiment much more relative weight than it would have under simple token-weighted voting.

The tradeoff is complexity. The square root relationship is far less intuitive than simple proportional voting, and casual participants may struggle to predict how a given token commitment translates into actual voting power. Quadratic voting is also more vulnerable to Sybil attacks than token-weighted voting in one specific way: because voting power grows slower than linearly with tokens, splitting a large holding across many separate wallets can sometimes yield more combined voting power than voting from a single wallet — which is why DAOs using quadratic voting often pair it with identity or reputation checks to limit wallet-splitting.

Other Voting Mechanisms on Snapshot

Beyond token-weighted and quadratic voting, Snapshot supports a range of additional voting strategies that DAOs can mix and match depending on the type of decision being made. One widely used alternative is one person, one vote, where every eligible participant gets exactly one vote regardless of token holdings — useful for decisions where a DAO wants to prioritize broad participation over capital weight, though it typically requires some way of verifying that each participant is a distinct individual rather than one person controlling many wallets.

Another approach is allowlist (or whitelist) voting, where only addresses on a pre-approved list can participate — often used for core-contributor votes, multisig signer elections, or other decisions meant to be restricted to a defined group rather than the entire token-holding public. Approval voting is also available, letting voters approve as many options as they support rather than being limited to a single choice, which works well for proposals with several acceptable outcomes. Ranked-choice voting is popular for elections with more than two options: instead of picking a single favorite, voters rank the choices in order of preference, and the system tabulates results across those preference orders to find the outcome with the broadest overall support, rather than simply the one with the most first-place votes.

Many DAOs don't rely on a single strategy across the board. A treasury-spending proposal might use token-weighted voting, since it involves a direct financial stake, while a governance-parameter change or a community-values decision might use one-person-one-vote to prioritize broad legitimacy over capital weight. This flexibility — the ability to pick a different voting strategy for each individual proposal or space — is one of the reasons Snapshot has been adopted so widely: it doesn't force every DAO into a single governance philosophy.

Limitations of Snapshot

Despite its advantages, Snapshot has several important limitations that every DAO participant should understand. The most fundamental is that Snapshot votes are non-binding — the platform has no built-in ability to automatically enforce on-chain actions. A Snapshot proposal produces a signal of community preference, not an executed outcome. If a DAO votes to move treasury funds, upgrade a smart contract, or change a fee parameter, someone — typically a multisig of trusted signers or an automated executor — still has to manually carry out that action on-chain afterward. This creates a trust gap: the vote itself can't guarantee the outcome will actually be implemented, or implemented faithfully to what was voted on. Some DAOs mitigate this with execution frameworks that connect a Snapshot result to an on-chain multisig, but this requires deliberate setup rather than coming built into Snapshot by default.

A second limitation relates to how token balances work. Because Snapshot checks a wallet's balance at a single snapshot block rather than requiring tokens to be locked or staked for the vote, the same tokens sitting in a wallet can in principle be used to vote in multiple unrelated proposals — even across different DAOs — at the same time. Unlike systems that require locking tokens as a form of committed "skin in the game," Snapshot's model treats voting power purely as a point-in-time balance check. The snapshot-block mechanism does successfully prevent one specific attack — using a flash loan to borrow tokens right before a vote closes and then returning them immediately after — since the block used to calculate voting power is fixed before that window opens. But it does not address the broader critique that unlocked token balances make voting power cheaper to acquire temporarily than genuinely committed, staked capital would be.

Finally, because participation is free and requires no locked capital, Snapshot spaces can also suffer from voter apathy and low turnout on routine proposals, and — as with any voting system based on wallet addresses rather than verified individual identity — remain generally susceptible to Sybil attacks, where one participant splits holdings or influence across multiple wallets to appear as several independent voters.

Security and Attack Prevention

Despite these limitations, Snapshot implements several meaningful security measures. First, cryptographic signature verification ensures that only the holder of a given private key can cast a valid vote from that wallet — signatures cannot be forged without the key itself, and Snapshot's off-chain design doesn't weaken this guarantee at all, since the underlying cryptography is identical to what secures on-chain transactions.

Second, the snapshot-block mechanism protects against most flash-loan style manipulation. By fixing the block used to calculate every voter's balance before the voting window meaningfully progresses, Snapshot prevents an attacker from borrowing a large quantity of tokens moments before a vote closes purely to swing the outcome, since those borrowed tokens wouldn't have existed in the attacker's wallet at the recorded snapshot block.

Third, transparency provides an additional layer of accountability. Snapshot votes and signatures are recorded off-chain, typically pinned to IPFS, creating a content-addressed, tamper-evident record: any alteration to the stored data would change its content hash and be immediately detectable, making the historical record difficult to quietly manipulate. It's worth noting this isn't identical to blockchain-level immutability — availability still depends on the data continuing to be pinned and served — but it does provide meaningful, publicly auditable proof of what was voted on and when.

Finally, many DAOs layer on their own additional safeguards beyond what Snapshot provides by default: requiring proposal creators to hold a minimum token balance to reduce spam and low-effort proposals, setting minimum quorum thresholds before a vote is considered valid, or integrating proof-of-personhood tools for spaces using one-person-one-vote or quadratic strategies to make wallet-splitting and Sybil attacks harder to pull off.

Practical Use Cases of Snapshot

In practice, Snapshot is used across a wide range of Web3 projects for many different kinds of decisions. DeFi protocols commonly use it to let token holders vote on protocol parameters — things like trading fee tiers, collateral requirements, interest rate models for lending markets, or whether to approve a new feature or integration. Treasury management is another major use case: DAOs frequently put treasury-spending decisions to a Snapshot vote, covering questions like whether to fund a grants program, invest treasury assets, hire core contributors, or allocate budget toward marketing and business development.

Snapshot is also used for broader strategic and parameter-level decisions — questions like whether a protocol should expand into a new market or integrate with another protocol — where community sentiment is valuable input even if the final execution still requires additional steps. NFT communities and infrastructure projects use it similarly, for everything from partnership decisions to more procedural governance-process changes.

Part of why Snapshot has been adopted so widely is that it removes friction from the entire participation process. Proposals typically include a discussion or commenting section directly on the platform, where community members debate the merits of a proposal, ask clarifying questions, and sometimes negotiate amendments before voting even opens — turning governance into an ongoing conversation rather than a single up-or-down transaction.

How to Get Started with Snapshot

Getting started with Snapshot is straightforward. First, check whether the DAO or project you're interested in actually uses it — most DAOs that do will prominently link to their Snapshot space from their official website, documentation, or Discord server. You can also visit snapshot.org directly and search for the project by name. Once you've found the right space, you'll see a list of active and closed proposals, along with basic information about the space's voting strategy and rules.

Click into any proposal that interests you to review its full details: the proposal description and rationale, the available voting options, the current vote distribution if voting is already open, and any community discussion in the comments. When you're ready to vote, click the Vote button, which will prompt you to connect your wallet if it isn't already connected. Snapshot will then display the voting options according to whatever strategy that space uses — a single choice, multiple approvals, a ranked list, or a quadratic allocation. Select your preference and confirm.

Your wallet will present an EIP-712 signature request summarizing exactly what you're voting for — always take a moment to actually read this before approving, the same way you'd check a transaction before signing it, since a malicious or spoofed site could otherwise trick you into signing something you didn't intend. Once you approve, no gas fee is charged and your vote is recorded immediately; you'll see it reflected in the running vote totals right away, and you can continue to follow the discussion as other members weigh in until the voting period closes.

Frequently Asked Questions

Conclusion

Snapshot has become a foundational piece of Web3 governance infrastructure precisely because it solves a problem that made on-chain voting impractical for most DAOs: cost. By replacing blockchain transactions with EIP-712 signatures and basing voting power on token holdings at a fixed snapshot block, it lets communities vote as often and as broadly as they want without anyone having to weigh a gas fee against the value of participating. The range of voting strategies it supports — from simple token-weighted voting to quadratic voting, one-person-one-vote, ranked choice, and more — gives DAOs the flexibility to match their governance model to the specific decision at hand, rather than forcing every vote through the same mechanism. That flexibility doesn't erase the platform's real limitations, though. Snapshot votes are non-binding signals that still require a human or automated step to execute, unlocked token balances mean voting power isn't backed by genuinely committed capital, and Sybil resistance varies significantly depending on which strategy a given space chooses. Understanding both what Snapshot does well and where it falls short is essential for anyone participating in DAO governance — whether you're casting your first vote or helping design a new DAO's voting rules — and that understanding is what allows communities to use the tool responsibly as part of a broader governance process, not as a complete substitute for one.

This article is for educational purposes only and does not constitute financial advice.