What it is
Proposal voting is the basic building block of DAO governance: someone submits a concrete proposal (spend money, admit a member, change a parameter), the group's voters cast yes/no/abstain votes over a fixed period, and the proposal only executes if it clears a defined threshold. It's the on-chain equivalent of a board or club vote, but with votes and (often) execution recorded and enforced by a smart contract.
How it works
- A proposer (anyone, or anyone meeting a minimum stake/membership requirement) submits a proposal with a specific, executable action attached — a transfer, a parameter change, a membership grant.
- The proposal enters a voting period of fixed length, during which eligible voters (token holders, DAO members, delegates) cast votes, typically weighted by tokens held or by one-member-one-vote depending on the DAO's design.
- The contract tracks running tallies of yes, no, and abstain votes, often visible in real time so voters can react to the current standing.
- Quorum and approval thresholds are checked: a minimum participation level (quorum) and a minimum yes-share (e.g., simple majority or supermajority) must both be met.
- If thresholds are met when voting closes, the proposal moves to a queued/timelock state (in many designs) giving members a final window to exit or object before execution.
- After the timelock, anyone can trigger execution, which calls the attached transaction exactly as specified — no additional discretion is exercised at execution time.
- If thresholds aren't met, the proposal simply expires with no effect.
Why designers use it
- Gives every stakeholder a transparent, auditable say in decisions that touch shared funds or shared rules, without needing a trusted central operator.
- Codifying the action inside the proposal itself (rather than voting on intent and trusting someone to execute it later) removes a point where insiders could deviate from what was voted on.
- Timelocks between passing a vote and executing it give members a chance to notice and react to bad proposals before funds move.
- Threshold and quorum knobs let a DAO tune how easy or hard it is to pass changes, trading off agility against safety.
Failure modes
- Low voter turnout lets a small, motivated minority pass proposals that the broader membership would have rejected — quorum requirements that are too low don't prevent this.
- Token-weighted voting concentrates power with whales, who can push proposals that benefit them at the expense of smaller holders.
- Vote buying or bribery markets can emerge around proposals with contested economic outcomes, since a public, purchasable vote is straightforward to bribe.
- Governance attacks: an attacker flash-loans or otherwise temporarily acquires enough tokens to pass a malicious proposal within a single voting window, as happened in real DAO exploits.
- Proposals with vague or overly broad attached actions ("upgrade the contract to address X") let a small yes-majority approve something far more consequential than voters realized.
What to check before using it
- Are quorum and approval thresholds calibrated to realistic turnout, not just a theoretical majority of all tokens?
- Is there a timelock between a proposal passing and its execution, giving members room to react?
- Can voting power be borrowed or flash-loaned right before a snapshot, and if so, is there a snapshot-based defense (e.g., checkpointed balances)?
- Does the proposal's attached action exactly match what's being voted on, with no room for the executor to substitute a different transaction?
- Is there an emergency brake (veto, pause, or exit mechanism like ragequit) for members who disagree with a passed proposal?