Token governance is the mechanism that lets token holders propose and vote on changes to a protocol or its treasury. Protocol governance can enforce outcomes onchain through smart contracts; blockchain governance cannot, because validators decide for themselves whether to upgrade. Token-weighted voting is the dominant model and the most flawed one, so before launching a DAO, every founder needs a plan for capture, low turnout, and legal liability.
What protocol governance actually is
Governance is the set of rules by which a token-based system makes decisions and changes itself over time. In practice it answers two questions: who can propose a change, and how does that change actually take effect onchain. For a smart contract protocol like Aave or Curve, the answer is mechanically clean. A proposal is filed, token holders vote, a timelock buffer protects against rushed exploits, and if the vote passes a smart contract executes the parameter change automatically.
The Compound governance flow below is the canonical version of this loop. Note the pieces that matter: a proposal threshold (you need to hold or be delegated some minimum stake to file at all), a voting window, a queueing step that pushes the action into a timelock contract, and only then execution. Each step is enforced in code, not by social agreement, and that is what makes protocol governance binding rather than advisory.
The thing many founders miss is that this only works for protocols. Layer 1 blockchain governance is structurally different and structurally weaker. A vote on Cosmos Hub or Polkadot can pass, but no smart contract can compel validators to upgrade their client software. Even formally governed L1s rely on social coordination and release cycles to land changes, which means if you are designing an L1 your governance vote is a signal to developers, not a binding mechanism for the network itself. That is an important honesty point at design time, because the language of "onchain governance" hides this distinction.
Why decentralization-by-default failed in 2021
Back in 2021 every protocol wanted to be a DAO. The reasoning was rarely "decentralization makes the product better." More often it was "we will be harder for the SEC to prosecute if no single entity controls the protocol," and that theory has not aged well. Regulators have prosecuted DAOs anyway, and the operating cost of running everything through a 7-day voting cycle has been far higher than projects expected.
When I was CPO for Bridge Mutual we were genuinely afraid of SEC scrutiny, so we did what every project was doing at the time. We structured BMI as a "valueless governance token". The plan was that once governance kicked in we would use part of the protocol fees to buy back and burn the token, creating value while telling the SEC the token was just a vote. Two problems with this. First, there is no actual evidence that the "valueless governance" framing protects you from US securities enforcement. Second, while you are trying to convince the SEC the token has no value, your users are reading the same materials. They believe you. And then they do not buy your token.
The other thing that surfaced quickly was the operational tax. Decisions take a long time. Critical bugs need rapid response, and you cannot fix a vulnerability if your voting window is a week. Most projects also have a setup that does not lend itself to onchain governance at all: a frontend that depends on offchain APIs, a treasury that holds fiat, a team that needs to ship features. Before you commit to a DAO, map out the actual governance process: how proposals are filed, how voting is run, how the change reaches the chain. Then ask which of those steps you would realistically run onchain. Most of the time the honest answer is fewer than you would like.
Token-weighted voting is structurally broken
If your governance process awards votes proportional to token balance, you have created an oligarchy with extra steps. The data is now conclusive enough that this is no longer an open question. A December 2024 Cambridge Centre for Alternative Finance study of ten major DeFi DAOs (Aave, Compound, Convex, Curve, Frax, Instadapp, Lido, MakerDAO, Rocket Pool, Uniswap) measured Gini coefficients between 0.97 and 0.99. For comparison, South Africa, the most income-unequal country in the world, sits around 0.63.
The numbers underneath those coefficients are blunt. At Aave alone, the top 121 wallets collectively hold roughly 73% of the AAVE token supply. Across the broader DAO ecosystem, voter turnout averages below 10%, and the top 10% of token holders control more than three quarters of all voting power. This is not a quirk introduced by bad actors. Token-weighted voting converts wealth into authority by design, and any DAO using it should plan around that fact rather than pretend it is not happening.
What this implies for design is uncomfortable. If you award votes by token balance, the question is not whether your protocol is centrally controlled, it is who that small set of central controllers will be and how transparent their incentives are. A protocol where five named delegates with public records run governance is honestly more accountable than one where five pseudonymous wallets coincidentally always vote together. The transparency of the centralization is what differentiates a viable governance system from theatrical one.
Governance attacks are now routine
Treat governance attacks as a baseline operational risk, not a tail event. Beanstalk Protocol lost $182 million in April 2022 to a flash-loan governance attack. The attacker used a flash loan to acquire 79% of governance voting power for a single transaction, passed two malicious proposals (one a decoy donation to Ukraine, one draining the treasury), and repaid the loan in the same transaction block. The vulnerability was a function called emergencyCommit that allowed proposals to execute the moment they had supermajority support, with no timelock between vote and execution.
The Compound DAO "GoldenBoyz" episode of 2024 shows the slower-burn version of the same problem. A delegate group associated with a notorious whale staged three progressive proposals (numbers 247, 279, and 289) over several months to transfer 499,000 COMP, roughly $24 million, from the treasury to a vault they would manage. The first failed quorum. The second was voted down. The third passed, narrowly, by 682,191 votes to 633,636, with only 57 wallets participating in the decisive vote. Compound only avoided losing the funds by negotiating with the attackers to rescind the proposal in exchange for a redesigned staking mechanism. The pattern across both attacks is consistent: token-weighted onchain execution plus low voter turnout creates a capture vector, and any protocol fitting that profile is on a clock.
If you are shipping governance, four mitigations should be non-negotiable from day one:
- Timelocks. A delay between vote passage and execution gives the community time to detect and respond. Compound had no working timelock between proposal passage and execution at the time of the GoldenBoyz vote, which was the structural reason the third proposal could go live before defenders coordinated.
- Guardian multisig with veto power. A small group with a kill switch is a pragmatic check on edge cases, even though "guardians" sounds anti-decentralization. The honest framing is that every working DAO has one, formal or informal.
- Quorum minimums. Without a meaningful quorum, three coordinated holders can execute on any proposal that the rest of the community ignores. A quorum that requires a real fraction of total supply forces governance attackers to commit more capital, which surfaces them earlier.
- Flash-loan resistance. Use snapshot-based voting (vote weight measured at a past block), not current-balance-based. Flash loans collapse the cost of borrowing voting weight to nearly zero, and Beanstalk is what that costs.
Your DAO is not the legal entity
Without a legal wrapper, a DAO in most US jurisdictions is a general partnership. That means members may be jointly and severally liable for the DAO's actions. The CFTC v. Ooki DAO case, filed in 2022 and decided by default judgment in June 2023, established that a DAO can be sued as an unincorporated association under California and federal law, and that token holders who voted to govern the protocol could be reached by the suit. The Sarcuni v. bZx DAO ruling in March 2023 went further, holding that token holders could face joint and several liability as members of a general partnership for the DAO's negligence. Most DAOs operating without a wrapper today are running this exposure profile.
This problem has solvable structural answers, and the standard playbook has stabilized. Wyoming's DUNA framework (passed March 2024, effective July 2024) and the Marshall Islands DAO LLC ("MIDAO") are now the two most common wrappers. Uniswap Foundation proposed adopting DUNA (called "DUNI") in August 2025 as a precondition for turning on the protocol's fee switch, with $16.5 million in UNI allocated specifically for back tax obligations and a legal defense budget. This is not a hypothetical concern. The largest DAO in DeFi voluntarily wrapped itself in a US legal entity rather than continue operating without one.
Launching a DAO in 2026 without a legal wrapper is not decentralization. It is exposure.
The standard multi-entity structure for a tokenized protocol is now: a DevCo handling product development, a foundation in a jurisdiction with established crypto-friendly legal infrastructure (Cayman, Panama, Liechtenstein, Switzerland), and optionally a DUNA or MIDAO wrapping the token-holder community. The foundation typically holds the treasury, employs the core contributors, and signs counterparty agreements. The DevCo handles software. The DAO handles parameter votes and treasury allocation. Each entity has a defined function and a defined liability surface, which is what makes the structure work.
Progressive decentralization is the consensus playbook
Nobody serious is recommending day-one DAOs anymore. The consensus operating model that has emerged in 2025 is progressive decentralization: start with a small, trusted team and centralized decisions, then decentralize specific functions over time as the protocol matures. Premature decentralization is now widely recognized as an anti-pattern, and this is not a compromise position. It is what the protocols that actually shipped have all converged on.
The sequence that works tends to look like this:
- The team controls admin keys directly while the protocol is small and the surface area is changing weekly.
- Admin keys move to a multisig once the team is more than two people and changes are more deliberate.
- The multisig is paired with a timelock so any change is visible before it executes.
- Limited governance opens to token holders for parameter tweaks and grant allocation, but not core code.
- Core protocol changes open to governance last, sometimes never.
If you are designing this roadmap and want the governance design stress-tested in a tokenomics audit before launch, the worst time to discover a structural flaw is the day after token generation. The right time is before you have publicly committed to a model. A separate question worth working through is treasury control, which usually decentralizes faster than the protocol code. Parameter votes around grant allocation are much lower-stakes than upgrades to the core, so opening those first lets the community build voting muscle without putting the protocol at risk. If you have not worked through how the treasury will be governed separately from the protocol itself, that is a gap.
Minimization, delegation, and the search for a better mechanism
Two design philosophies sit on opposite ends and both are valid. Governance minimization is the Uniswap and Aave approach. Both have progressively narrowed what governance can actually do, with Uniswap v3 and v4 restricting governance to a small set of parameters while most of the protocol is immutable. The philosophy is the inverse of "more decentralization equals better": the best governance is the governance you do not need. If your protocol's core logic never changes, there is no attack surface for governance attacks because there is nothing meaningful to attack. The tokenomics design question this poses is whether the protocol needs governance at all, or whether it can ossify the core and use governance only for treasury allocation and edge parameters.
The opposite philosophy is delegation, and it has produced the centralization vector everyone warned about. Most large DAOs moved to delegation models because direct voting does not scale, but in practice delegation concentrates power in a small number of professional delegates, and those delegates are often the same VCs that received early allocations. A 2024 Bubblemaps investigation showed that a16z-controlled wallets collectively held enough UNI to unilaterally clear Uniswap's 4% governance threshold, and a16z used this in 2023 to block a Wormhole bridge proposal in favor of LayerZero, where they had competing investments. If you are designing a delegation model, the question to answer up front is whether you can prevent this exact scenario. Delegation caps, public delegate disclosure, conviction voting that weights long-term commitment, and visible voting records are all mechanisms worth considering. None of them solves the problem fully.
Then there are the alternative voting mechanisms. Quadratic voting (vote cost increases quadratically with vote count) is used by roughly 100 DAOs, including Gitcoin and several Optimism projects. Conviction voting weights support by duration of commitment. Vote-escrow (ve) locking, popularized by Curve, weights by lockup time and is closely linked to token utility design. Tamai and Kasahara (2024, Frontiers in Blockchain) showed quadratic voting alone is vulnerable to collusion, while a hybrid of quadratic plus vote-escrow performs better in simulation. The honest framing is that no alternative mechanism has been deployed at the scale of token-weighted voting and shown clear superiority. Most protocols default to token-weighted despite its known flaws because the alternatives have unresolved problems of their own. That state of affairs may not last, but it is where 2026 starts.
More from the 101 series
Frequently Asked Questions
01When should a project skip launching a DAO entirely?
+
02Does a small DAO with a modest treasury actually need a legal wrapper?
+
03Can a small protocol manage its treasury without formal governance?
+
04Is quadratic voting actually better than token-weighted voting in practice?
+
