Most governance systems work fine until they don't. The DAO votes on parameter changes. The multisig executes. The treasury grows. Everyone feels decentralized. Then someone figures out that quorum is 4% of total supply and 60% of tokens sit in cold wallets that never vote. Now 4% is really 10% of circulating supply. And 10% of circulating supply is one whale with a Telegram group.

I have watched three governance failures up close in the last two years. Not theoretical attacks from blog posts. Real proposals that passed, real money that moved, real communities that fractured. Here is what went wrong and what you should actually do about it.

Failure one: quorum gaming at Beanstalk

In April 2022, Beanstalk's governance had a fatal design flaw. Proposals could pass with a simple majority of votes cast, and there was no time lock between proposal passage and execution. An attacker took a flash loan, acquired enough governance tokens to pass a proposal in a single transaction, and drained $182 million from the protocol.

The mechanics were straightforward. Borrow tokens. Vote. Execute. Repay. All in one block. The governance system had no concept of "you need to hold these tokens for a while before you can vote." It just counted balances at the moment of the vote.

The fix is snapshot voting with a lookback period. When a proposal is created, the contract records the current block number. Voting power is determined by token balances at that snapshot block, not at the time of the vote. Flash loans do not help because the attacker did not hold the tokens at the snapshot. OpenZeppelin's Governor contract does this by default with ERC20Votes and the proposalSnapshot() function. If you are not using snapshot voting in 2026, stop reading and go fix that first.

But snapshot voting alone is not enough. You also need a meaningful time delay between proposal creation and voting start. Compound's Governor Bravo uses a voting delay of roughly two days. This gives the community time to see the proposal, discuss it, and organize a response. Without the delay, an attacker can create and pass a proposal before anyone notices it exists.

Failure two: proposal spam and voter fatigue

A mid-sized DeFi protocol we advised (I will not name them, they are still a client) had a governance system where any token holder with 0.1% of total supply could submit a proposal. That sounds reasonable. In practice, one disgruntled community member submitted 47 proposals in two months. Most were nonsense. A few were near duplicates of rejected proposals with slightly different parameters.

What happened next was predictable. Active voters stopped paying attention. Quorum dropped from 12% to 3%. The one serious proposal that quarter, a critical security patch to the lending pool, barely passed with 3.2% participation. A protocol managing $40 million in TVL had its security upgrade approved by holders of $1.28 million in tokens.

Proposal spam is a denial of service attack on voter attention. The defense has several layers.

First, raise the proposal threshold. 0.1% is too low for most protocols. Compound uses 1% of total supply to create a proposal. That is roughly $5 million in COMP at current prices. That is not a rounding error. It means proposers have real skin in the game.

Second, add a proposal bond. The proposer deposits tokens that are returned if the proposal reaches quorum (regardless of outcome) and slashed if it does not. This makes spam expensive without preventing legitimate proposals that the community actually cares about. Nouns DAO experimented with this model and it reduced low-quality proposals significantly.

Third, implement proposal velocity limits. No more than N active proposals at once. No new proposals from the same address within M blocks of their last proposal. Simple rate limiting that any engineer would apply to an API but that governance designers routinely forget.

Failure three: timelock configuration as a trojan horse

Timelocks are supposed to be the safety net. A proposal passes, then sits in a queue for 48 hours (or whatever the delay is) before it can be executed. During that window, users can review the on chain actions and exit the protocol if they disagree.

In late 2023, a protocol on Arbitrum (this one was public, it was Mochi Protocol's USDM situation) had a timelock set to 6 hours. Six hours. On a weekend, the core team pushed through a proposal that changed the collateral parameters on their stablecoin. By the time most community members saw the transaction in the timelock queue, it was already past the delay window and executed. The parameter change made the stablecoin undercollateralized. The peg broke within 48 hours.

Six hours is not a timelock. It is a speedbump. For any protocol managing meaningful value, 48 hours is the minimum. Many serious protocols use 7 days. Yes, that means emergency fixes take a week. That is the tradeoff. You can have a fast governance system or a safe one. Pick one.

The escape hatch for emergencies is a guardian role. A multisig (usually the core team or a security council) that can pause the protocol or veto a proposal during the timelock period. This is centralization. Acknowledge it. Document it. Put sunset clauses on it. But do not pretend you can run a protocol with $50 million in TVL and a 7 day timelock and no emergency brake.

Compound has this. Aave has this. MakerDAO had the GSM (Governance Security Module) with a 48 hour delay plus an emergency shutdown module. These are not training wheels. They are load-bearing safety infrastructure.

Configuration decisions that look boring but aren't

Quorum percentage. Too low and proposals pass without real consensus. Too high and nothing ever passes. We have seen protocols set quorum at 20% of total supply and then spend six months unable to pass any proposal because whale holders do not vote. A reasonable range for most protocols is 4% to 10% of total supply, with the understanding that you should track actual voting participation and adjust over time.

Voting period length. Compound uses roughly 3 days. That is fine for simple parameter changes. For proposals that move treasury funds or change core protocol logic, consider longer periods. Some protocols use tiered voting periods where higher impact proposals require longer voting windows. This adds complexity but reflects the reality that "change the fee from 0.3% to 0.25%" and "migrate the entire treasury to a new contract" should not have the same approval process.

Delegation. Without delegation, governance participation is limited to active token holders. With delegation, a few professional delegates can represent thousands of passive holders. Gitcoin and Optimism have invested heavily in delegation. It works, but it creates its own power dynamics. A delegate with 5% of voting power who goes inactive can swing quorum calculations. Build in delegate activity requirements and automatic undelegation after N missed votes.

What I tell teams building new governance

Start with a multisig. Seriously. A 4 of 7 multisig with known, doxxed signers is more secure than a token governance system with 2% quorum and a 6 hour timelock. It is also more honest about where power actually sits.

When you move to token governance, use OpenZeppelin's Governor as your base. It handles snapshot voting, timelocks, and proposal lifecycle correctly. Do not write your own governance contract from scratch. I have reviewed custom governance implementations. They all had bugs. Every single one.

Set your timelock to at least 48 hours. Include a guardian multisig that can cancel proposals during the timelock window. Set your quorum based on observed voting participation, not theoretical token distribution. Add a proposal bond. Rate limit proposals.

And monitor your governance. Set up alerts for new proposals, large delegation changes, quorum threshold approaches, and timelock queue additions. Governance attacks are slow enough to see coming if you are paying attention. The protocols that get burned are the ones that stopped watching.