DAO governance is now an operating system for real capital
DAO governance already controls real capital. A 2024 large-scale study counted more than 13,000 DAOs, 11.1 million governance token holders, and $24.5 billion in aggregate treasuries. That scale changes the analytical frame. DAOs are no longer interesting because they replace managers with token polls. They matter because they encode budget authority, upgrade authority, and emergency authority into public rules.
The important design question is therefore not whether a project has “a DAO.” The real question is which decisions are governed by deterministic contracts, which are delegated to representatives, and which remain social coordination problems. The strongest live systems already look like layered governance stacks rather than pure one-token-one-vote machines. Compound governance combines a token, a Governor module, and a Timelock. ENS separates executable proposals, social proposals, and constitutional amendments. Arbitrum distinguishes constitutional from non-constitutional AIPs and adds waiting periods across L2 and L1. Optimism splits governance across a Token House and a Citizens’ House, then adds a veto-based upgrade process.
That evolution is rational. Pure token voting is too blunt for a system that needs to allocate treasury funds, change protocol parameters, manage grants, and handle security incidents. Once the asset under governance becomes large enough, the mechanism has to become more explicit about thresholds, time delays, proposal classes, and exception handling.
The mechanism is the governance
Governance quality in Web3 is mostly determined by a short list of parameters. Proposal threshold decides who gets agenda power. Snapshot rules decide when voting power is fixed. Quorum decides how much participation is needed. Timelocks and waiting periods decide whether users can exit before execution. Execution rules decide whether a passed vote is self-executing, multisig-mediated, or still socially enforced. OpenZeppelin’s standard Governor modules expose exactly these levers through voting delay, voting period, proposal threshold, quorum logic, and timelock integration.
| System | Agenda gate | Pass condition | Execution delay | What this architecture optimizes |
|---|---|---|---|---|
| Compound | >25,000 COMP to propose, or 100 COMP for an autonomous proposal that later reaches delegated support. | Majority support and at least 400,000 votes cast for the proposal. Voting lasts 3 days after a 2 day review period. | 2 day timelock after passage. Any change takes at least about one week end to end. | Fast, legible parameter governance with a hard-coded execution delay. |
| ENS | At least 0.1% of all ENS delegated to the proposer address, currently described as 100,000 ENS. | Executable and social proposals require 1% quorum and 50% approval. Constitutional amendments require 1% quorum and a two-thirds majority. | Snapshot votes run 5 days. Executable onchain proposals then have a 7 day voting period and a minimum 2 day timelock. | Separation between enforceable actions and value-level constitutional commitments. |
| Arbitrum DAO | 1,000,000 votable ARB delegated to the proposer for a formal AIP. | More votes for than against, plus quorum of 3% of votable tokens for non-constitutional AIPs or 4.5% for constitutional AIPs, counting “in favor” and “abstain.” Voting lasts 14 days and can extend 2 more days if quorum is reached late. | 3 day L2 waiting period for treasury actions or 8 day L2 waiting period for L2-to-L1 messages, then L1 finalization and an extra 3 day L1 waiting period for constitutional actions. The constitution states roughly 27 days for non-constitutional AIPs and 37 days for constitutional AIPs from temperature check to implementation. | High-friction governance for upgrades and treasury movement, with explicit exit windows. |
| Optimism Collective | Not a single-token lane. Governance is split across the Token House and the Citizens’ House, and protocol upgrades are reviewed by the Developer Advisory Board. | Citizens’ House uses a 1 member, 1 vote model. Citizens also elect DAB representatives and can ratify core documents. | After DAB review, protocol upgrades enter a 7 day veto period. | Stakeholder checks and balances rather than pure capital-weighted control. |
The pattern is clear. Mature DAOs no longer rely on one voting rule. They classify proposals and match each class to a different latency, quorum, and legitimacy threshold. That is a mechanism-design response to the fact that “send treasury funds,” “upgrade core code,” and “signal community preference” are not the same decision.
Token voting scales badly without a representative layer
Token voting is still the default primitive, but the public record shows why it is insufficient on its own. A 2024 empirical study of Compound, Uniswap, and ENS found that voting power is heavily concentrated in a small number of addresses. The same study also found an important nuance: those large holders rarely overturned a result that differed from the broader community outcome. Concentration is real, but it does not automatically mean constant abuse. This is especially visible in DeFi governance.
The deeper problem is that low participation and delegation turn governance into a representative system whether the DAO acknowledges it or not. Another study found that contributors or vested users held the necessary majority on average in at least 7.54% of DAOs, and had singularly decided at least one proposal in 20.41% of DAOs. The same paper observed shifts in token ownership shortly before governance polls in 1,202 of 8,116 proposals, or 14.81%.
That evidence matters for design. Snapshot calculates voting power at proposal creation time, and OpenZeppelin-style governance reads votes at a defined timepoint, which protects the vote from mid-process balance changes. But those safeguards only freeze power after the relevant checkpoint. They do not stop pre-snapshot accumulation, delegation campaigns, or coordination among large holders.
Delegation is therefore best understood as a scaling hack, not as decentralization itself. Compound allows holders to delegate to themselves or another address. ENS, Uniswap, and other large DAOs rely on visible delegate classes for the same reason. Representation increases throughput, but it also creates agenda setters, reputation effects, and concentration around a small active set of delegates. The mechanism-design trade-off is straightforward: more adaptability and voter convenience usually means less direct participation and more dependence on a quasi-political class.
There is also a countervailing result worth keeping in view. The large-scale DAO study on 100 DAOs found that higher grassroots participation correlates with higher decentralization, and lower variance in voting power correlates with more decentralized outcomes. That does not eliminate the need for delegates. It does suggest that a DAO should treat participation engineering as a core governance function rather than a marketing task.
Offchain signaling is useful, but only if execution stays constrained
Offchain governance tooling solved a real coordination problem. Snapshot lets users vote with a gasless Ethereum signature in many configurations, and voting does not affect the funds in the user’s account. Snapshot also lets a space combine up to 8 voting strategies, which means voting power can be derived from more than a single ERC-20 balance. The official docs explicitly note that strategies can use non-monetary onchain data such as POAPs or NFTs.
That flexibility is good for discovery, signaling, and prioritization. It is weaker for binding treasury execution. Snapshot’s own SafeSnap plugin exists because many DAOs need a bridge from offchain voting to onchain action. SafeSnap routes a passed Snapshot vote through a Reality.eth question and then allows execution after a 24 hour cooldown. Snapshot recommends substantial bonds, an arbitrator, long cooldowns, and monitoring. Those are not cosmetic extras. They are the missing enforcement layer.
The design implication is inferential but strong. Offchain voting is best used where cheap participation matters more than immediate finality. Treasury transfers, contract upgrades, and role changes should either execute onchain through constrained governor logic or pass through a tightly specified execution rail with explicit challenge windows and monitoring. Compound’s timelock model, ENS’s executable proposal lane, and Arbitrum’s multi-stage waiting periods all point in that direction.
This is where many DAOs quietly fail. They keep the legitimacy theater of token voting while routing actual execution through under-specified multisigs, councils, or service providers. Once that gap becomes large enough, the DAO has not decentralized governance. It has only decentralized recommendation while centralizing execution. That is an inference from how these systems are structured, not a universal accusation, but the mechanism risk is clear.
The best DAOs narrow discretion instead of pretending to remove humans
Rule-based governance does not mean human-free governance. It means human discretion is boxed in by proposal classes, voting thresholds, and narrowly defined exceptional powers. ENS is explicit about this. Its binding rules state that fees are primarily an incentive mechanism, that treasury income must first support ENS’s long-term viability and ongoing development, and that constitutional amendments require a two-thirds majority with at least 1% of all tokens participating.
Arbitrum makes the same move in a more security-oriented way. Its constitution separates constitutional and non-constitutional AIPs, defines different quorum thresholds, and inserts long waiting periods before implementation. It also gives a 12-member Security Council emergency and non-emergency powers, but those powers are bounded. Emergency actions require 9 of 12 approvals, are justified only for true security emergencies, and must be followed by a transparency report.
Optimism pushes the design further by rejecting pure capital-weighting for all decisions. Its Citizens’ House uses one-member-one-vote, citizens elect representatives to the Developer Advisory Board, and protocol upgrades face a 7 day veto period after DAB review. Optimism also assigns governance-specific rights protections, including blocking votes against Foundation document changes that would materially reduce token holder rights.
The tension is obvious. More discretionary bodies improve operational speed and can handle expert review. More deterministic rules improve predictability and reduce capture surface. The evidence from live systems suggests the best balance is not “more flexibility.” It is constrained flexibility: councils with explicit scope, constitutional lanes for core changes, hard timelocks for execution, and public reporting when exceptional powers are used.
What this means for token economy design
DAO governance works best when the token economy is designed around narrow, legible rights rather than vague community sovereignty. For practical token economy design, five rules stand out:
- Govern fewer things. Put routine operations behind clear policy rails or service mandates. Reserve token votes for upgrades, treasury allocation, constitutional changes, and other high-impact choices. Systems such as Compound, ENS, and Arbitrum already separate these lanes in different ways.
- Separate proposal classes. A budget proposal should not face the same mechanism as a core protocol upgrade. ENS and Arbitrum both formalize this separation, and the difference improves interpretability for voters.
- Treat delegation as an institution. Delegation needs disclosure, performance expectations, and rotation pressure because it creates a representative layer whether the DAO planned for one or not. Empirical work on Compound, Uniswap, ENS, and broader DAO samples shows why.
- Make execution slower than sentiment. Cheap signaling can be fast. Binding execution should be slower, monitored, and challengeable. Snapshot plus SafeSnap, OpenZeppelin timelocks, and Arbitrum’s waiting periods all encode this principle.
- Design emergency powers as exception handling, not shadow governance. Arbitrum’s Security Council and Optimism’s veto-based upgrade process are useful because their authority is scoped and proceduralized. If a fast path has no explicit trigger, quorum, or reporting duty, it is not an emergency path. It is the real governor.
For funding allocation in particular, the implication is direct. Governance should decide budgets, eligibility rules, evaluation criteria, and review cadence. It should not force the full token-holder base to micromanage every grant or contributor task. ENS’s constitution frames treasury use around protocol sustainability and public goods, while Optimism explicitly uses governance for resource allocation and retroactive funding. The durable pattern is parameterized delegation, not perpetual plebiscite.
At FinDaS Tokenomics, this is the practical lens we use for tokenomics consulting. The hard part of tokenomics design is rarely inventing another vote. The hard part is assigning the right decision to the right mechanism, with the right threshold, the right delay, and the right execution path. That is where tokenomics consulting stops being branding and becomes institutional engineering.
