A governance attack uses flash-borrowed or temporarily accumulated governance tokens to pass a malicious proposal that drains the protocol treasury or changes parameters in the attacker favor. The most famous example: the Beanstalk attack (April 2022) where an attacker flash-borrowed enough BEAN/governance power to pass a proposal stealing $182M from the treasury, all in one transaction.
What Is a Governance Attack?
4 min read
The short version
Most DAOs let token holders vote on how to spend the treasury. A governance attack exploits this: borrow a mountain of governance tokens for one block, vote yes on a proposal that sends the treasury to your wallet, execute the proposal, return the borrowed tokens, and walk away with the money. One transaction. No hacking required. Just using the governance system exactly as designed but faster than anyone expected.
How It Works
How it works: (1) The attacker creates a malicious proposal (often disguised or submitted at the last moment): send treasury funds to attacker address, change admin to attacker, or modify parameters to enable extraction. (2) The attacker accumulates voting power: via flash loan (borrow tokens, vote, return in same transaction), market purchase (buy enough tokens to reach quorum), or a combination. (3) The attacker votes the proposal through: if quorum and approval threshold are met, the proposal passes. (4) After timelock (if any), the proposal executes its malicious payload. Why it works: many DAOs have low quorum requirements (3-10% of supply), inexpensive token supplies (smaller DAOs), snapshot-based voting that does not check if tokens were borrowed, and proposals that can be submitted and voted on rapidly. The Beanstalk attack (April 17, 2022): the attacker flash-loaned $1B in various assets, swapped into enough BEAN governance tokens to pass a proposal (BIP-18) transferring all Beanstalk assets to their wallet. Stolen: $182M. The entire attack (borrow, vote, execute, extract, repay) happened in one Ethereum transaction. Defenses: timelocks (delay between vote passing and execution), vote escrow (tokens must be locked for weeks before gaining voting power), snapshot at proposal creation time (not voting time), high quorum requirements, and guardian/veto mechanisms.
The Beanstalk governance attack ($182M, April 2022)
Block 14602790 (April 17, 2022). One transaction. Step 1: attacker flash-borrows ~$1B in DAI, USDC, and USDT from Aave. Step 2: swaps into BEAN and 3CRV, depositing into the BEAN:3CRV Curve pool to acquire Stalk (Beanstalk governance power). Step 3: with 67% of total Stalk (exceeding the supermajority threshold), votes to pass BIP-18 (a malicious Beanstalk Improvement Proposal). Step 4: BIP-18 executes: transfers all Beanstalk protocol assets to the attacker address. Step 5: attacker repays all flash loans. Net profit: $182M (total protocol value minus flash loan fees). Time elapsed: one Ethereum block (12 seconds). The attack was possible because: Beanstalk had no timelock on governance execution, voting power was acquirable via flash loans, and there was no delay between proposal creation and voting. Post-attack: Beanstalk added governance timelocks and the community relaunched the protocol (Beanstalk Farms).
What People Get Wrong
Governance attacks require hacking smart contracts
No code is exploited. The attacker uses the governance system exactly as designed. They just acquire voting power temporarily (via flash loans) in a way the designers did not anticipate. The governance worked correctly. The rules were just insufficient to prevent this abuse.
Only tiny DAOs are vulnerable
Any DAO where: governance tokens can be flash-borrowed, quorum is achievable with available liquidity, and execution has no meaningful timelock is vulnerable regardless of size. Beanstalk had $182M TVL. The defense is structural (timelocks, vote escrow) not size.
Timelocks completely prevent governance attacks
Timelocks prevent instant execution (the Beanstalk one-transaction attack). But they do not prevent a wealthy attacker from buying tokens, passing a malicious proposal, waiting through the timelock, and executing. They give the community time to react (cancel, counter-vote, exit) but do not make attacks impossible, just harder and detectable.
Keep Reading
Sources & Further Reading
- Rekt.news Beanstalk Post-Mortem
Detailed analysis of the Beanstalk governance attack
- OpenZeppelin Governor
Standard governance implementation with timelock and quorum protections
Questions People Also Ask
- How do protocols prevent governance attacks now?
- Best practices post-Beanstalk: (1) Timelock on all governance execution (24-72 hours minimum). (2) Vote escrow: tokens must be locked for days/weeks before gaining voting power (cannot flash-loan). (3) Snapshot at proposal creation: voting power calculated when the proposal was submitted, not when votes are cast. (4) Guardian veto: a security council can cancel malicious proposals during the timelock. (5) High quorum: requiring 5-10% of total supply to participate.
- Is the Beanstalk attacker in jail?
- The attacker was not immediately identified (used Tornado Cash to obscure fund flows). The exploit was conducted entirely through publicly available DeFi protocols without violating any computer access laws in the traditional sense. As of 2024, no arrest has been publicly announced. The legal status of governance attacks remains ambiguous.
- Can voting power from staking be flash-loaned?
- If the governance system uses token balances at the time of voting (not time-locked balances), yes. If it uses vote escrow (veTokens that require locking for months/years), no. This is why veToken models (Curve veCRV, Frax veFXS) are more resistant: you cannot flash-loan a position that requires a 4-year lock to get maximum voting power.