How DAOs Work: A Technical Guide for Product Teams

DAOs are governance structures where token holders control protocol decisions. The idea is compelling; the reality is complex. This guide covers how DAO governance works technically and where it commonly fails.

The Governor Contract

Most DAOs use OpenZeppelin's Governor contract (or its variants: GovernorBravo, Compound Governor). The Governor handles: proposal creation, voting period management, vote counting, and execution. It's the smart contract layer that enforces governance rules without a central authority.

The Proposal Lifecycle

A holder with enough tokens (proposal threshold) submits a proposal — on-chain code to be executed if it passes. Voting opens after a delay (voting delay, e.g., 48 hours — allows users to acquire/delegate tokens). Voting runs for the voting period (e.g., 5 days). If quorum is met and the vote passes, a timelock period begins (e.g., 48 hours). After the timelock, anyone can execute the proposal.

The Timelock

The timelock is the most important security feature of DAO governance. It delays execution after a vote passes, giving the community time to respond to malicious proposals — either by canceling them (if the guardian/veto exists) or by exiting the protocol before the change takes effect. A 48-hour minimum timelock is the standard for production governance; 7 days is common for high-stakes parameter changes.

Voting Power and Delegation

ERC20Votes (or ERC721Votes) tokens use snapshots — voting power is based on token balance at the proposal's creation block, not the current balance. This prevents flash loan attacks on governance. Most token holders delegate to themselves or trusted delegates. Active governance participation is typically 5–15% of total supply — most holders are passive.

Common Governance Failures

Low participation: quorum isn't met, proposals fail not because of disagreement but apathy. Plutocracy: large token holders (VCs, founders) dominate decisions, small holders feel unrepresented and disengage. Governance attack: an attacker accumulates enough tokens to pass malicious proposals (Beanstalk Farms was drained this way). Short voting period: not enough time for community review. Scope creep: governance voting on operational decisions that should be delegated.

Practical Governance Design

Start simple — treasury multisig + community signaling before moving to on-chain governance. Deploy full on-chain governance only when you have sufficient decentralization. Keep the scope of governable parameters tight at first. Use Snapshot for off-chain signaling before binding on-chain votes. Build a guardian/security council that can veto malicious proposals with a 24-hour delay.