Snapshot integration: where vote accounting breaks in a DAO
A typical Snapshot integration looks like this: voting is moved off-chain, and voting weight is calculated from a balance snapshot at a specific block — and this is almost always where DAO vote accounting diverges from the real distribution of influence.
The barrier to entry is low, so addresses that no longer hold the token at the time of calculation enter the poll, while those who received it later are left without a vote. The error is not in the vote storage, but in the snapshot point.
Vote delegation adds a second failure.
If the snapshot records only the balance at an address, the chain of delegates and sub-delegates is counted partially: weight is attributed to the one who transferred the tokens rather than the one who controls them, or it passes twice — through the owner's address and through an aggregating contract.
Wallets in staking and escrow are a separate case: the tokens are in the snapshot, but voting rights for them are not counted.
Then comes contestation of the voting results. Until it is fixed which block should be the reference point and how delegation should be resolved, quorum is calculated in two ways and produces two different results.
A recount shows that some votes were collected using an outdated balance snapshot, and the decision is rolled back — the cost of the dispute is higher than the dispute itself.
We break down how this is closed: choosing the snapshot point, delegation rules, and the set of checks we run before publishing the results.
What changes after moving voting off-chain
Moving voting off-chain removes the main barrier of the transaction-per-vote model. In Snapshot, a vote becomes a signed message: the holder confirms the choice with a wallet, and weight is calculated from the balance snapshot at a specified block.
Quorum, thresholds, and delegation rules are set in the space settings — for each DAO, without code changes.
Cost of participation for a token holder
On-chain, every vote is a separate transaction, and its cost is the same for a holding of hundreds of tokens and millions. A small holder pays the same price as a large one, and most often simply does not vote.
After moving off-chain, participation does not require a transaction: DAO turnout grows primarily because of those who were previously cut off by the barrier to entry.
Those who do not want to follow every agenda delegate their vote to an active participant — the weight stays in the protocol rather than being lost.
Counting speed and result transparency
Votes are aggregated by weight distribution strategies as they arrive — the interim result is visible in real time, not after manual reconciliation.
The result is fixed by the balance snapshot: transferring tokens after the vote starts no longer changes weight, so the “moved the holding before counting” scenario does not work. Any participant can verify the sample — addresses, weights, and signatures are public.
A separate class of failures, “vote not counted,” goes away: there is no need to wait for block confirmation and resubmit. Any participant can reproduce the count from open data and compare it with the published result.
Snapshot integration: connection formats and limitations
Connection is possible in three ways, and they differ not in convenience, but in how many operations remain with a human. The choice depends on how often the space parameters change and who exactly holds the assets.
| Option | When it fits | What remains manual |
|---|---|---|
| Setup through the service interface | Launching votes without in-house development | Settings edits, some participant composition checks |
| Direct connection to your own dashboard | You need your own interface and your own counting logic | Signatures, request limits, failure handling |
| Off-chain voting, on-chain execution | The decision must execute itself after quorum | Executor module and audit of its permissions |
Calculating voting weight for different asset types
Weight is calculated from the balance snapshot at the start of voting, not at the moment the vote is cast.
The native token, ERC-20 tokens, NFTs, and liquidity tokens require different strategies: for liquidity, the share in the pool is taken; for NFTs, the quantity or the ownership flag itself. Without this, the same asset can be routed through several wallets and counted twice.
Linking the voting result to execution
The voting result consists of signed messages, not transactions, so the decision is executed as a separate step. We configure quorum, the delay before execution, and executor permissions so that a passed decision cannot be canceled without a new vote.
If automation is not needed, the result is transferred to a multisig manually — slower, but control remains with a narrow group.
Implementation stages: from audit to handover of control
Implementing voting is not installing a tool, but moving the decision-making process into a transparent loop. Therefore, the implementation stages begin with a governance audit and end with transferring control to the client's team along with the regulations. Below is how the work is structured from the first review to independent operation.
- Governance audit. We analyze who makes decisions today, where votes are recorded, and how weight is calculated: token holders, delegation, contribution to the liquidity pool. The output is a role map and discrepancies between the charter and actual practice.
- Rights distribution scheme. We agree on who has administrative rights, who creates proposals, and who only votes. Changing the counting strategy and canceling proposals go to a multisig — one compromised device will not rewrite the rules.
- Space setup. We create a space in Snapshot, connect counting strategies, set the threshold for submitting a proposal, voting period, quorum, and the snapshot window by which balances are fixed.
- Test loop. A copy of the space on a testnet: we run delegation, partial exit from the pool, voting at the quorum boundary, and an attempted manipulation by transferring tokens after the snapshot.
- Pilot vote. We run one real decision in parallel with the old process and compare the results — the discrepancy is visible before the loop becomes primary.
- Handover of control. We transfer rights to the client's addresses, issue access by name, and record instructions for administrators.
Verifying counting correctness
We build the reconciliation methodology on historical votes: we recount them using the new strategies and compare with the actual results. We analyze discrepancies by cause — token migration, late transfers, liquidity withdrawal.
Incident response regulations
Before handover of control, we record who stops voting and within what timeframe in the event of a strategy error or admin key compromise, how a proposal is canceled, and where the incident is escalated.
Configurations, regulations, and documentation at delivery
Integration development ends not with a demonstration of working voting, but with the handover of artifacts that the client's team uses to continue without us. The package goes into the repository and internal knowledge base.
Rights scheme and access levels
- Snapshot space configuration files: a set of weight counting strategies, quorum threshold, voting window, and proposal validation rules — editable without rebuilding.
- Role scheme: who creates proposals, who changes space settings, who signs decisions, and which actions require two signatures.
- Access policies: to whom we grant administrative rights, on what principle we revoke them, and how we maintain the list of participants with publishing rights.
- Description of counting strategies: what weight each asset gives, at what block height the snapshot is fixed, and how delegation is counted.
Instructions for voting participants
- For the holder: wallet connection, message signature instead of a transaction, verification of counted weight before confirming the vote.
- For the administrator: how to submit a proposal, set deadlines, restart voting, and what to do if results diverge.
- Troubleshooting: vote not counted, weight changed after the snapshot, wallet not supported.
A separate document covers the update regulations: the procedure for testing new strategies, who approves changes to quorum settings, and how an unsuccessful update is rolled back.
Case study: how participant votes stopped getting lost
The client is a decentralized autonomous organization with several thousand token holders and voting on Snapshot.
Decisions were made based on a balance snapshot, but the “snapshot — delegation — vote signature” link was not configured: some participants saw that their weight was not counted and demanded a review of the results.
What it was like before the rebuild
The balance snapshot was fixed at the moment the proposal was published, and token transfers and delegate changes inside the voting window were not handled — the signature went through, but an outdated weight value was included in the count.
Results were collected manually: exporting the signature list, reconciling addresses with delegation, and filling the quorum. Before the rebuild: 6–7% of cast votes were not counted, results review took up to 11 days, and three out of ten votes ended in a dispute and review.
What was achieved after launch
The counting strategy was tied to the block number, and delegation accounting was moved to the moment the snapshot was fixed, while signatures began to be verified automatically as they arrived.
Quorum is calculated at the close of the window, and the vote report is generated without manual reconciliation — an engineer gets involved only to analyze anomalies.
The share of uncounted votes dropped below 0.5%, the time from proposal submission to result shrank to 5 days, and disputed results with reviews fell to zero. Participants stopped contesting quorum, and discussion returned to the substance of the proposals.
How does off-chain voting differ from on-chain voting?
The key difference is where the fact of voting is recorded. In off-chain mode, a participant signs a message with their wallet: the signature instead of an operation confirms voting rights but does not change network state and does not require a transaction fee.
Weight is calculated from the balance snapshot at the chosen block, so the result is visible within minutes, not after block confirmations.
On-chain, a vote is a transaction. It is recorded in the contract state, cannot be revoked or rewritten, but each operation costs the participant a network fee and waiting time.
Hence the trade-off: mass polls are unprofitable on-chain, while execution of decisions happens only there.
| Criterion | Off-chain voting | On-chain voting |
|---|---|---|
| Participant action | wallet signature | transaction with fee |
| Weight accounting | balance snapshot at a block | current contract state |
| Where the result is stored | signatures and counted result | contract state |
| Time to result | minutes | depends on network load |
| When chosen | polls, signaling decisions, initiative selection | treasury payouts, parameter changes, rights transfer |
Snapshot covers the first scheme: voting off-chain, while recording the decision on-chain is done by a separate transaction.
This hybrid provides inexpensive discussion and a verifiable result — participants do not pay for each vote, while execution and its author remain on-chain.
Technical concerns before launching voting
The questions engineers ask before integrating voting into the production loop rarely concern the tool itself — more often they concern interfacing with what already works. Below are answers to objections that come up on almost every project.
Is this compatible with already deployed governance?
Yes. Off-chain voting (Snapshot) reads the distribution of rights at the chosen network block and does not require migrating existing contracts or changing the accounting model.
Already deployed governance remains the source of weights, while counting happens off-chain — nothing needs to be rebuilt or migrated.
How are delegated tokens counted?
Weights are taken from the state at a specific block: the voter receives the sum of their own balance and everything delegated to them, while the delegator loses the weight and cannot vote again.
Delegation is tied to an address, so one participant can hold the weights of several holders — it is only important that the snapshot falls within the window when the delegation was active.
What protects against manipulation?
The snapshot is taken from a past block, not the current one, so buying tokens after the vote starts and influencing the outcome is impossible.
Additionally, the circle of voters is limited by the rights threshold for creating a proposal, and counting strategies exclude pools and borrowed positions if they should not participate.
When exactly does voting close?
The closing moment is set explicitly when the proposal is created and is counted by block time, not by the server clock — the result becomes reproducible. After closing, a recount using the same snapshot gives the same result for any independent verifier.
Let's discuss the task and come back with an implementation plan
To estimate a Snapshot integration, it is enough to describe the current governance setup: how decisions are made, who participates in them, and which assets give voting weight.
We will review the scheme, clarify contentious points, and come back with an implementation plan and timeline by stage.
What to send for the review:
- governance scheme: who initiates proposals, what quorum and majority thresholds are in effect, and how much time is allotted for voting;
- asset list: tokens, locked positions, pool shares, NFTs — everything that should be counted;
- participant roles: holders, delegates, council or multisig wallet, who executes passed decisions;
- vote accounting rules: by balance at the snapshot moment, by delegation, or by several strategies at once;
- where voting happens now — forum, chats, manual spreadsheets — and how the result turns into action;
- transparency requirements: public vote list, history export, access to space settings;
- draft space or testnet, if they already exist.
The implementation plan includes setting up the space and voting strategies, linking with the executor wallet, testing on a testnet, the procedure for migrating current votes, and handing over documentation to your team.
The work estimate is based on the asset list and number of roles, so the accuracy of this data directly affects the timeline.
Discussing the task takes one conversation: describe the situation in free form — we will come back with a work plan and estimate.