Governance Attack

What Is a Governance Attack?

A governance attack is an exploit that targets the legitimate voting process of a decentralized autonomous organization (DAO) rather than its smart contract code. Instead of finding a bug, the attacker uses the governance system exactly as designed: they acquire enough voting power to pass proposals that benefit themselves at the expense of all other participants.

This is what makes governance attacks particularly insidious. From the protocol's perspective, a malicious actor buying governance tokens looks identical to a legitimate large investor. Both acquire tokens through normal market activity, and both submit proposals through the standard governance process. The system cannot distinguish between a genuine community member proposing a treasury allocation and an attacker proposing to drain funds.

Governance attacks have resulted in hundreds of millions of dollars in losses across DeFi protocols, with incidents ranging from the $181 million Beanstalk exploit in 2022 to the $20 million BonkDAO attack in 2026.

How It Works

Most governance attacks follow a common pattern, regardless of the specific variant:

1. Acquire voting power: the attacker obtains governance tokens through purchase, flash loans, borrowing, or delegation manipulation
2. Submit a malicious proposal: typically disguised as routine governance or framed alongside a legitimate-looking initiative
3. Vote the proposal through: using the acquired voting power to meet quorum and approval thresholds
4. Execute and extract value: the proposal transfers treasury funds, mints new tokens, or changes critical protocol parameters to benefit the attacker

The simplest version of a governance proposal that drains a treasury might look like this:

// Malicious proposal: transfer entire treasury to attacker
function execute() external {
    // Step 1: Transfer all stablecoins
    IERC20(USDC).transfer(
        attackerAddress,
        IERC20(USDC).balanceOf(address(treasury))
    );

    // Step 2: Transfer all governance tokens
    IERC20(GOV_TOKEN).transfer(
        attackerAddress,
        IERC20(GOV_TOKEN).balanceOf(address(treasury))
    );
}

In protocols without proper safeguards, this proposal can be submitted, voted on, and executed in minutes or even within a single transaction.

Attack Variants

Flash Loan Voting

The most capital-efficient attack vector uses flash loans to borrow massive quantities of governance tokens, vote on a malicious proposal, execute it, and repay the loan: all within a single transaction in a single block. The attacker's cost is limited to the flash loan fee (near zero) and gas costs.

This variant works only against protocols that allow same-block voting and execution, where voting power is calculated at the time of the vote rather than from a historical snapshot.

Gradual Accumulation

Rather than borrowing tokens temporarily, the attacker slowly purchases governance tokens across multiple pseudonymous wallets to avoid detection. When enough voting power is assembled, the attacker coordinates a vote during a period of low community participation. This approach requires real capital but is harder to defend against because each individual purchase appears legitimate.

Vote Buying and Bribes

Bribery platforms allow attackers to rent governance votes from token holders without purchasing the underlying tokens. Holders stake their governance tokens and sell their voting rights to the highest bidder. This is already operational in DeFi, particularly around Curve gauge voting (the so-called "Curve Wars"). While some bribery is used for legitimate competitive governance, the same infrastructure can be weaponized for attacks.

Social Engineering

Some attacks exploit voter trust rather than raw voting power. The attacker submits a proposal disguised as routine maintenance or a replication of a previously approved proposal. Voters approve it without reviewing the underlying code, not realizing it contains hidden malicious logic. This variant relies on voter apathy and trust rather than token accumulation.

Real-World Examples

Beanstalk: $181 Million (April 2022)

The most infamous governance attack exploited Beanstalk's emergencyCommit function, which allowed immediate execution of any proposal that achieved two-thirds support. The attacker:

1. Submitted two proposals: BIP-18 (transfer all funds to attacker) and BIP-19 (a $250K donation to Ukraine, likely for social cover)
2. Borrowed over $1 billion via flash loans from Aave, Uniswap V2, and SushiSwap
3. Used the borrowed funds to acquire a supermajority of governance voting power
4. Voted, executed the proposal, and repaid all loans in a single transaction

The attacker profited approximately $76 million (24,930 ETH). The root cause was straightforward: Beanstalk had no time-lock on voting power, no snapshot mechanism, and allowed same-block proposal execution.

Build Finance DAO: $470K (February 2022)

Unlike Beanstalk, this was a gradual accumulation attack. The attacker acquired BUILD tokens over time across multiple wallets, then submitted a proposal granting control of the BUILD token contract. To avoid counter-votes, the attacker kept the proposal quiet and did not announce it on Discord. After the proposal passed, the attacker minted over 1.1 million new BUILD tokens, drained liquidity pools, and seized 130,000 METRIC tokens from the treasury. BUILD's price collapsed from roughly $1.50 to near zero.

Tornado Cash: $2.1 Million (May 2023)

This attack used social engineering rather than brute-force token accumulation. The attacker submitted a proposal claiming to replicate a previously approved, legitimate proposal. Voters trusted it and approved it. However, the proposal contained hidden logic: a selfdestruct function that allowed the attacker to deploy entirely new code to the same contract address. Once executed, the new code assigned 10,000 governance tokens to each attacker-controlled address, totaling 1.2 million votes compared to only roughly 70,000 legitimate votes. The attacker gained total governance control and extracted 483,000 TORN tokens.

Compound: $24 Million Attempted (July 2024)

A DeFi whale known as "Humpy" withdrew 230,333 COMP from exchanges using five wallets, delegated voting power, and narrowly passed Proposal 289: a $24 million allocation to a yield strategy the whale controlled. The vote passed 682,191 to 633,636. Unlike other attacks, this was resolved through negotiation: Humpy agreed to rescind the proposal in exchange for development of a legitimate COMP staking product.

BonkDAO: $20 Million (July 2026)

The most recent high-profile governance attack demonstrated that no technical sophistication is required. The attacker spent roughly $4 million buying BONK tokens across multiple anonymous wallets over several days. Only seven wallet addresses voted on the proposal, with the attacker's wallets controlling 99.878% of total voting weight. The attack succeeded because of extremely low governance participation.

Defenses and Mitigations

Time-Locked Voting

Requiring tokens to be held for a minimum duration before conferring voting power eliminates flash loan attacks entirely. Combined with execution timelocks (a delay between proposal passage and execution), this gives the community time to identify and respond to malicious proposals.

Vote Escrow

Pioneered by Curve's veCRV model, vote escrow requires users to lock tokens for a chosen duration (up to four years for Curve). Voting power scales with lock duration: longer lockups grant more votes. This aligns governance power with long-term commitment and makes short-term manipulation prohibitively expensive.

Snapshot-Based Voting Weight

Voting power is calculated from a historical snapshot taken at a specific block height before the proposal was submitted. Tokens acquired after the snapshot block carry zero voting weight. This prevents flash loan attacks because the attacker would need to hold tokens before the snapshot is taken.

Quorum Requirements

Minimum participation thresholds invalidate low-turnout votes. BonkDAO's 7-wallet vote would have failed with meaningful quorum requirements. However, quorum must be calibrated carefully: set too high and legitimate governance stalls, set too low and attacks become trivial.

Delegation

Allowing inactive token holders to delegate voting rights to trusted, active representatives increases effective participation without requiring every holder to actively vote. Higher participation makes accumulation attacks more expensive. Protocols like Compound, ENS, and Aave all implement delegation systems.

Conviction Voting

Rather than discrete voting windows, token holders continuously signal their preferences. The longer a holder supports a proposal, the more "conviction" accumulates. Proposals must reach a minimum conviction threshold to pass. This rewards sustained commitment and makes last-minute vote manipulation extremely costly.

The Fundamental Tension

Token-weighted voting (one token, one vote) is the dominant governance model in DAOs because it is Sybil-resistant on permissionless blockchains: since on-chain identities cannot be verified, tying votes to economic stake makes manipulation expensive. However, this creates inherent plutocracy where those with more capital hold more governance power.

This leads to several structural problems. Early adopters who acquired tokens at low prices hold disproportionate influence. Wealthy participants can buy governance outcomes. Small holders face rational apathy because their votes are economically insignificant, which lowers participation and makes attacks cheaper. And as large holders shape governance to benefit themselves, token concentration increases in a reinforcing cycle.

Academic research has shown that no voting rule deriving power solely from wallet balances can be simultaneously anti-plutocratic, Sybil-resistant, and permissionless. Alternatives like quadratic voting reduce plutocracy but introduce Sybil vulnerability (one person creating many wallets). This tension is fundamental and has no known complete solution.

Why It Matters

Governance attacks highlight a core tradeoff in decentralized protocol design: the more power you give to token holders, the more vulnerable the system becomes to actors who accumulate tokens purely to extract value. Protocols that manage significant treasuries or control critical infrastructure must treat governance security as seriously as smart contract security.

For Bitcoin-native protocols, this risk is handled differently. Bitcoin's governance operates through social consensus and miner signaling rather than token-weighted voting, making it resistant to these specific attack vectors. Layer 2 protocols like Spark inherit this property: Spark does not rely on a governance token for protocol decisions, instead using cryptographic mechanisms like FROST threshold signatures for operational security.

Understanding governance attacks is essential for anyone participating in DAO governance, evaluating DeFi protocol risk, or designing new decentralized systems. The history of these attacks demonstrates that technical defenses must be paired with thoughtful governance design to protect community-managed treasuries. For a deeper look at how protocol risk propagates through decentralized systems, see the research article on DeFi protocol risk.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.