On April 17, 2022, Beanstalk Farms — an Ethereum-based decentralized credit protocol — lost approximately $182 million in a governance attack. The attacker used a flash loan to acquire a supermajority of Beanstalk's governance tokens, voted to approve a malicious proposal that transferred the protocol's reserves to themselves, and executed the entire operation in a single blockchain transaction.
The attack was technically legitimate. It followed the protocol's governance rules exactly as designed. That was the problem.
How Beanstalk Governance Worked
Beanstalk used a governance model common in DeFi: token holders could submit proposals and vote on changes to the protocol. The voting power was proportional to the number of governance tokens (Stalk) held. Proposals needed a supermajority (two-thirds of voting power) to pass, and once passed, they could be executed after a delay period.
The critical detail: Beanstalk's governance system determined voting power based on token holdings at the time of the vote, not at the time the proposal was submitted. And flash loans could temporarily inflate holdings.
The Attack
The attacker's operation was executed with surgical precision:
-
Submitted a malicious governance proposal (BIP-18) on April 16 that, if passed, would transfer Beanstalk's reserve funds to the attacker's address. The proposal was disguised as a donation to Ukraine — which added a layer of social engineering to the technical attack.
-
Waited for the voting period to nearly expire. The one-day delay between proposal submission and when it could be voted on was the window.
-
Took out massive flash loans from Aave, totaling approximately $1 billion in various tokens.
-
Deposited the borrowed tokens into Beanstalk, receiving Stalk governance tokens in return. This temporarily gave the attacker approximately 79% of all voting power.
-
Voted for the malicious proposal using their temporarily overwhelming governance power. With 79% of voting power, the two-thirds supermajority requirement was easily met.
-
The proposal passed and executed immediately — the governance system executed the approved transfer, sending approximately $182 million in protocol reserves to the attacker.
-
Repaid the flash loans and walked away with the profit. After repaying the ~$1 billion in flash loans and transaction fees, the attacker's net profit was approximately $80 million.
The entire sequence — from flash loan to governance vote to fund transfer to loan repayment — occurred in a single Ethereum transaction.
The Philosophical Problem
The Beanstalk attack raises a fundamental question about decentralized governance: if the rules were followed, was it really an attack?
The protocol's governance rules stated that proposals passing with a supermajority could execute changes, including fund transfers. The attacker acquired the tokens, had the voting power, cast the vote, and the proposal passed. Every step was within the rules as coded.
The problem was that the governance rules did not account for temporary token holdings acquired through flash loans. The system treated borrowed tokens the same as tokens held by long-term stakeholders. This meant that governance decisions could be made by someone with zero long-term stake in the protocol — someone who held the tokens for mere seconds.
This is a design flaw, not a code bug. The smart contracts executed exactly as written. The economic model underlying the governance system was simply wrong.
The Flash Loan Problem (Again)
Beanstalk joins a growing list of DeFi protocols attacked through flash loans:
- bZx (February 2020) — multiple flash loan attacks exploiting price oracle manipulation
- Harvest Finance (October 2020) — $34 million drained through flash loan-enabled price manipulation
- Cream Finance (October 2021) — $130 million stolen through flash loan attacks
- Beanstalk (April 2022) — $182 million through flash loan governance attack
Flash loans are a uniquely DeFi phenomenon. In traditional finance, acquiring the capital to influence a governance vote requires real money held over a meaningful period. In DeFi, anyone can borrow a billion dollars for the duration of a single transaction.
This creates attack surfaces that have no traditional finance analog:
- Governance attacks — temporarily acquiring voting power
- Price oracle manipulation — temporarily distorting prices that other protocols depend on
- Liquidity pool exploitation — temporarily imbalancing pools to extract value
Defense Mechanisms
Several mechanisms can protect against governance attacks:
Time-weighted voting power. Instead of basing voting power on current token holdings, use a time-weighted average that requires tokens to be held for a meaningful period before they confer voting power. This makes flash loan governance attacks impossible.
Snapshot-based voting. Take a snapshot of token holdings at the time a proposal is submitted, not at the time of the vote. This prevents acquiring tokens after a proposal is known.
Governance delays. Implement a meaningful delay between when a vote passes and when it can be executed, allowing the community to detect and respond to malicious proposals.
Flash loan detection. Smart contracts can detect when a governance vote is occurring within the same transaction as a large deposit, and reject such votes.
Multi-stage governance. Require proposals to pass multiple rounds of voting over extended periods, making flash loan attacks impractical.
How Safeguard.sh Helps
Safeguard.sh provides the continuous monitoring and vulnerability analysis that helps organizations identify design-level security flaws — not just code bugs — before they are exploited. Our platform tracks the security posture of your software dependencies and infrastructure, including smart contracts and governance mechanisms, flagging known vulnerability patterns and enforcing security reviews through policy gates. For organizations building or integrating with DeFi protocols, Safeguard.sh helps ensure that governance models are reviewed for economic attack vectors, not just technical ones.