What Is Snapshot Voting?

Introduction

Snapshot voting is a form of off-chain governance that lets blockchain communities vote without paying gas for every proposal and ballot. That sounds almost contradictory at first. Governance is supposed to be credible because blockchains are hard to rewrite, yet Snapshot moves the act of proposing and voting away from the chain itself. The reason this works is that it does not abandon cryptographic verification; it changes where verification happens and what gets written on-chain.

The core problem Snapshot solves is simple: token-based governance becomes less legitimate when participation is expensive. If casting a vote requires an on-chain transaction, then small holders often stay out, routine signaling votes become costly, and communities start avoiding governance except for major decisions. Snapshot lowers that friction by making votes gasless for users while still tying voting power to blockchain data such as token balances, NFT holdings, or other contract state.

This design has made Snapshot a common governance layer for DAOs, DeFi protocols, and NFT communities. Officially, Snapshot describes itself as a voting platform and an off-chain, gasless multi-governance client. Its results are meant to be easy to verify and hard to contest. To understand why that claim is plausible, you need to see the architecture clearly: wallets sign messages, strategies compute voting power from chain state, and a hub indexes the resulting records so anyone can query and audit them.

The important distinction is that Snapshot usually governs by social and procedural legitimacy first, and by direct blockchain enforcement only when paired with additional execution machinery. A Snapshot proposal can be highly influential even if it does not itself move funds or upgrade contracts. In many communities, a passing Snapshot vote tells multisig signers, delegates, or protocol operators what they are expected to do next. That is both Snapshot’s strength and its limit.

Why do projects use off-chain (gasless) voting instead of on-chain voting?

If every governance action were executed directly on-chain, the system would be maximally explicit but often impractical. Proposals would cost gas to submit. Every voter would pay gas to participate. During periods of network congestion, governance would become more expensive precisely when protocol conditions are volatile and decisions matter most. That produces a bad incentive: only large holders or highly motivated insiders participate regularly, while ordinary members become spectators.

Snapshot changes this by separating two functions that are often bundled together. The first function is measuring who should have influence. The second is recording their preferences. The measurement can still depend on blockchain state, because token balances and other assets live on-chain. But the recording of preferences can happen off-chain through signed messages. Once you separate those functions, you can preserve much of the legitimacy of token-based voting without forcing every ballot into the blockchain’s fee market.

This is the key idea that makes Snapshot click: the chain is used as the source of truth for voting power, while signatures are used as the source of truth for voter intent. You do not need an on-chain vote transaction to know that an address voted. You need a verifiable signature from that address. And you do not need to mutate chain state every time someone votes if all participants agree to evaluate the result against a fixed snapshot of balances.

That word “snapshot” is not cosmetic. Each proposal includes a specific block number that determines when balances are measured. If voting power were computed from the latest state at every moment, users could buy tokens after a proposal goes live, borrow assets temporarily, or otherwise manipulate influence during the vote. By fixing a block number, Snapshot says: voting power for this proposal is whatever the relevant strategies compute at this particular chain state. That makes the electorate stable for the life of the proposal.

How is Snapshot organized (spaces, proposals, and votes)?

Snapshot’s official documentation describes three core elements: spaces, proposals, and votes. A space is the organizational unit. It functions like a community profile where settings live and where proposals and votes are associated. If a DAO has its own Snapshot presence, that presence is its space. Creating a space requires an ENS domain, which acts as a practical naming and ownership anchor.

A proposal is the object that defines what is being decided. It includes the title, body, available choices, the voting system, the timing window, and the snapshot block number used to measure voting power. A vote is a signed statement from a wallet indicating the voter’s choice. Snapshot supports multiple voting systems, including single-choice, approval voting, quadratic voting, and others, because communities do not all want to aggregate preferences the same way.

This sounds like a normal web application so far, but the unusual part is where data lives and how it becomes trustworthy. Snapshot’s architecture is hybrid. The user interface presents proposals and voting screens. A hub service exposes a GraphQL API for reading data. A database indexes content for efficient queries. At the same time, proposals and votes are associated with IPFS content identifiers, so the system keeps content-addressed references to governance artifacts rather than relying only on mutable database rows.

That hybrid design matters because raw cryptographic integrity and practical usability are different problems. A content-addressed object on IPFS is good for auditability and replication. A relational database is good for filtering proposals, sorting votes, and serving a usable interface quickly. Snapshot combines them: persistent references for integrity, indexed storage for convenience, and an API so clients can reconstruct or inspect governance activity.

How does a Snapshot vote work step-by-step?

Mechanically, a Snapshot vote is not a blockchain transaction. It is a signed message. The voter connects a wallet, chooses an option, and signs data proving that the address authorized that vote. Because no state change is being executed on a blockchain, the user does not pay normal voting gas fees.

Here is the mechanism in plain terms. Imagine a tokenholder opens a proposal in a DAO’s Snapshot space. The proposal already specifies a block number that freezes the relevant balances in time. When the tokenholder votes, their wallet signs a message describing the vote. That message can then be submitted to Snapshot’s infrastructure, where it is accepted, indexed, and made queryable. Anyone who later inspects the vote can verify that the signature corresponds to the claimed address and that the voting power calculation used the proposal’s configured strategies against the specified snapshot block.

The result is that the vote is off-chain but not unauthenticated. This is an important distinction. “Off-chain” sometimes gets misheard as “trust me, the website says so.” Snapshot is not that. The signed-message model means voter intent is cryptographically attributable to a wallet. The strategy system means voting power can be recomputed from chain state. And the Hub GraphQL API exposes messages, including ordering information and IPFS-related fields, so external tools can inspect the record rather than relying only on what the web interface displays.

The API documentation is especially revealing here. Snapshot exposes “messages” representing confirmed actions such as votes, proposals, and space settings, along with an ordering field called mci. Those messages can be used to replay the hub API. In other words, the system is not just serving final tallies; it also exposes an ordered stream of governance actions that clients can query for verification or reconstruction.

How do Snapshot voting strategies calculate voting power?

If signed messages explain how votes are cast, voting strategies explain how votes are weighted. This is where Snapshot becomes far more flexible than a simple “one token, one vote” tool.

Officially, a voting strategy is a set of conditions used to calculate a user’s voting power. Technically, Snapshot describes a strategy as a JavaScript function that returns a score for a set of addresses. That score is the address’s voting power under that strategy. A space can choose between one and eight strategies, and if multiple strategies are configured, the final voting power is the cumulative sum of the scores they return.

This arrangement solves a hard governance problem: different communities define legitimacy differently. Some want voting power based on an ERC-20 governance token balance. Some want NFT ownership to matter. Some want balances from multiple contracts to count together. Some want delegation. Some want thresholds or validation rules. If Snapshot forced everyone into one formula, it would only fit a small slice of crypto governance. Instead, it lets spaces specify the rule by which influence is measured.

The simplest example is the default strategy, erc20-balance-of. Suppose a DAO says voting power equals the number of governance tokens held at block B, where B is the proposal’s snapshot block. Then when Alice votes, Snapshot computes her balance of that token at block B. If she held 1,000 tokens then, her vote carries 1,000 units of weight even if she later sells them. If Bob bought tokens after the proposal started, those later purchases do not affect this vote because the relevant state has already been fixed.

Once you understand that example, combined strategies become intuitive. A community might say voting power equals governance-token holdings plus a bonus for holding a specific NFT. Or it might combine balances across more than one network or contract. Snapshot’s documentation notes that strategies can be built from ERC-20s, NFTs, other contracts, and combinations. The Score API exists to calculate these scores based on the protocol’s strategy definitions.

That flexibility is powerful, but it introduces a subtle governance risk: strategy configuration is policy. A DAO may think it is debating a proposal, when in reality the decisive choice was made earlier in the configuration of who counts and how much they count. Snapshot’s own guidance makes this operationally concrete. Spaces are strongly encouraged to test strategies in the Playground before using them. If a strategy is misconfigured and votes have already been cast, those votes cannot be reverted; the recommended remedy is to delete the proposal, fix the settings, and create a new proposal.

That caveat tells you something important about Snapshot’s philosophy. It provides a verifiable voting process, but it does not save communities from defining their electorate poorly. The cryptography can prove what happened under the configured rules. It cannot guarantee those rules were wise.

Why does Snapshot fix a snapshot block for each proposal?

The snapshot block is the main anti-manipulation device in token-weighted off-chain voting. Without it, voting power would be a moving target. A voter could accumulate tokens only after seeing a proposal, borrow assets temporarily, or shift balances between wallets during the voting window. The final result would reflect tactical timing rather than the intended electorate.

By fixing a block number inside the proposal, Snapshot makes voting power a historical query rather than a live balance check. The strategy asks, in effect: *what did this address control at block B under rule R? * Because every voter on that proposal is measured against the same block, the result can be independently recomputed.

This mechanism is fundamental; the rest is partly convention. The exact voting system (single choice, approval, quadratic, and so on) is a community design choice. The exact strategies are configurable. But some kind of fixed reference point for balances is what makes token-weighted off-chain governance coherent. Without it, gasless voting would be much easier to game.

Of course, the snapshot block does not solve every manipulation vector. It limits balance-timing attacks on the measured assets, but it does not stop bribery, collusion, social coercion, or poor strategy design. Off-chain voting can still be influenced by broader governance markets. In crypto, that matters because token-based governance is not just a technical system; it is an economic one.

How do delegation and multisig workflows work with Snapshot, and what costs apply?

Many governance participants do not want to vote on every proposal personally. That is why delegation exists. Snapshot supports delegation, but with an important twist: the delegation action itself is on-chain and therefore costs gas. This is a useful contrast. Snapshot removes gas from the repetitive act of voting, but not every adjacent governance action can be made free if it must alter durable rights or relationships on-chain.

A space must explicitly use delegation-aware voting strategies for delegated voting power to count. Snapshot documents two main delegation strategies, and the difference between them is not just technical but constitutional. In with-delegation, the delegator cannot vote while the delegation is active; the delegate’s power includes their own power plus the delegated amount. In delegation, the delegated voting power is returned in a way that still lets the delegator’s own vote take precedence if both vote. The choice between those modes determines whether delegation is exclusive or overrideable.

That is a good example of how Snapshot often embeds governance design inside seemingly technical settings. A community may say “we support delegation,” but there are meaningfully different versions of that sentence. Does delegation transfer practical authority unless revoked before proposal creation? Or does it merely create a backup representative whose influence disappears if the original holder shows up? Snapshot can support either, but the community has to choose.

Multisigs introduce another practical layer. Snapshot supports Gnosis Safe for voting, proposal creation, and space setup. Here again, the platform adapts off-chain governance to real organizational structures. A treasury or core team may operate from a Safe rather than a single externally owned account, so governance participation needs to work for coordinated signers.

Snapshot documents two Safe signing modes. The default synchronous mode is off-chain: the first signer keeps the confirmation flow open until the others confirm, and this does not create a normal Safe transaction. There is also an asynchronous mode using on-chain signatures, enabled in Safe settings, which creates a pending Safe transaction that signers can confirm later. So even within an “off-chain voting” system, some workflows can intentionally reintroduce on-chain transactions when organizational convenience or persistence requires them.

Where are Snapshot proposals and votes stored, and how can I audit them?

For Snapshot to be more than a website, outsiders need ways to inspect the underlying governance record. The available documentation and code point to a layered answer.

The hub stores and serves indexed governance data. Its repository describes it as the service that stores the database, forwards new messages to peers, and holds a private key that signs valid messages. It exposes a GraphQL API, including a public endpoint, so clients can query proposals, votes, messages, and voting power. The database schema shows tables for spaces, proposals, votes, users, and related objects, with ipfs columns present across multiple tables. Proposals and votes both include IPFS fields in the schema, meaning Snapshot stores content-addressed identifiers alongside indexed relational records.

This matters because indexing and auditability are doing different jobs. The database helps answer questions like “show me all active proposals in this space” quickly. The IPFS CID answers a deeper question: “what exact content object is this record referring to?” In the API docs, message records include IPFS references and a receipt field. The docs do not fully explain receipt verification, so that part should be treated cautiously. But the existence of both an IPFS reference and a message stream is evidence that Snapshot is trying to surface more than a black-box tally.

A reputable secondary case study from the IPFS project adds useful architectural context: Snapshot uses IPFS as a main storage layer for proposals and signed votes, while using MySQL for indexing and querying. That same source describes a Snapshot-built microservice called Pineapple that races uploads across multiple IPFS pinning services and also uploads data to AWS S3. Since this is not Snapshot’s core official docs, it is best read as implementation context rather than a protocol guarantee. Still, it helps explain how Snapshot tries to make off-chain governance artifacts both addressable and available.

The broad point is this: Snapshot’s verifiability does not come from pretending off-chain data is magically trustworthy. It comes from using signatures for authorship, blockchain state for voting power, content-addressed references for payload integrity, and indexed APIs for inspection.

What does a passing Snapshot vote actually do; social mandate or on-chain execution?

A common misunderstanding is to assume that because Snapshot governance is widely used, its results are automatically self-executing. Usually they are not.

Snapshot is, first of all, a voting client. A passing proposal may function as a social mandate, an instruction to multisig signers, a legitimacy signal for delegates, or a precondition for later on-chain execution. But the vote itself is recorded off-chain. Unless a community has connected Snapshot to some execution mechanism, the result does not by itself move protocol funds or upgrade smart contracts.

That is not necessarily a weakness. Many governance decisions are not pure smart contract actions anyway. Communities use Snapshot for signaling, treasury preferences, parameter direction, election-like processes, and coordination where human interpretation is still required. In these cases, direct on-chain execution would add cost without adding much value.

But this does create a dependence on institutional follow-through. Snapshot works best when the community already knows who is expected to implement the result and under what norm. If the winning option says “the multisig should deploy upgrade X,” then the legitimacy of the vote must be strong enough that the multisig signs the transaction. If that social layer is weak, Snapshot can register preference without guaranteeing consequence.

What are the main risks and assumptions behind Snapshot’s trust model?

Snapshot is elegant, but its trust model is not the same as on-chain governance. It depends on several assumptions being good enough.

The first assumption is that the configured strategy truly reflects the intended electorate. If the wrong token, network, contract, threshold, or delegation mode is selected, the vote can be perfectly verifiable and still substantively wrong. This is why the Playground and pre-vote testing matter so much.

The second assumption is that off-chain legitimacy is acceptable for the decision being made. For a low-stakes signaling proposal, that is usually fine. For an action where immediate censorship resistance or automatic enforcement is essential, a pure Snapshot vote may be insufficient unless paired with other infrastructure.

The third assumption is that economic manipulation remains bounded. The snapshot block reduces some balance-based attacks, but it does not eliminate vote buying, bribery, or metagovernance pressure. Broader crypto governance markets have shown that voting influence can be rented or incentivized in sophisticated ways. Snapshot does not create those incentives, but neither does it neutralize them.

The fourth assumption is that the supporting infrastructure remains queryable and understandable. Snapshot is open-source and exposes APIs, which helps. But any off-chain system involves services, indexing, moderation choices, and operational keys. The hub documentation, for example, notes that it uses a relayer private key to counter-sign accepted messages. That is part of the practical trust surface, even if the end-user experience feels as simple as “sign and vote.”

None of this means Snapshot is flawed in a special way. It means governance systems are always mixtures of cryptography, software, incentives, and social enforcement. Snapshot simply makes that mixture more visible because it chooses lower-cost participation over full on-chain execution by default.

Conclusion

Snapshot voting exists because cheap participation and credible governance are often in tension. Its solution is to anchor voting power in blockchain state while recording proposals and votes off-chain as signed, verifiable messages. Spaces define the rules, strategies compute influence, a fixed block number stabilizes the electorate, and hubs plus IPFS-linked records make the process inspectable.

The idea to remember tomorrow is simple: Snapshot does not remove trust from governance; it rearranges it. You trust blockchains for balances, signatures for voter intent, content-addressed records for integrity, and community institutions to carry the outcome into action. That tradeoff is why Snapshot became so widely used; and why understanding its assumptions matters as much as understanding its interface.

How does Snapshot voting affect real-world usage?

Snapshot voting changes how governance tokens translate into real influence because proposals record intentions off-chain while execution often requires separate on-chain steps. Before you fund, trade, or rely on a protocol outcome, check who actually counts, how results are executed, and whether you need to hold or move assets to participate. Use Cube Exchange to fund and trade governance tokens quickly, then follow the checks below to align trading with any governance timelines.

1. Inspect the proposal’s snapshot block and configured strategies on the space page to confirm which token, network, and block determine voting power.
2. Confirm the proposal’s execution path (multisig, on-chain executor, or advisory) so you know whether a passing vote will automatically change protocol state.
3. Fetch the proposal’s IPFS CID and verify signed messages or the hub message stream for authenticity before trusting tallies.
4. Deposit fiat or crypto into your Cube account, trade the governance token using a limit order for price control (or a market order for immediate fills), and withdraw to your wallet before the snapshot if you need on-chain delegation or direct voting.