Cowrie Research

beanstalk-governance-takeover-2022-04-17

13 min read

Beanstalk Governance Takeover (2022-04-17)

  • Name: Beanstalk governance takeover
  • Date: 2022-04-17
  • Protocol: Beanstalk
  • Chain: Ethereum
  • Category: governance capture / flash-loan voting takeover / malicious proposal execution / treasury drain
  • Loss: commonly reported as about 182M gross protocol loss, with roughly 77M of non-Bean assets realized by the attacker after repaying flash loans
  • Summary: The attacker used Beanstalk’s Silo governance model and emergencyCommit() path to turn borrowed liquidity into temporary constitutional control. After seeding enough Stalk one day earlier to submit malicious proposals, the attacker flash-loaned more than $1 billion of stablecoins, converted that capital into whitelisted LP positions that minted massive voting power, crossed the two-thirds emergency threshold, and executed BIP-18 in the same attack sequence. The passed proposal delegatecalled attacker-controlled logic that transferred protocol assets out of Beanstalk, after which the attacker unwound liquidity, repaid the loans, and kept the remaining profit.
  • Trigger / entry point:
    • Beanstalk governance let deposited whitelisted assets in the Silo mint Stalk, which carried voting power immediately.
    • The protocol had an emergencyCommit() path that allowed execution after roughly one day if a proposal had more than two-thirds of outstanding Stalk voting for it.
    • Proposal execution in Beanstalk’s diamond architecture could include an _init / delegatecall-style logic handoff, giving a passed proposal very broad authority over protocol state and assets.
  • Root cause:
    • Beanstalk treated instantaneous deposit-based voting weight as legitimate governance power even though that power could be rented for one transaction through flash loans.
    • The emergency path collapsed acquire votes, cross threshold, and execute proposal closely enough that temporary voting power could become permanent asset extraction.
    • Proposal execution authority was too broad: once the attacker won governance, the protocol effectively handed them a root-level code-execution path.
    • In practice, Beanstalk put treasury and upgrade authority behind a voting system that had no meaningful distinction between durable political alignment and momentary rented balance-sheet mass.
  • Exploit path:
    1. On 2022-04-16 the attacker-funded address acquired about 212,858 BEAN and deposited it into the Silo, enough to qualify to propose governance actions.
    2. The attacker submitted BIP-18 (0x68cdec0ac76454c3b0f7af0b8a3895db00adf6daaf3b50a99716858c4fa54c6f) and BIP-19 (0x9575e478d7c542558ecca52b27072fa1f1ec70679106bdbd62f3bb4d6c87a80d) about one day before the main exploit.
    3. Public postmortems describe BIP-18 as the real malicious execution path and BIP-19 as a visible Ukraine-donation decoy, with the malicious _init target for BIP-18 precomputed and later deployed via CREATE2.
    4. Once the emergency waiting period had elapsed, the attacker launched the main exploit transaction 0xcd314668aaa9bbfebaf1a0bd2b6553d01dd58899c508d4729fa7311dc5d33ad7.
    5. In that attack flow, the attacker flash-loaned roughly $1 billion of DAI, USDC, and USDT from Aave, plus tens of millions of BEAN and LUSD from other venues.
    6. The borrowed assets were routed through Curve to mint large amounts of the whitelisted LP assets BEAN3CRV-f and BEANLUSD-f, which were then deposited into the Silo.
    7. Those deposits minted enough Stalk for the attacker to control more than the two-thirds emergency threshold, commonly described as roughly 70% to 79% of outstanding voting power.
    8. With temporary supermajority control established, the attacker invoked emergencyCommit() on BIP-18.
    9. Execution jumped into malicious proposal logic at 0xE5eCF73603D98A0128F05ed30506ac7A663dBb69, which public analyses describe as being deployed at execution time through CREATE2 and used to transfer Silo assets toward the attacker-controlled path.
    10. The attacker then removed liquidity, repaid the flash loans, converted the residual proceeds, and retained roughly 24,830 WETH as profit while also sending $250K to the Ukraine donation address referenced in public reporting.
  • What the attacker needed to be true:
    • Whitelisted LP assets had to mint voting power immediately on deposit.
    • Those LP assets had to be cheaply manufacturable with borrowed capital at sufficient scale.
    • The emergency governance path had to permit execution before the borrowed voting weight disappeared.
    • Proposal payloads had to be powerful enough to run attacker-controlled logic rather than only narrow parameter changes.
    • Enough onchain liquidity had to exist to rent a supermajority for one transaction.
  • Technical anatomy worth remembering:
    • This was not just flash loans are dangerous; it was a governance-design failure where temporary liquidity could become final authority.
    • The critical mistake was not merely low quorum. It was coupling a two-thirds emergency threshold to immediately depositable voting weight and root-level execution privileges.
    • The diamond _init / delegatecall style mattered. Once governance was captured, the proposal executor did not need a second bug to steal assets.
    • The attacker prepared the social and technical staging one day in advance, then collapsed the actual vote capture and malicious execution into the exploit window.

Three constitutional-authority promotions this incident collapsed

  1. Some capital could still become formal Beanstalk voting weight quickly enough to matter

    • Flash-loaned stablecoins and other borrowed inventory could still be transformed into whitelisted LP positions such as BEAN3CRV-f and BEANLUSD-f.
    • Depositing those LP positions into the Silo immediately minted Stalk, so the protocol already allowed one-transaction balance-sheet mass to cross from rentable liquidity into formal vote math.

  2. That one-transaction vote math still counted as canonical emergency constitutional truth

    • Beanstalk did not require durable holding time, longer-lived alignment, or a stronger emergency electorate than ordinary deposit-derived weight.
    • Once the attacker crossed the two-thirds threshold, emergencyCommit() treated that borrowed LP-manufactured Stalk as a legitimate emergency supermajority for BIP-18 rather than as transient, cheaply assembled voting mass.

  3. That accepted emergency supermajority still deserved immediate protocol-root execution authority

    • After the vote was accepted, the system still let the proposal reach diamond _init / delegatecall-style execution with no materially separate treasury, upgrade, or payload-scope backstop.
    • The final damaging promotion was not merely hostile coalition won the vote; it was hostile coalition won the vote and therefore inherited same-path root authority over protocol assets.
  • Representative transactions and addresses:
    • Attacker EOA / exploit address: 0x1c5dcdd006ea78a7e4783f9e6021c32935a10fb4
    • Victim Beanstalk contract: 0xc1e088fc1323b20bcbee9bd1b9fc9546db5624c5
    • Proposal transaction for BIP-18: 0x68cdec0ac76454c3b0f7af0b8a3895db00adf6daaf3b50a99716858c4fa54c6f
    • Proposal transaction for BIP-19: 0x9575e478d7c542558ecca52b27072fa1f1ec70679106bdbd62f3bb4d6c87a80d
    • Main exploit / emergency execution transaction: 0xcd314668aaa9bbfebaf1a0bd2b6553d01dd58899c508d4729fa7311dc5d33ad7
    • Malicious proposal / init contract highlighted in public analysis: 0xE5eCF73603D98A0128F05ed30506ac7A663dBb69
  • Response / mitigation:
    • Beanstalk publicly disclosed the exploit, paused the protocol, and shut off governance while pursuing a recovery and relaunch path.
    • Later analyses emphasized the need for execution delay, governance redesign, and removal or restriction of the flash-loan-friendly emergency path.
    • The case became a canonical warning that onchain governance with arbitrary execution is itself a privileged attack surface, not just an administrative feature.

Pattern tags

  • governance-capture
  • borrowable-governance-weight
  • The decisive capital was not borrowed governance tokens directly; flash-loaned stablecoins were converted into whitelisted LP positions that minted Stalk immediately, so Beanstalk authenticated manufactured deposit weight as constitutional authority.
  • emergencyCommit() collapsed assemble votes, cross the decisive threshold, and reach execution into one short attacker window, which made the protocol’s emergency branch function as a timelock bypass for rented capital.
  • BIP-18’s execution path turned governance victory into root-level effect execution through malicious _init logic, so the harmful step was not merely hostile vote passed but hostile vote passed on a governor whose payload authority already reached protocol assets.
  • The protocol had no meaningful live distinction between the electorate that could pass routine governance and the authority that could drain treasury assets, which made flash-accessible vote mass and protocol-root control effectively the same control surface.

Why the exploit worked

  • Beanstalk let whitelisted Silo deposits mint Stalk immediately, and the exploitable vote-bearing assets were not scarce governance tokens but LP positions that could be manufactured on demand from borrowed stablecoins. That meant the attacker did not need to corner BEAN governance float; they only needed enough temporary balance-sheet mass to create vote-bearing deposits for one transaction.
  • The proposal timeline fit the borrowed-capital window. The attacker only needed a small pre-position one day earlier to satisfy proposal eligibility, then could wait for the emergency period to mature and assemble the decisive supermajority only at execution time. In practice, Beanstalk split who may propose from who can actually rule right now, and the second gate was much cheaper to buy than the first.
  • emergencyCommit() made temporary vote power actionable before defenders could respond. Once the attacker crossed the two-thirds threshold, Beanstalk did not force a long, defender-readable post-vote delay between hostile majority formed and root authority executes.
  • The passed proposal’s authority was already too broad. Public analyses of BIP-18 show that successful governance could hand execution into attacker-controlled _init logic via the diamond architecture, so no second contract bug was needed after the vote. Winning governance was enough because governance already sat on the protocol’s root execution path.
  • The exploit also shows why governance backstops must be modeled against attacker time, not nominal procedure. By the time the flash-loaned LP deposits existed and the emergency threshold was crossed, the only remaining question was whether anything outside the vote path could still directly stop execution. In Beanstalk, that answer was effectively no.

Detection and audit pivots

  • Measure rentable decisive voting power rather than only tokenholder distribution. For Beanstalk-style systems, that means counting not just borrowable governance tokens, but also the borrowable assets that can be transformed into immediately vote-bearing LP, staking, or receipt positions.
  • Review emergency paths separately from ordinary governance. The shortest path to treasury, upgrade, or arbitrary-execution authority defines the real security boundary; if an emergency branch lets temporary capital reach execution before social coordination can form, that branch is the protocol’s actual root key.
  • Ask what exact object a hostile majority can execute. If proposal success can jump into _init, delegatecall, arbitrary call bundles, or other broad code-execution surfaces, then a vote threshold is functioning as an upgrade authorization surface and should be reviewed like one. timelock-action-bundle-commitment is the positive-design companion when the sharper question is how governance should have frozen one exact reviewed execution bundle.
  • Audit governance backstops by comparing attacker-to-execution time with defender-to-intervention time. If defenders would need another vote, ad hoc social coordination, or an undefined emergency authority after a bad proposal already has supermajority support, the backstop is mostly decorative. governance-backstop-scope-and-intervention-latency-discipline is the companion note for making that design question explicit.
  • Treat admission of vote-bearing LP tokens and similar wrappers as constitutional design, not liquidity plumbing. If a deposit asset can be cheaply manufactured at scale from flash-loanable or highly borrowable inventory, then listing that asset as vote-bearing is equivalent to lowering the real cost of seizing governance.

Failure-prevention checklist

  • Sample voting weight from a prior block or prior epoch, or impose enough seasoning that freshly minted LP, staking, or receipt positions cannot become constitutional power in the same attack window that created them.
  • Keep emergency execution paths narrower than routine governance, not broader. If an emergency branch can still reach treasury transfers, arbitrary _init / delegatecall logic, or upgrade-equivalent authority, it is a root-key lane and needs stronger isolation, not just a higher threshold.
  • Treat whitelisting of vote-bearing LP and wrapper assets as constitutional policy review. The DAO should explicitly model how much flash-loanable or borrowable inventory can be turned into those positions before deciding they deserve immediate voting rights.
  • Hard-commit proposal payload identity. If a passed proposal can hand execution into an _init target or other external logic, reviewers need one frozen executable bundle rather than a socially described plan plus mutable runtime resolution. timelock-action-bundle-commitment is the positive-design companion.
  • Keep attacker-to-execution time longer than defender-to-intervention time. A guardian, veto, pause, or emergency council is only real if it can still stop the dangerous branch after a hostile supermajority forms. governance-backstop-scope-and-intervention-latency-discipline is the companion note here.
  • Separate proposer eligibility from decisive constitutional authority. If a small durable stake can pre-stage a payload and a much larger borrowed stake can later force execution, the second gate is the real security boundary and must be hardened directly.
  • Model rentable majority cost against the value behind governance, including borrowed stablecoins that can be turned into vote-bearing LP positions, not just the spot float of the headline governance asset.
  • Put treasury, mint, and upgrade powers behind stricter review than ordinary policy changes so captured vote is not automatically equivalent to captured protocol root authority.

Audit prompts

  • Which assets can mint Beanstalk-style voting weight immediately on deposit, and how cheaply can those assets be manufactured from flash-loanable or highly borrowable inventory?
  • Could an attacker pre-stage a proposal with a small durable position, then rent the decisive supermajority only at the moment the shortest execution branch opens?
  • What exact powers does a passed proposal have: parameter updates only, or _init / delegatecall / arbitrary call authority that already reaches treasury and upgrade surfaces?
  • How much wall-clock time exists between hostile threshold crossed and payload executes, and what concrete operator or guardian path can still interrupt that window?
  • If the decisive electorate is made of LP or wrapper positions rather than the base governance token, what is the true market depth and borrowability of the assets that create those positions?
  • Does the protocol treat emergency governance as a narrower break-glass tool, or as a faster lane to the same root powers ordinary governance already controls?
  • If offchain proposal watchers, delegate chat rooms, or UI alerts fail for one cycle, does the protocol still have an onchain delay or veto layer strong enough to stop a hostile emergency majority?
  • What is the cheapest realistic path to two-thirds of outstanding voting weight today, and how does that cost compare with the value governance can move in one successful execution?

Lessons that should already be standard

  • Voting weight that can be manufactured from borrowed stablecoins is not durable constitutional legitimacy just because the accounting path mints it honestly.
  • Emergency execution paths are governance root keys. If they can still touch treasury or arbitrary execution, treat them like privileged admin lanes, not mere community fast paths.
  • Whitelisting LP or wrapper assets as vote-bearing is not a liquidity decision; it is a decision about what kinds of capital are allowed to become the constitution.
  • Once governance can execute _init / delegatecall style payloads, governance capture does not need a second bug. Winning the vote already is the exploit.
  • Proposal eligibility and decisive authority are different security problems. A system is not safe just because opening the proposal requires some durable stake if finishing the attack only requires briefly rented balance-sheet mass.
  • High threshold is not a defense when the threshold is reachable by flash-manufactured voting weight and the path to execution is shorter than any realistic human response loop.
  • Borrowable capital, same-cycle vote formation, and arbitrary execution authority compose into an admin key for rent even when the protocol still describes the mechanism as decentralized governance.

Why this incident matters

  • It is one of the cleanest examples of governance behaving like a root key that could be rented for a single block.
  • It shows how LP-token-based voting systems can be more dangerous than obvious governance-token borrow attacks because the vote-bearing assets can be manufactured from borrowed stablecoins during the exploit.
  • It remains a high-signal case for any protocol that combines flash-loan-accessible balances, emergency execution, and arbitrary proposal payloads.

Internal linkages

  • Core recurring pattern: governance-capture.
  • Sharper mechanism lens: borrowable-governance-weight — the decisive bug was that flash-loaned stablecoins could be transformed into immediately vote-bearing LP deposits, so Beanstalk authenticated one-transaction capital as constitutional authority.
  • Closest flash-loan governance cousin: makerdao-bprotocol-flash-loan-governance-vote-acceleration-near-miss-2020-10-26 — Maker’s near miss showed the same rented-vote constitutional risk one and a half years earlier, but Beanstalk is the canonical case where temporary voting power actually crossed the execution threshold and drained protocol assets.
  • Useful contrast: governance-decay-remnant-authority-capture — Beanstalk was not a dead protocol with abandoned constitutional machinery; it was an actively used governor whose live emergency path still treated one-transaction liquidity as durable political legitimacy.

Control surface

Graph View

Backlinks