3.11.6 Governance Attacks

Most DeFi protocols are governed by tokens. The token holders vote on proposals: parameter changes, treasury allocations, protocol upgrades, fee distributions. The token is, in principle, an economic stake — holders with more tokens have more influence because they have more skin in the game. In practice, the security of governance is determined not by the principle but by the mechanics: how votes are weighted, how proposals are gated, what happens when voting power can be acquired temporarily, and what attackers can buy at the margin.

This subsection covers the design problem. Governance attacks are not a single vulnerability class — they are a category of attacks that exploit the gap between governance's intent ("decisions are made by stakeholders with long-term economic interest") and governance's mechanism ("decisions are made by whoever holds tokens at the moment of the vote"). The attack patterns vary, but they share a common shape: an attacker acquires voting power without acquiring long-term economic interest, votes for a proposal that benefits them at the protocol's expense, and exits before the consequences hit.

The category has produced both spectacular failures (Beanstalk, $182M, April 2022) and slow-burn losses (governance-token markets routinely show selling pressure correlated with proposal outcomes). The defenses are mostly not about smart contract code in the conventional sense — they are about the design of the voting mechanism, the gating between voting and execution, and the incentive structure around governance participation.

What Governance Attacks Actually Look Like

Three concrete patterns capture most governance attacks:

1. Flash Loan Governance Attacks

The attacker takes a flash loan large enough to acquire a controlling share of the governance token. They use the temporary voting power to pass a malicious proposal — typically one that transfers the protocol's treasury to an attacker-controlled address. They repay the loan from the proceeds.

The canonical case: Beanstalk Farms (April 2022, $182M). Beanstalk's governance allowed proposals to execute immediately upon passing if they reached a 2/3 supermajority. The attacker took a flash loan from Aave for approximately $1 billion in stablecoins, deposited them as collateral on Beanstalk to acquire governance tokens, voted in favor of a previously-submitted malicious proposal that transferred the protocol's funds to themselves, and repaid the flash loan with the stolen funds. The full sequence executed in a single transaction.

The proposal text had been visible for the entire voting window. Beanstalk used a "fundraiser" pattern that, when combined with a 2/3 instant-execution threshold, meant any actor with enough capital for one transaction could pass any proposal they had previously submitted. The flash loan provided the capital.

2. Vote-Buying Attacks

The attacker pays existing token holders to vote a specific way. Unlike flash loans, this doesn't require acquiring the tokens — just renting their voting power. Markets like Cobra Finance, Hidden Hand, Bribe.crv, and Convex's vlCVX market made this explicit, providing infrastructure for paying for votes on specific proposals.

The mechanism is usually:

  1. A proposal exists on a target protocol
  2. An attacker (or whoever wants the proposal to pass) posts a "bribe" on a bribe marketplace
  3. Token holders who haven't voted yet can claim the bribe by voting the desired way
  4. The bribe market settles after the vote

The legality and ethics of vote-buying markets remain contested. The technical reality is that they exist and have moved hundreds of millions of dollars in observed vote outcomes. Curve's gauge weight voting (which determines CRV emission distribution across pools) is the most-bribed governance system in DeFi, with weekly bribe pools running into the tens of millions of dollars.

For most protocols, the threat is more limited: bribes only have to outvalue the voter's perceived stake in the outcome. For decisions where most holders are passive, even small bribes can shift outcomes.

3. Proposal-MEV Sandwiches

A proposal passes that will change a protocol parameter — fees, interest rates, asset listings, etc. The change creates a brief arbitrage window between the proposal's execution moment and the time markets adjust. Searchers position transactions immediately before and after execution to capture the difference.

This isn't quite a "governance attack" in the usual sense — it doesn't subvert governance, it exploits the inevitable consequences of governance. But it does mean: governance decisions create extractable economic events at their moment of execution, and the value extracted by searchers is value not captured by the protocol or its users.

Other Patterns

Several less-common but still significant patterns:

  • Long-tail voter apathy. Many protocols have voting participation below 10% of total tokens. An attacker who accumulates a smaller absolute amount can dominate the active vote.
  • Delegate concentration. Vote delegation concentrates power in a few addresses; compromising any single delegate can shift outcomes. This was a contributing factor in the 2023 Tornado Cash governance compromise where an attacker passed a malicious proposal by using a previously-undisclosed mechanism (allocating their proposal's bytecode space cleverly to grant themselves admin rights).
  • Time-based exploits. Proposals that execute too quickly after passing prevent the community from responding. Proposals that don't execute for a long time after passing allow market conditions to change.

The Voting Mechanism's Trust Model

Like bridges, governance has a trust model that the protocol designer must make explicit. The honest question: what does it cost to capture this governance system?

For a flash-loan-resistant governance with checkpointed voting:

Cost to capture = (price per token) × (tokens needed to reach quorum + 1)

For a flash-loan-vulnerable governance (no checkpointing, instant execution):

Cost to capture = (flash loan fee) × (loan amount to acquire tokens) + gas

The two numbers are typically separated by three or more orders of magnitude. Checkpoint-based voting forces the attacker to actually hold the tokens at a previous point in time, which means actually buying them with real capital and bearing the market-price exposure. Flash-loan-vulnerable voting allows the attacker to rent the tokens for one transaction at near-zero cost.

The same design principle as bridge architecture: the security level is determined by the cheapest path to capture, not by the difficulty of the "intended" path.

Defenses Against Flash-Loan Governance Attacks

The Beanstalk pattern is preventable with one of several specific mechanisms.

1. Checkpointed (Snapshot-Based) Voting

The voting weight at the time of the vote is taken from a snapshot at an earlier block (typically the block when the proposal was submitted, or some block before that). Acquiring tokens after the snapshot does not increase voting power.

contract CheckpointedGovernance {
    IERC20Votes public immutable token;
    mapping(uint256 => Proposal) public proposals;
    uint256 public proposalCount;

    struct Proposal {
        uint256 snapshotBlock;
        uint256 votesFor;
        uint256 votesAgainst;
        uint256 executableAt;
        bool executed;
        bytes32 actionHash;
    }

    function propose(bytes32 actionHash) external returns (uint256) {
        uint256 id = ++proposalCount;
        proposals[id] = Proposal({
            snapshotBlock: block.number,
            votesFor: 0,
            votesAgainst: 0,
            executableAt: 0,
            executed: false,
            actionHash: actionHash
        });
        return id;
    }

    function castVote(uint256 proposalId, bool support) external {
        Proposal storage p = proposals[proposalId];
        require(p.snapshotBlock > 0, "no proposal");

        // Voting power is taken from the snapshot block, not the current block
        uint256 weight = token.getPastVotes(msg.sender, p.snapshotBlock);
        require(weight > 0, "no voting power at snapshot");

        if (support) p.votesFor += weight;
        else p.votesAgainst += weight;
    }
}

OpenZeppelin's Governor contract uses this pattern. The snapshot mechanism makes flash-loan governance attacks economically infeasible — the attacker would have to hold the tokens for the entire window between snapshot and vote, paying actual market price and bearing all the associated risk.

ERC20Votes (OpenZeppelin's voting-compatible ERC-20) is the standard token implementation: it maintains a history of vote balances per address, queryable at any past block.

2. Timelocked Execution

Even with checkpointed voting, the gap between vote and execution should not be zero. The Compound timelock pattern:

contract TimelockController {
    uint256 public constant DELAY = 2 days;
    mapping(bytes32 => uint256) public queuedActions;

    function queue(bytes32 actionHash) external onlyAdmin {
        queuedActions[actionHash] = block.timestamp + DELAY;
    }

    function execute(bytes32 actionHash, bytes calldata callData) external onlyAdmin {
        require(queuedActions[actionHash] != 0, "not queued");
        require(block.timestamp >= queuedActions[actionHash], "delay not met");

        delete queuedActions[actionHash];
        // ... execute the action
    }

    function cancel(bytes32 actionHash) external onlyAdmin {
        delete queuedActions[actionHash];
    }
}

A timelock requires the action to be queued before it can execute, with a minimum delay. The community has the delay window to observe the queued action, respond to anything malicious, exit the protocol if necessary, or coordinate a cancel.

The right delay depends on the protocol. Two days is the historical Compound default. For high-value protocols, 7-14 days is increasingly common. The principle: enough time for stakeholders to respond to anomalous proposals, but not so long that legitimate governance becomes impractical.

3. Quorum and Supermajority Requirements

Beanstalk's vulnerability included a 2/3 supermajority threshold. With checkpointed voting and a sufficient quorum, even acquiring 2/3 of tokens at market price is dramatically more expensive than acquiring them via flash loan. Combined with a sufficiently long voting window, the cost rises further.

The tradeoffs: too-high quorum thresholds can prevent legitimate governance from acting at all. Too-low thresholds let small minorities act. Most modern Governor contracts use 1-10% of total supply for quorum, with simple majority for routine votes and supermajority (66%, 75%) for amendments to the constitution.

4. Delegation and Vote Concentration

ERC20Votes allows holders to delegate their voting power to representatives. This is healthy for some governance — most holders won't vote on every proposal, so delegating to active participants is functional. It also concentrates power, which can be exploited (a delegate's compromised key acquires the delegated power).

Defenses:

  • Document the trust model: "delegated tokens vote with the delegate's choices"
  • Provide easy un-delegation
  • Require explicit re-delegation when a delegate's address changes
  • Consider quadratic voting or other weighting that diminishes the marginal power of concentrated stakes

The quadratic voting tradeoff: it requires identity (otherwise an attacker creates 100 wallets and votes from each), which conflicts with permissionless governance.

Defenses Against Vote-Buying

Vote-buying is harder to prevent at the contract level — voters' decisions are voluntary, and a contract cannot observe whether a voter received off-chain payment.

The defenses are mostly at the governance design level, not the contract level:

Discourage Concentration

Markets like Hidden Hand pay vote-buyers based on tokens delegated to specific protocols (Convex's vlCVX) where vote delegation is concentrated. If governance is distributed across many small holders, no single bribe target captures meaningful voting power.

This is partially in tension with practical reality: large holders exist, governance tokens trade like equity, and protocols routinely have a few entities holding double-digit percentages. The defense is real but bounded.

Make Voting Costs Higher than Bribes

Some protocols require voters to lock tokens for an extended period (veToken model, popularized by Curve). The longer the lock, the more voting power. This creates a long-term commitment that aligns with the protocol's interest.

The tradeoff: long locks reduce liquidity for token holders. The veToken model has been adopted widely (Curve, Balancer, Aura, etc.) and has produced genuine alignment in some cases. It has also produced the largest vote-buying markets in DeFi (Curve's gauge weight battles), so the alignment is partial.

Disclose Conflicts of Interest

Some governance frameworks require voters to disclose external positions that might bias their vote. Enforcement is operational rather than technical. The frameworks that include disclosure (e.g., MakerDAO's delegation system) tend to produce more reasoned debate but are not bribe-proof.

Reduce the Stakes

The most reliable defense: don't give governance much power. A protocol whose governance can transfer the treasury is more attackable than a protocol whose governance can only modify a few parameters within hard-coded bounds.

The pattern: hardcode the most consequential decisions (caps on fees, immutable distribution of revenue, fixed asset whitelist) and leave only secondary parameters to governance. This limits the attack surface dramatically.

Defenses Against Proposal-MEV

Section 3.11.3 covers MEV defenses generally. For governance-specific cases:

Stagger Parameter Changes

Major parameter changes can be staggered across blocks or even days. A fee change that takes effect over a 24-hour ramp gives markets time to adjust without a discrete extraction event.

struct GradualParameterChange {
    uint256 startValue;
    uint256 endValue;
    uint256 startTime;
    uint256 endTime;
}

function getCurrentParameter() public view returns (uint256) {
    if (block.timestamp <= currentChange.startTime) return currentChange.startValue;
    if (block.timestamp >= currentChange.endTime) return currentChange.endValue;

    uint256 elapsed = block.timestamp - currentChange.startTime;
    uint256 duration = currentChange.endTime - currentChange.startTime;
    return currentChange.startValue + (currentChange.endValue - currentChange.startValue) * elapsed / duration;
}

Make Execution Time Predictable but Not Block-Precise

The execution time of a governance decision should be predictable enough for stakeholders to plan, but not block-precise enough for searchers to position around. A few-minute window of randomized execution within the announced execution slot reduces the precise MEV opportunity.

Use Commit-Reveal for Sensitive Votes

For votes on sensitive parameters (interest rate changes, oracle whitelist changes), the vote itself can be committed first and revealed later. This prevents searchers from positioning during the vote-counting phase.

Specific Protocol Patterns

The Tornado Cash Governance Compromise (May 2023)

A protocol that was widely thought to have well-designed governance was compromised through a subtle proposal-execution flaw. The attacker:

  1. Submitted a proposal with bytecode that, when executed, would grant the attacker admin rights to the governance contract
  2. The proposal's bytecode was visible during the voting window, but the malicious behavior was obfuscated (the bytecode appeared to be one thing, but executed differently)
  3. The community voted approval, not catching the obfuscation
  4. The proposal executed and granted the attacker admin
  5. The attacker drained the protocol's TornadoCash governance vault

The lesson: proposals that involve arbitrary code execution must be reviewed at the code level, not just at the description level. A proposal's English description is what voters read; the bytecode is what executes. If the two diverge, voters approve something they didn't understand.

Defenses:

  • Limit the scope of proposal execution (e.g., only allow proposals to call specific whitelisted contracts)
  • Require multiple independent reviewers to verify the bytecode-vs-description match
  • Use proposal "preview" tools that simulate the proposal's effect on testnet
  • Require longer review windows for proposals that touch the governance contract itself

MakerDAO's Approval Voting

MakerDAO uses an approval-style mechanism where holders continuously delegate (or revoke delegation from) MKR to specific "delegates." The current delegations determine voting outcomes on any given proposal.

This pattern is more responsive than per-proposal voting (delegates can act quickly) but concentrates power. Maker's delegate ecosystem has produced meaningful governance, but it has also produced periods where a small number of delegates controlled the outcome of major decisions.

Compound's Governor Bravo / Optimistic Variants

Compound's governance framework has been iterated over multiple versions:

  • Governor Alpha (2020): original; required holding tokens at proposal block
  • Governor Bravo (2021): refinements including signature-based voting
  • Optimistic Governance: proposals execute by default unless vetoed by a council

The "optimistic" variant has been adopted by several protocols (Optimism, etc.) — it reduces governance friction but introduces a council that can veto, which is its own trust assumption.

Practical Checklist

For a protocol designing token-based governance:

  • Voting uses checkpointed snapshots (e.g., ERC20Votes from OpenZeppelin)
  • Snapshot block is sufficiently distant from the voting window
  • Execution is timelocked between vote-pass and action (minimum 2 days, longer for high-value protocols)
  • Quorum threshold is set high enough that minor participation cannot pass proposals
  • Supermajority thresholds exist for the most consequential changes (treasury, upgrade, asset whitelist)
  • Proposal-execution scope is bounded (cannot call arbitrary code; can only call specific approved contracts)
  • Bytecode review is required for proposals touching the governance contract itself
  • Long-duration locks (veToken style) align voter incentives with protocol horizon
  • Most consequential parameters are hardcoded or capped at the contract level rather than being governance-changeable

For a protocol consuming governance decisions from another:

  • The other protocol's governance attack surface is part of your threat model
  • You can selectively un-integrate or pause based on the other protocol's governance outcomes
  • Your protocol does not assume the other protocol's governance will always act in good faith

For a protocol's voters and delegates:

  • The delegation interface is well-understood
  • Delegates' addresses are documented (so re-delegation is easy if a delegate's keys are compromised)
  • Voters understand that their vote may be effectively "rented" via vote-buying markets

A protocol that designs governance well from the start has a different security profile than one retrofitting defenses after a compromise. Beanstalk's $182M loss was preventable by adopting any one of several well-known patterns; the cost of doing so before launch is small.

Cross-References

  • MEV — Section 3.11.3 covers proposal-execution MEV and the broader ordering-based extraction patterns
  • Flash loans — Section 3.11.4 covers flash loans as the capital primitive that enables fast governance attacks
  • Defensive patterns — Section 3.7.5 covers timelock and pause mechanisms applicable to governance
  • Access control — Section 3.7.3 covers the role-based access patterns governance contracts depend on
  • Anti-patterns — Section 3.7.7 covers patterns that should not appear in governance contracts (e.g., admin-only-without-multisig)
  • OpenZeppelin Governor — https://docs.openzeppelin.com/contracts/governance covers the reference implementation
  • Compound Governor Bravo — historical reference for the most influential governance design
  • Tally / Snapshot — UIs for many DeFi governance systems