Beanstalk Farms — flash-loan governance exploit

What happened

On 17 April 2022 an attacker drained approximately $182 million from the Beanstalk Farms treasury in a single Ethereum transaction that took approximately thirteen seconds to execute. The theft exploited Beanstalk’s on-chain governance system using borrowed capital — a “governance flash-loan attack” — that gave the attacker temporary voting control over the protocol long enough to pass and immediately execute a malicious proposal transferring the treasury to their own wallet.

The attacker netted approximately $80 million in profit after repaying the flash loans, fees, and protocol costs. The remainder of the $182 million was consumed by loan repayment and operational overhead within the same transaction. The Beanstalk protocol — an algorithmic stablecoin system — effectively ceased operating. It relaunched four months later with a rebuilt governance architecture that included mandatory voting delays and removed the instant-execution pathway. The attacker was never publicly identified.

How it worked

Beanstalk’s governance model allowed any holder of Stalk tokens — earned by depositing BEAN-3CRV liquidity pool tokens in the Beanstalk Silo — to propose and vote on governance changes. Crucially, the system had no time-lock between a proposal passing and its execution. A proposal that received a supermajority of votes could be executed immediately in the same transaction in which the votes were cast. This design prioritised responsiveness over security.

Flash loans are a DeFi primitive that allows anyone to borrow an arbitrary amount of assets from a lending protocol, provided the loan is repaid within the same Ethereum transaction. Because Ethereum transactions are atomic — they either fully complete or fully fail — there is no credit risk to the lender. Flash loans are legitimate tools for arbitrage and collateral swaps, but their combination with governance voting rights is catastrophic if a protocol does not account for it.

The attacker assembled the exploit using three simultaneous flash loans: $350 million in DAI from Aave, $500 million in USDC from Aave, and $150 million in USDT from Aave — approximately $1 billion in total borrowed capital. Within the same transaction, they deposited the bulk of these funds into Curve’s 3CRV pool to receive BEAN-3CRV LP tokens, then deposited those LP tokens into the Beanstalk Silo. This gave the attacker approximately 79% of the total governance voting weight in the protocol for the duration of that single block.

With a supermajority secured, the attacker submitted and simultaneously voted in favour of a malicious governance proposal — “BIP-18” — that instructed Beanstalk to transfer its entire treasury, including roughly $77M in BEAN-3CRV tokens and $36M in other assets, to the attacker’s wallet. Because no time-lock existed, the vote result was immediately executed in the same transaction. The treasury was empty. The attacker then repaid all three flash loans and pocketed the net proceeds.

The governance contract’s flaw was not a code bug in the conventional sense: the logic executed exactly as written. The design assumption was that governance participants were long-term stakeholders with genuine skin in the game. Flash loans invalidated that assumption entirely by allowing the creation of a temporary majority position with no capital at risk beyond transaction fees.

Timeline

• 6 April 2022 — A malicious governance proposal (BIP-18) is submitted to Beanstalk, seeding it in the system in advance. Because Beanstalk required proposals to be open for voting for a minimum period, the attacker submitted the proposal eleven days early.
• 17 April 2022, ~12:24 UTC — The attacker begins the exploit transaction. Approximately $1B in flash loans borrowed from Aave.
• 17 April 2022, ~12:24 UTC (same block) — BEAN-3CRV LP tokens acquired, deposited into Silo, voting weight reaches 79% supermajority. BIP-18 voted through and immediately executed. Treasury drained. Flash loans repaid. All in one transaction.
• 17 April 2022, ~12:37 UTC — Beanstalk team confirms the exploit publicly. Protocol is paused.
• April 2022 — Beanstalk publishes post-mortem. Begins fundraising for protocol restart.
• August 2022 — Beanstalk relaunches with a new governance architecture incorporating time-locks, snapshot-based voting eligibility (preventing flash-loan exploitation), and multi-sig emergency controls.

What defenders should learn

The Beanstalk attack defined the governance flash-loan attack class and forced DeFi to address a fundamental design gap. The central lesson is that voting weight derived from instantaneously acquired positions must never translate into instantaneous execution power. Any governance system in which the same transaction that acquires voting power can also execute the vote outcome is vulnerable to this attack, regardless of what the required supermajority threshold is. A $1 billion flash loan can manufacture any majority.

Time-locks are the primary mitigation. Requiring a mandatory delay — typically 24 to 72 hours — between a vote passing and its execution means that flash-loaned voting power is useless, because the loan must be repaid within the same transaction and cannot be held open for 24 hours. Most DeFi governance systems that post-date Beanstalk incorporate this requirement directly; Compound, Aave, and others already had it. Protocols that had not yet implemented time-locks audited their governance designs in the weeks following the attack.

Snapshot eligibility — recording voting weight at a block prior to the proposal rather than at the voting block — is the complementary control. If a user’s voting weight is measured at a snapshot taken before the governance action began, flash-loaned capital acquired in the execution transaction cannot contribute to the vote total. Combining a pre-vote snapshot with a time-locked execution window removes both the instant acquisition and instant execution pathways simultaneously.

The Beanstalk case also illustrates the risk of governance designs that optimise for speed. Beanstalk’s immediate-execution model was a feature, not an oversight — it was intended to let the protocol respond quickly to market conditions. The design achieved operational flexibility at the cost of security against the specific attack class that eventually destroyed it. Speed and security are in direct tension in on-chain governance, and protocols should resolve that tension in favour of security for any action that can affect treasury balances or core protocol parameters.