DAOs and Governance

02 September 2026

Decentralized Autonomous Organizations - DAOs - are organizations run by rules encoded as smart contracts, with decisions made by token holders rather than a board of directors. In practice, that means when a DAO needs to change a parameter, allocate treasury funds, or upgrade a protocol, someone writes a proposal, token holders vote on it, and if the vote passes, the transaction executes automatically on-chain. This is on-chain governance.

The reality is messier and more constrained than the ideal. Every mechanism comes with trade-offs, every tool has failure modes, and every design decision opens specific risks. This page maps the entire territory: how proposals get from idea to execution, what can go wrong at each step, and which pages in this site cover each piece in detail.

Proposals: from creation to execution

A governance proposal starts with an idea. Before anyone pays gas fees to put it on-chain, most DAOs use an off-chain temperature check - often on the Snapshot platform - to gauge whether the idea has community support. This is called Snapshot Off-Chain Signaling Before On-Chain DAO Votes. The relationship between that off-chain vote and the binding proposal that follows is not automatic; the Snapshot result signals intent, but the formal on-chain vote happens separately.

Only token holders who meet the Proposal Threshold Minimum Token Requirement in DAOs can create the actual on-chain proposal. That threshold exists to prevent spam: if anyone with one token could create a proposal, every DAO would drown in useless motions. But set the threshold too high, and you concentrate proposal power in whale wallets. The page on proposal thresholds explains how DAOs balance these pressures.

Once created, the proposal enters a voting period. Token holders cast their votes using a mechanism chosen when the DAO was designed. The most common is simple token-weighted voting: one token equals one vote. But many DAOs use quadratic voting, where the cost of additional votes increases exponentially. How Quadratic Voting Works in DAO Token Governance explains why quadratic weighting reduces the influence of large holders and gives minority positions proportionally more voice.

Some DAOs use conviction voting, where voting power for a proposal accumulates over time as a token holder maintains their preference. Others use optimistic governance, where proposals pass by default unless someone raises a veto during a challenge period. These are less common but solve specific problems - conviction voting for continuous resource allocation, optimistic governance for low-controversy decisions.

Delegation: the practical reality of DAO voting

Most token holders never vote. They hold tokens but lack the time, expertise, or attention to evaluate every proposal. This is where delegation comes in.

How to Delegate DAO Voting Power to a Delegate covers the exact on-chain transaction: a token holder signs a delegation transaction that assigns their voting power to another address. The tokens never leave the holder's wallet - delegation is not transfer. The delegate can now vote with the combined power of everyone who delegated to them.

This creates a class of professional delegates, tracked by tools like Tally and Karma. The Sybil platform attempts to map delegates to real identities. The risk, covered in Vote Buying and Bribery Marketplaces in DAO Governance, is that delegates can be bribed or captured. Vote marketplaces let buyers pay token holders to vote a certain way - or to delegate to a specific address. This undermines the entire premise of governance legitimacy.

Some DAOs use liquid democracy, where token holders can delegate to different delegates for different proposal categories, or even redelegate at any time. Others enforce vote locking: tokens must be committed for a fixed period to qualify for voting, with longer locks granting proportionally more power. Vote Locking for Boosted Governance Power in DAOs examines the opportunity cost: locked tokens cannot be sold or used elsewhere, and the price of that illiquidity is the premium voting power it buys.

When a token holder does not delegate, their tokens are effectively silent. Tools like Tally Governance Dashboard surface delegation interfaces and track delegate performance. Boardroom and DeepDAO aggregate governance activity across hundreds of DAOs. But no tool solves the fundamental problem: the apathy death spiral where low turnout lets a small minority control the DAO.

Voting power and quorum: why most proposals fail

A passed vote with 5% turnout is not the same as a passed vote with 50% turnout. To prevent minority capture, DAOs set a Quorum Requirement - the minimum percentage of voting power that must participate for a proposal to be valid.

Quorum Requirement in DAO Voting and Why Most Proposals Fail It explains the critical calculation: quorum is usually measured against the circulating supply, not the total supply. Tokens locked in contracts, burned, or held by inactive addresses don't count. Even so, many proposals fail because quorum was not reached - the error message "Proposal failed: quorum not reached" is one of the most common in DAO governance.

Low Quorum Enabling Minority Capture of DAO Treasuries is the risk in the opposite direction. If quorum is set too low relative to actual voter turnout, a coordinated minority can pass proposals that drain the entire treasury. This is not theoretical - it has happened. Some DAOs use adjustable quorum that scales with proposal importance, but that introduces its own governance overhead.

Then there is the flash loan problem. Flash Loan Governance Attacks on DAO Voting explains how an attacker can borrow millions of tokens, vote on a malicious proposal, and return the tokens - all within a single transaction. The tokens never left the attacker's control, but their voting power was temporary and massive. Defenses include vote locking (requiring tokens to be held for a period before voting) and snapshot-based voting (measuring holdings at a historical block).

Timelocks, Executions, and the Dangers Between

A passed proposal does not execute immediately. Every serious DAO uses a Timelock Execution Delay - a mandatory waiting period between passage and execution, usually 24 hours to 7 days.

Timelock Execution Delay on DAO Governance Proposals covers what happens during that delay: users can review the code that will execute, challenge it if they find bugs, or even exit the DAO through mechanisms like rage quit. The delay is a safety buffer. But it has costs: proposals that need fast action - like responding to a market crash - cannot execute quickly.

During the timelock, several things can go wrong. The proposal can be cancelled by the proposer if their token balance drops below the threshold. It can be vetoed by a council or multisig override. It can expire in the timelock queue without execution - the error "Proposal expired in timelock queue without execution" appears in many DAO logs.

Execution itself can fail. The error "Execution reverted: timelock not yet expired" occurs when someone tries to execute early. "Execution reverted due to contract error" happens when the proposal's target contract has changed since the vote passed. Compound Governor Bravo Contract Framework for DAO Governance explains how that framework handles these lifecycle states - Pending, Active, Succeeded, Queued, Executed, Defeated - and how each transition can fail.

Some DAOs use a Gnosis Safe Multisig with Zodiac Governance Modules instead of a pure on-chain governor. This hybrid model lets a multisig of trusted signers make quick operational decisions while token votes handle major changes. Multisig vs Full DAO Vote for Operational Decisions helps DAO designers decide which model fits which scenario.

Frameworks and Tooling: Choosing the Governance Stack

The choice of governance framework determines everything else. The two dominant on-chain frameworks are Compound Governor Bravo and OpenZeppelin Governor.

Compound Governor Bravo, used by Uniswap, Compound, and hundreds of forks, provides a complete governance lifecycle: proposal creation, voting, queueing, and execution. It is battle-tested but rigid. OpenZeppelin Governor Contract Library for DAO Development is modular - you can swap in different voting strategies, timelocks, and execution mechanisms. The trade-off is complexity: more modules mean more surface area for bugs.

Snapshot is the dominant off-chain voting platform. It is gasless for voters - they sign messages, not transactions. But Snapshot votes have no on-chain force; they are signaling. The page on Snapshot explains why this distinction matters and how DAOs bridge off-chain sentiment to on-chain action.

Tally and Boardroom provide governance dashboards and delegation interfaces. DeepDAO tracks treasury holdings and proposal activity. Aragon OSx offers a full DAO creation and management stack with upgradeable governance. Moloch v3 includes rage quit - dissenting members can exit with their proportional share of treasury before a proposal they oppose executes.

For gasless voting, Gasless Meta-Transaction Voting in DAOs via Relayers explains how relayers pay gas fees on behalf of voters, then collect reimbursement or rely on subsidized infrastructure. This lowers participation barriers but introduces centralization risk - the relayer could censor certain votes.

Risks and security: what can actually go wrong

The risks in DAO governance are not theoretical. They have caused real losses.

Flash Loan Governance Attacks have been demonstrated in production. Vote Buying markets operate openly on some networks. Low Quorum has allowed treasury drains. Governance Token Price Collapse can destroy the security budget that makes a DAO attack-resistant.

Governance Token Price Collapse Removing DAO Security Budget is counterintuitive: even if the treasury holds millions in stablecoins, a collapsed token price means an attacker can buy enough tokens to pass proposals cheaply. The DAO's security depends on the cost of acquiring voting power, which is the token price times quorum. When that price crashes, the cost of attack crashes too.

Legal Liability for DAO Members from Unincorporated Status is a growing concern. Courts in some jurisdictions have ruled that DAO token holders may be liable for DAO actions as partners in an unincorporated association. The page on legal liability explains the current situation and why incorporating in Wyoming, the Cayman Islands, or the Marshall Islands changes that exposure.

Proposal execution reentrancy can drain a DAO's entire treasury. Delegate private key compromise can let an attacker vote with thousands of tokens. Timelock bypass via emergency multisig override is sometimes by design and sometimes a bug. The error inventory at the top of this page lists two dozen specific failure modes - each maps to a real incident in DAO history.

The spoke pages: where to go next

This page has surveyed all of on-chain governance. Each topic here has its own dedicated page with complete coverage. Here is where to go for the details:

Voting mechanisms: Read How Quadratic Voting Works in DAO Token Governance for the math and trade-offs of quadratic weighting. Vote Locking for Boosted Governance Power in DAOs covers veToken models and opportunity costs. How to Delegate DAO Voting Power to a Delegate explains the delegation transaction step by step.

Proposal lifecycle: Snapshot Off-Chain Signaling Before On-Chain DAO Votes clarifies the relationship between gasless signaling and binding votes. Timelock Execution Delay on DAO Governance Proposals covers why delays exist and what happens during them. Proposal Threshold Minimum Token Requirement in DAOs explains how thresholds balance access and spam prevention.

Quorum and failure: Quorum Requirement in DAO Voting and Why Most Proposals Fail It breaks down the quorum calculation. Low Quorum Enabling Minority Capture of DAO Treasuries explains the minority attack vector. The error messages listed above - "Proposal failed: quorum not reached," "Proposal marked Defeated despite majority due to quorum" - are detailed there.

Frameworks and tools: Compound Governor Bravo Contract Framework for DAO Governance covers the dominant on-chain governor. OpenZeppelin Governor Contract Library for DAO Development explains the modular alternative. Gnosis Safe Multisig with Zodiac Governance Modules for DAOs covers hybrid governance. Gasless Meta-Transaction Voting in DAOs via Relayers explains how to vote without gas costs.

Risk and security: Flash Loan Governance Attacks on DAO Voting details the attack vector and defenses. Vote Buying and Bribery Marketplaces in DAO Governance explains the market structures that undermine legitimacy. Multisig vs Full DAO Vote for Operational Decisions helps choose between models. Governance Token Price Collapse Removing DAO Security Budget covers the price-attack relationship. Legal Liability for DAO Members from Unincorporated Status addresses the regulatory exposure.

Each of these pages answers one question completely. This page maps the territory. Go where your specific question leads.