Beanstalk Farms Governance Attack
April 2022 — flash-loan-funded governance takeover passes malicious BIP-18; $182M drained in a single transaction.
Beanstalk Farms was an algorithmic-stablecoin protocol that used a governance-token-voted system to manage its parameters. On April 17, 2022, an attacker used a flash loan to acquire enough governance tokens to pass a previously-submitted malicious proposal (BIP-18) that transferred all of the protocol's treasury — approximately $182M in various stablecoins — to an attacker-controlled address.
The attack was structurally novel at the time: it was the first major flash-loan-funded governance takeover, demonstrating that any governance system relying on token-weighted voting with same-block voting power was vulnerable to flash-loan amplification. The Beanstalk proposal had been submitted 24 hours earlier (the protocol's minimum delay) without raising community attention; when the attacker acquired the votes via flash loan and passed the proposal, the entire treasury was drained before any human intervention was possible.
Beanstalk subsequently relaunched with substantially-revised governance mechanisms including extended timelocks, prior-block voting snapshots (preventing flash-loan-amplified voting), and additional treasury safeguards. The case became a canonical reference for flash-loan governance attacks and substantially influenced subsequent DAO-governance design across the industry.
Timeline
- 2021-08Beanstalk Farms launches as decentralised stablecoin protocol; BEAN as algorithmic stablecoin.
- 2022-04-16Attacker submits two BIPs (BIP-18 and BIP-19): one for ostensible Ukraine humanitarian donation; one transferring protocol treasury to an attacker address.
- 2022-04-17 (~12:00 UTC)After the 24-hour minimum delay, the proposal becomes eligible for voting.
- 2022-04-17 (~12:24 UTC)Attacker initiates flash loan from Aave: $350M of WETH + DAI used to acquire ~67% of Beanstalk's governance token (Stalk) within a single transaction.
- 2022-04-17 (~12:24 UTC)Attacker uses acquired Stalk voting power to pass BIP-18 (transferring protocol treasury).
- 2022-04-17 (~12:24 UTC)Approximately $182M in stablecoins transferred from Beanstalk treasury to attacker-controlled address; flash loan repaid in the same transaction; net theft $182M.
- 2022-04-17 (afternoon)Beanstalk team and community publicly acknowledge the attack; protocol operations paused.
- 2022-04-19Beanstalk announces relaunch plan with revised governance mechanisms.
- 2022-08Beanstalk relaunches with new governance design including prior-block voting snapshots and extended timelocks.
Mechanism
Beanstalk's governance design. Beanstalk used a token called Stalk for governance voting. Each proposal required a majority of Stalk supply to pass. The governance system computed voting power at the moment of vote casting — same-block voting power was operative.
The 24-hour minimum delay. Beanstalk required proposals to have been submitted at least 24 hours before voting was enabled, ostensibly to give the community time to review proposals. In practice, the delay was inadequate: the proposal sat for 24 hours without community attention, then was voted on in a single transaction the moment voting became eligible.
The flash-loan acquisition of voting power. The attacker took a $350M flash loan from Aave consisting of WETH and DAI. Within the same transaction, the attacker: (a) swapped the WETH and DAI into the various assets needed to mint Beanstalk's BEAN stablecoin; (b) deposited the BEAN into the Beanstalk silo to accumulate Stalk voting power; (c) accumulated approximately 67% of total Stalk supply.
The proposal passage. With 67% of Stalk now controlled by the attacker's transaction, the previously-submitted BIP-18 (which the attacker had submitted 24 hours earlier) passed immediately. The proposal authorised transfer of approximately $182M of various stablecoins from the Beanstalk treasury to a specific attacker-controlled address.
The exit and flash-loan repayment. With the $182M transferred to the attacker address, the attacker withdrew the BEAN deposit (recovering the assets used to acquire Stalk), swapped back to WETH and DAI, and repaid the flash loan from Aave. The flash loan was repaid in full; the net effect of the attack was $182M of Beanstalk treasury assets transferred to the attacker minus minimal transaction costs.
The same-block voting power problem. The structural failure was that Beanstalk's governance computed voting power at the moment of vote casting. Because flash loans can move arbitrary capital within a single block, any same-block voting-power system can be drained by flash-loan attackers. The fix is to use prior-block snapshots: voting power as of the block when the proposal was first submitted, not when votes are cast. Such snapshots make flash-loan acquisition irrelevant because the attacker would need to have held the governance tokens before the proposal existed.
Impact
The Beanstalk attack was the first major flash-loan governance takeover and substantially shaped subsequent DAO governance design. Post-Beanstalk: (a) most major DeFi DAOs adopted prior-block voting snapshots; (b) extended timelocks (often 48-72 hours) became standard; (c) anti-flash-loan guards (rejecting votes from addresses whose voting power increased substantially in the past N blocks) became common; (d) treasury-protection mechanisms requiring additional approval layers for large outflows became standard. The Beanstalk case is referenced in essentially every modern DAO-design discussion. It also became a teaching example of the broader interaction between lifecycle properties (flash-loan economics) and contract logic (governance) — a pattern lesson that extends beyond Beanstalk's specific bug.
Operational lessons
- 1Same-block voting power is structurally broken in flash-loan environments. Any governance system that computes voting power at vote-casting time is vulnerable to flash-loan amplification. The fix is prior-block snapshots — voting power as of the proposal-submission block.
- 2Proposal-delay periods must extend beyond the human-review timeframe. Beanstalk's 24-hour delay was inadequate because no community member reviewed the proposal during the window. Modern DAO governance often uses 48-72 hour delays plus mandatory discussion periods to ensure substantive community engagement.
- 3Treasury concentration is a structural risk. Beanstalk's entire treasury was drainable through a single proposal. Modern DAO design often distributes treasury across multiple multisig vaults, requires separate multisig approval for outflows above thresholds, and uses staged-release mechanisms.
- 4Flash loans amplify the cost-benefit math of governance attacks. Without flash loans, governance attacks require substantial pre-existing capital; the cost of capital usually makes attacks unprofitable. With flash loans, the capital cost is the gas of one transaction. Any DAO economic-security model must account for flash-loan amplification.
- 5Public proposals can hide in plain sight. BIP-18 was submitted publicly 24 hours before the attack. The community had access to the proposal text but did not review it. Public-attack-surface monitoring tools (e.g., DAO-proposal alerting bots) have become standard post-Beanstalk to surface high-risk proposals.
Aftermath
Beanstalk Farms relaunched in August 2022 with substantially-revised governance mechanisms: prior-block voting snapshots, longer timelocks, anti-flash-loan guards, and distributed treasury structure. The relaunched protocol has operated without major governance incidents since. The original attacker has not been publicly identified; some of the stolen funds were traced through Tornado Cash, which subsequently became OFAC-sanctioned (August 2022) partly in response to the volume of stolen funds being laundered through it. The Beanstalk case is foundational teaching material in DAO-governance design curricula and is referenced in essentially every modern discussion of flash-loan defence patterns. The relaunch's successful operation without subsequent governance incidents demonstrates that the structural fixes (prior-block snapshots + extended timelocks) are effective when implemented; the bug class is well-understood and defendable against.
Sources & further reading
- Primary
- Secondary
- Secondary
- Primary
We prioritise primary sources. Where a topic moves quickly (regulation, security incidents), we re-check sources on the cadence shown by the page's "Next review" date.