Vote in DAO Governance

DAO voting splits into two mechanically different systems: gasless off-chain signalling on Snapshot, and on-chain votes that can actually execute code through a Governor contract. This guide covers both, plus delegation, how quorum is calculated, what it costs, and the whale-dominance and vote-buying problems that token voting has not solved.

What you are actually doing when you vote

In token-based governance, voting power is a function of tokens held or delegated at a specific past moment, not of identity. There is no one-person-one-vote; there is one-token-one-vote, weighted by whatever strategy the organisation has configured. Understanding that changes how you read a result: a proposal that passed 90% did not necessarily convince 90% of participants, it attracted 90% of the voting weight that turned up.

Two entirely different systems get called "voting", and the difference matters more than any interface detail:

• Off-chain signalling. You sign a message. Nothing is written to a blockchain, nothing executes, and it costs nothing. Snapshot is the dominant venue. The result is a legible expression of holder sentiment that a multisig, foundation, or subsequent on-chain vote is expected — but not forced — to honour.
• On-chain execution. You send a transaction to a Governor contract. Votes are tallied in contract storage and, if the proposal succeeds and clears its timelock, the encoded calls execute automatically. Nobody has to be trusted to implement the outcome, and nobody can decline to. This costs gas.

Most large DAOs use both: a temperature check and formal signalling vote on Snapshot, then an on-chain vote for anything that moves treasury funds or changes protocol parameters. Knowing which one you are participating in tells you exactly how much your vote is worth.

Snapshot: off-chain voting

Snapshot's own documentation describes it as "a voting platform that allows DAOs, DeFi protocols, and NFT communities to vote easily and without gas fees", operating entirely off-chain. The pieces you will encounter:

Spaces. Each organisation has a space — its governance hub, where proposals live and where the rules are configured. Space settings include the voting period ("how long voting remains open"), the voting delay ("time between proposal creation and voting start"), proposal validation determining who is eligible to propose, the voting strategies that decide how votes are counted, and member roles such as Admin, Moderator and Author.

Strategies. A voting strategy is the function that converts your wallet's holdings into voting power. The simplest reads an ERC-20 balance, but a space can count staked tokens, LP positions, NFTs, or several sources combined — which is why your voting power on one proposal may differ from another organisation's, or from your raw token balance.

The snapshot block. Voting power is measured at a block height fixed when the proposal is created, which is where the platform gets its name. Buying tokens after that block does not increase your weight on that proposal, and selling afterwards does not reduce it.

Voting types. Snapshot documents six: single choice (one option only), weighted (distribute your power across options), approval (select any number of choices, each receiving equal voting power), quadratic (power is distributed using square-root calculations, which dilutes large holders' influence and emphasises the number of voters over the size of holdings), ranked choice or instant-runoff (rank all choices, with elimination rounds until one exceeds 50%), and basic (For, Against, Abstain — where Snapshot notes that Abstain votes count toward quorum requirements).

Execution. By default a Snapshot vote executes nothing. Two bridges exist between signal and action: SafeSnap, which uses Reality.eth to let a Safe multisig execute a passed off-chain proposal, and Snapshot X, which the documentation describes as "fully onchain governance on EVM and Starknet". Absent one of those, a Snapshot result is advisory — a fact worth knowing before you spend an afternoon campaigning on one.

On-chain governance: Governor contracts and execution

Most on-chain DAO governance runs on the OpenZeppelin Governor pattern or a close derivative, and its parameters are the vocabulary of every on-chain proposal you will read.

• Voting delay — "how long after a proposal is created should voting power be fixed". OpenZeppelin's documentation suggests 7,200 blocks, roughly one day, as an example. This window exists so holders can react to a new proposal before the balance sheet is frozen.
• Voting period — how long the proposal remains open. The reference guide uses 50,400 blocks, roughly one week.
• Proposal threshold — an optional minimum voting power required to submit a proposal at all, used to prevent spam. It can be set to zero.
• Quorum — via GovernorVotesQuorumFraction, defined as a percentage of total supply measured at the block the proposal's voting power is retrieved from. The documented example initialises it at 4%.
• Vote options — For, Against and Abstain. Under the standard GovernorCountingSimple module, "only For and Abstain votes are counted towards quorum". Abstain is therefore not a null action: it is how you help a proposal reach the threshold at which it can be decided, without endorsing it.
• Historical snapshots — voting power "is retrieved from past snapshots rather than current balance, which is an important protection that prevents double voting". Without it, one holder could vote, transfer the tokens, and vote again from the receiving wallet.
• Timelock — a successful proposal is normally queued in a TimelockController before it executes, with distinct Proposer, Executor, Canceller and Admin roles. The delay is a safety valve: it gives users a window to exit and guardians a window to cancel if a malicious proposal passes.

The lifecycle follows from those parameters: proposed, then pending during the voting delay, then active for the voting period, then succeeded or defeated, then queued in the timelock, then executed. A proposal can stall at any stage — a succeeded proposal that nobody queues, or a queued one that nobody executes, simply does not happen.

The main interface for this is Tally, which as of 2026 has been renamed: its site now states "Tally is now Cactus. New name, same platform." Its documentation says the platform "powers governance and staking for 400+ protocols including Arbitrum, BNB Chain, Compound, ENS, Gitcoin, GMX, Lisk, Optimism, and many more." Expect to see both names in circulation for some time; the contracts and URLs behind them are unchanged.

Delegation: the part most holders skip

Delegation is not optional plumbing — on most on-chain systems it is a precondition for your tokens counting at all.

With OpenZeppelin's ERC20Votes extension, token holders "must either set a trusted representative as their delegate, or they can become a delegate themselves by self-delegating". Undelegated tokens carry zero voting power. This surprises people constantly: they hold a governance token, open a proposal, and find their voting power reads zero. The fix is a one-time delegate transaction, which costs gas but persists — you do not repeat it for every vote, only when you change delegate or acquire tokens in a new wallet.

Snapshot's delegation works differently and is worth understanding separately. Its documentation states delegations are stored on-chain in the Gnosis Delegate Registry contract at 0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446, indexed via a subgraph. You can delegate globally across all spaces or to a specific space by entering its key, and space-specific delegation takes priority over global. Critically, delegating on Snapshot does not disarm you: the docs describe the case where a delegator votes directly and the delegates' voting power from that delegator drops to zero. You keep the last word. Note also that a delegation voting strategy must be added to a space for delegated votes to count there at all.

Delegation is the practical answer to the fact that reading every proposal in every DAO you hold a token in is a part-time job. It is also a real transfer of influence. Before delegating, read the delegate's stated platform, check their voting history — both Snapshot and Tally/Cactus surface it — and confirm they actually vote rather than merely accumulating delegations. You can revoke or change a delegation at any time by setting a new one.

Quorum, and why proposals fail without opposition

Quorum is the minimum participation required for a vote to count. On a Governor contract it is a fraction of total supply at the proposal's snapshot block, commonly a low single-digit percentage — OpenZeppelin's example uses 4% — precisely because token-voting turnout is chronically poor.

Two implications people miss. First, a proposal with overwhelming support can still fail purely on turnout: if the For votes do not reach quorum, the outcome is defeat regardless of the ratio. Second, because Abstain counts toward quorum under the standard counting module while Against does not, abstaining is a substantive choice. If you want a proposal to be decided but do not want to endorse it, Abstain moves it toward decidability; if you want it to die on turnout, not voting is a more effective action than voting Against. Read your DAO's counting module before assuming which applies — this is one of the details that varies.

What you'll need (prerequisites)

• A self-custodial wallet — MetaMask, Rabby, or hardware. For any position large enough to matter in a vote, use hardware such as Ledger.
• The DAO's governance token, held at or before the proposal's snapshot block. Tokens acquired after it carry no weight on that proposal.
• Voting power actually activated — meaning self-delegated or delegated, on systems that require it.
• Native gas token, for on-chain votes and for the one-time delegation transaction. Snapshot voting itself needs none.
• The proposal text, read in full — including the encoded calldata for on-chain proposals, not just the human-readable summary.

Step-by-step

1. Step 1: Find the DAO's real governance venue

   Start from the protocol's own documentation or website and follow its link to the forum, its Snapshot space, and its Tally/Cactus page. Do not start from a search result or a link in a direct message. Governance sites are attractive phishing targets precisely because holders arrive at them expecting to sign things.

2. Step 2: Connect a self-custodial wallet

   Click "Connect Wallet" and choose MetaMask, Rabby, WalletConnect, or a hardware wallet. Connecting is a message signature that proves address ownership and moves no funds. If you hold governance tokens on a hardware wallet, connect that wallet directly — do not move tokens to a hot wallet in order to vote.

3. Step 3: Select the correct network

   For on-chain votes, the Governor contract lives on one specific chain — Ethereum mainnet for some DAOs, Arbitrum, Base, Optimism or elsewhere for others — and you must be on it, with that chain's gas token. Snapshot voting is off-chain, but the strategy reading your balance still points at a particular chain, so tokens sitting on the wrong network will not be counted.

4. Step 4: Activate your voting power by delegating

   On ERC20Votes-style systems, undelegated tokens carry zero voting power — self-delegate, or pick a delegate. This is a one-time transaction that costs gas and persists. On Snapshot, delegation is optional and handled through the Gnosis Delegate Registry, globally or per space. What you should never do at this step is grant a token-spend approval. Voting requires no allowance; a request to approve spending in order to vote is a drainer, not a governance flow.

5. Step 5: Read the proposal, including the calldata

   Read the forum discussion, not only the summary on the voting page. For on-chain proposals, expand the actions the proposal will execute: target contracts, function signatures, and parameters. A proposal's prose and its calldata are written by the same author and are not required to match — the calldata is what executes. Check the snapshot block too, so you know which of your holdings count.

6. Step 6: Cast your vote

   Choose your option and confirm. On Snapshot this is a gasless off-chain signature with no transaction and no fee. On a Governor contract it is a transaction — typically castVote or castVoteWithReason — that costs gas and writes your choice to contract storage. Where the ballot is Basic or For/Against/Abstain, remember that Abstain generally counts toward quorum while Against does not.

7. Step 7: Verify, then watch the execution

   For an on-chain vote, confirm the transaction on the block explorer and check your weight is reflected in the tally. For Snapshot, your vote and its voting power appear on the proposal page and are verifiable against your signature. Then follow through: a succeeded on-chain proposal still has to be queued in the timelock and executed before anything changes.

What it costs

Governance is one of the few areas of DeFi with no protocol fee — nobody charges you to vote. The costs are network gas and time.

• Snapshot voting: nothing. Off-chain signatures cost no gas. Creating a proposal in a space is likewise gasless, though spaces set their own eligibility rules.
• Delegation: one-time gas. Both the ERC20Votes self-delegate transaction and a Gnosis Delegate Registry setDelegate call are on-chain writes. You pay once, and again only if you change delegate or use a new wallet. On mainnet this can cost more than the governance participation is worth for a small holder — a genuine reason to hold governance tokens on a layer 2 deployment where one exists.
• On-chain voting: gas per vote. Every castVote is a transaction. For small holders on mainnet, the fee routinely exceeds any plausible marginal influence, which is a structural cause of low turnout rather than a sign of apathy.
• Proposing and executing: gas, plus a threshold. Submitting an on-chain proposal costs gas and usually requires meeting the proposal threshold. Queuing and executing a passed proposal are separate transactions that someone has to pay for — often a delegate or the foundation, but the contract does not care who.

Security and pitfalls

Never approve a token spend to vote. This is the one bright-line rule. Voting, delegating, and proposing require no ERC-20 allowance over your governance tokens. Any interface asking you to approve spending as a step in voting is malicious.

Treat signature requests with the same suspicion as transactions. Snapshot's gasless voting normalises signing off-chain messages, which is exactly the habit signature drainers exploit — an off-chain order or permit costs nothing at signing time and moves assets later. Read what the wallet is presenting. A Snapshot vote payload names the space and the proposal; it does not reference your token balances as transferable. If you have signed something you should not have, go straight to how to revoke token approvals and then how to respond to wallet compromise.

Delegation is a real transfer of influence. You keep your tokens and you can revoke, and on Snapshot voting directly overrides your delegate. But between delegating and noticing, your weight votes as they choose. Delegating to an address you cannot identify, or to whoever is at the top of a leaderboard, is not participation.

Read the calldata, not the title. The most consequential governance failures were proposals that passed while looking ordinary. If you cannot interpret the encoded actions, treat the presence of a treasury transfer, a role grant, or an upgrade target in the payload as reason to wait for someone who can.

Understand what a Snapshot result binds. Unless the space runs SafeSnap or Snapshot X, a passed proposal obliges nobody. Verify how a DAO actually implements its off-chain results before treating a Snapshot vote as a decision.

Use a governance-appropriate wallet setup. Tokens that carry meaningful voting weight belong on hardware or in a multisig. You can delegate voting power from a cold wallet to a hot one for convenience without ever exposing the tokens themselves — the delegate address votes, but cannot move funds.

The criticism: whale dominance and vote-buying

Token voting has a well-documented set of failures, and anyone participating should understand them rather than discover them.

Voting power is purchasable. Because weight is bought rather than earned, an attacker with capital can acquire influence directly. In July 2024, Compound's Proposal 289 — allocating 499,000 COMP, roughly $24 million of the treasury, to a product designed by a group known as the "Golden Boys" — narrowly passed by 682,191 votes to 633,636. OpenZeppelin's security team flagged accounts acquiring COMP on the open market and directing it toward the proposal. Within days the proposal was rescinded under community pressure and replaced with a different arrangement, but the mechanism worked exactly as designed: enough tokens were bought, and the vote passed.

Voting power can be rented. Where voting weight derives from a balance rather than a time-locked commitment, it can be borrowed. In April 2022 an attacker used flash loans — over a billion dollars of assets from Aave, converted through Curve into the LP tokens Beanstalk's Silo accepted — to reach a supermajority of governance weight and invoke Beanstalk's emergencyCommit function, bypassing the normal proposal lifecycle and draining $182 million. The protocol lacked any defence against governance capture via flash-loaned voting power. This is the reason timelocks, voting delays, and historical snapshots exist in modern Governor designs — they make rented weight useless because power is measured at a block that has already passed.

Formal decentralisation is not effective decentralisation. In April 2023 the Arbitrum Foundation's first proposal, AIP-1, sought 750 million ARB — close to $1 billion — for its operations. Holders objected strongly, and the Foundation then characterised the proposal as a ratification rather than a request, disclosing that tens of millions of tokens had already been allocated and some converted to fiat before the vote concluded. The proposal was subsequently broken up after backlash. A vote that cannot change the outcome is a consultation.

Turnout is structurally low. Quorum thresholds sit at a few percent of supply because that is what participation supports. Low turnout concentrates power further: a handful of large delegates routinely decide outcomes, and quorum itself becomes the swing factor rather than the merits.

None of this makes governance pointless — the Compound proposal was reversed because holders and researchers paid attention, and the AIP-1 restructuring happened for the same reason. But scrutiny, not the vote count, is what did the work in both cases.

Troubleshooting

• My voting power shows as zero. The most common cause on on-chain systems is undelegated tokens — self-delegate and it resolves. Other causes: you acquired the tokens after the proposal's snapshot block, they are on a different chain than the strategy reads, they are held in a contract or exchange account the strategy does not count, or the space's strategy counts something other than a plain balance.
• I delegated but my delegate's power didn't increase. On Snapshot, a delegation voting strategy must be added to the space for delegated votes to count there. Also check delegation scope: a space-specific delegation overrides a global one for that space.
• "Proposal not active" or the vote button is disabled. You are inside the voting delay, or the voting period has closed. Check the proposal's start and end times, not just its status label.
• The vote transaction reverted. Usual causes: the proposal is not in the active state, you have already voted from that address, or your address has no voting power at the snapshot block. Read the revert reason on the explorer before resubmitting and paying twice.
• The proposal passed but nothing happened. Succeeded is not executed. Someone must queue it in the timelock, wait out the delay, and then execute it. Check the proposal's on-chain state; if it is stuck at succeeded or queued, raise it in the forum.
• My vote isn't showing. On Snapshot, votes appear on the proposal page with the voting power that was applied. On-chain, look for the VoteCast event on your transaction. Interface indexing can lag; the chain and the signature are authoritative.

When not to use this route

• When gas exceeds your influence. If you hold a small position and the on-chain vote costs meaningful gas on mainnet, delegate once to someone whose record you have checked rather than paying per vote for a rounding-error's worth of weight.
• When you have not read the calldata. Voting For on a proposal you have not verified adds legitimacy to something you do not understand. Abstaining, or not voting, is the honest position — and under standard counting, Abstain still contributes to quorum.
• When the vote is purely advisory and you need a guarantee. If a Snapshot space has no SafeSnap or Snapshot X execution path, the result binds nobody. Escalate to the on-chain process rather than treating signalling as settlement.
• When your tokens are on an exchange or in a wrapper that does not delegate. Custodied tokens generally cannot vote. If governance participation matters to you, hold the tokens yourself — see how to use cold storage.
• When you bought after the snapshot block. No amount of tokens acquired after the snapshot affects that proposal. Wait for the next one.
• When you are trying to change something governance does not control. Plenty of protocol decisions sit with a foundation, a core team, or a multisig rather than the token. Read the governance scope before spending effort on a proposal that no contract can enact.

FAQ