Snapshot’s proposal, result and vote-list screens reveal how participation is distributed. A real SafeDAO example shows why a high approval rate is not proof that a decision has been executed.
Snapshot is useful for participants who want to examine a DAO or other community’s proposal alongside its weighted voting result. The harder part is interpretation: participation thresholds, voting power and authority to carry out a decision cannot be reduced to a single percentage.
What we examined
On September 27, 2026, we opened SafeDAO’s public space, the closed SEP 55 proposal, its vote list and its IPFS metadata. We assessed the readability of those screens and compared their meaning with Snapshot’s official documentation. We did not connect a wallet, sign a message, submit a vote, test hardware wallet compatibility or execute a treasury transaction.
The review focuses on classic offchain Snapshot voting. Snapshot X is an onchain governance protocol in the same ecosystem; its execution capabilities should not be attributed to every Snapshot proposal.
A real proposal: read the three figures separately
SafeDAO’s SEP 55 requested 5 million SAFE for Safenet Beta. Our concern here is how to read the vote, rather than the merits of funding it. On the inspection date, the panel showed 99.94% for Accept, 33.2m / 10m and 331% on the Quorum line, and 93 on the Votes tab. These are the interface’s displayed, abbreviated figures; 331% is not a fresh calculation from the rounded 33.2m label.
Actual Snapshot interface captured on September 27, 2026. Numbered markers were added for explanation.
- Proposal and status: The SEP 55 title identifies the decision, while Closed means its voting period has ended. It does not establish that funds were transferred.
- Choice result: In this single-choice vote, 99.94% represents Accept’s share of participating voting power. It is not 99.94% of all community members, or necessarily that share of the 93 voting addresses.
- Quorum: Participation is compared with the configured threshold of 10 million. The 331% figure reports progress against that threshold, rather than support for Accept.
The proposal’s metadata recorded single-choice as its voting type and 24829356 as its snapshot block. The block reference identifies the historical state relevant to investigating voting power. A current wallet balance should not be substituted for voting power on an earlier proposal.
The vote count can hide concentrated voting power
The Votes tab was the most revealing screen. Its first row showed 19.1m SAFE and 57.445% of voting power; the second showed 5.2m SAFE and 15.692%. The two displayed shares add up to 73.137%. A total of 93 recorded votes plainly did not mean 93 equal weights.
SEP 55’s public vote list on September 27, 2026. The screen reports voting weights; it does not establish an individual’s identity or personal wealth.
- Votes counter: Keep the number of vote records separate from their combined weight.
- Voting power column: Read the token-denominated weight together with the percentage beneath it. An address need not represent one person, and its voting power may include delegation.
A space’s voting strategy calculates each participant’s weight. Token balances, delegated votes, NFTs and address allowlists can produce different allocations. Holding a governance token does not imply the same voting power on every past proposal. The voting type then governs how that weight is assigned to choices. Snapshot’s strategy documentation explains the distinction. We read SEP 55’s reported weights; we did not independently recalculate them from blockchain data.
A decision example: is 80% support enough?
Consider a hypothetical community requiring 1,000 units of voting power for quorum and a simple majority of the accept/reject weight. Assume there are no abstentions. With 600 units for Accept and 150 for Reject, support is 600 / 750 = 80%. Participation is only 750, so quorum fails and the proposal does not pass.
Add another 250 units to Reject. Participation reaches 1,000 and support falls to 60%, but both of our stated requirements are now satisfied. The lower support percentage accompanies a valid decision. The example has a boundary: real spaces can count abstentions differently, demand a different majority or use another voting type. Do not apply this formula without checking their rules.
A workable reading order is to identify the voting power rule, check which choices count toward quorum, and then examine the passing condition. If the result panel and the community’s governance text seem inconsistent, a colored result bar alone is insufficient evidence.
What does a voting signature authorize?
In classic Snapshot, the wallet signs a message recording the vote. The normal voting action does not send an onchain transaction and charge gas for every ballot. The official voting guide describes a vote signature, rather than a token transfer or spending approval. Connecting a wallet to a site is not itself a submitted vote.
“Gasless” is not a safety guarantee. Check the domain and the community’s official space link, then read the proposal, choice and account context in the wallet request. A request to transfer tokens or grant token spending permission is different from the ordinary voting message you expected. Pause until the request is understood.
Gasless voting does not make earlier steps such as acquiring tokens or delegating onchain free. Buying an asset to qualify for a vote is a separate financial decision from using the interface. We did not open the signing screen, so this review does not rate its usability.
Between a recorded result and execution
An offchain vote does not move treasury funds by itself. SEP 55’s text described a foundation’s role and separate implementation conditions. Seeing an Accept majority is not proof that the requested 5 million SAFE was sent. Establishing execution requires the relevant implementation record and, where applicable, an onchain transaction.
If the task requires automatic or permissionless execution, examine the mechanism that provides it. SafeSnap connects Snapshot outcomes to Reality.eth and a Safe module, with bond, challenge, waiting and execution conditions. Snapshot X provides onchain proposals and execution strategies. You still need to understand the proposed transaction, the contract’s authority and the conditions for triggering it. A finished vote is not proof of a completed transaction.
Safeguards begin before the final signature. Proposal and voter validation, voting weights, quorum, discussion periods and execution authority all contribute to the process. Documentation about spam prevention or audits does not prove that a particular community configured everything safely. Using a smart contract also leaves code and permission risks to assess.
Who should use Snapshot, and when is it insufficient?
Reading proposals, measuring community preferences and inspecting voting weights are strong reasons to use Snapshot. Moving from SEP 55’s result panel to the vote list exposed concentration behind the headline approval rate. The discussion link and metadata record made it possible to investigate beyond the brief result.
The limitation is the interpretation expected of the reader. A newcomer can mistake a weighted percentage for a headcount, overlook the historical block or treat a closed vote as an executed action. A governance forum is a useful complement for assessing arguments and objections; an onchain governance or execution tool serves the separate task of inspecting binding transactions. We did not perform a hands-on comparison of Snapshot X and SafeSnap and do not claim a speed or security advantage for either.
Snapshot works best for readers willing to check the result, the distribution of voting power and execution authority separately. Its public interface makes that preparation easier, provided the result screen is treated as one part of the governance record. Our DAO governance analysis examines voting concentration alongside treasury controls and Lido’s opposition mechanism.
