Governance attack

Why this is a different category from an exploit

A smart contract exploit finds a mistake in the code. A governance attack finds no mistake at all. The proposal is valid, the vote is valid, the execution is valid, and at the end of it the treasury belongs to somebody else. That distinction has a commercial consequence, because the controls that catch the first category, audits and formal verification, do not catch the second. A protocol can pass every audit it commissions and still be one flash loan away from handing over the keys.

Two conditions have to hold for the attack to work. The attacker has to be able to acquire enough voting weight, and the system has to let them spend it before anyone can respond. Break either condition and the attack becomes a slow, expensive, visible accumulation that a community can watch approaching.

Beanstalk, 17 April 2022

Beanstalk's own statement puts the attack at roughly 12:24pm UTC on 17 April 2022 and the theft at about 76 million dollars in non-Beanstalk user assets, carried out by using a flash loan to exploit the protocol's governance mechanism.¹ CertiK's analysis puts the total loss at approximately 182 million dollars, of which the attacker kept 76 million as profit.²

The root cause is two design choices meeting. Voting power was tied to Silo deposit receipt assets that could be minted inside the same transaction with borrowed funds, with no check for it. And Beanstalk carried an emergencyCommit function that executed immediately, with no timelock delay, once a supermajority above two thirds had been reached.²

Put those together and the attack writes itself. Borrow, mint voting weight, cross the two thirds line, execute, repay the loans, keep the difference, all inside one transaction that no human saw before it confirmed. Nobody had to find a bug, because there was nothing to find.

Mango Markets: the vote as a settlement device

On 11 October 2022 Avraham Eisenberg manipulated the price of the MNGO token through large positions on Mango Markets, borrowed against the inflated collateral value, and drained roughly 114 million dollars from the protocol's liquidity pools.³ What came next is the part that belongs in this entry. He acquired MNGO governance tokens with part of the proceeds and used them to vote on a settlement proposal with Mango DAO, returning some of the funds in exchange for keeping the rest and the DAO agreeing not to pursue him.³

It did not work where it mattered. A federal criminal prosecution followed in the Southern District of New York, United States v. Eisenberg, No. 1:23-cr-00010, filed 9 January 2023, alongside separate civil actions brought by the CFTC and by Mango Labs in the same district.⁴

The design lesson is blunt. A governance vote binds the protocol's own contracts. It does not bind a prosecutor, a regulator or a counterparty, and a vote bought with the proceeds of the underlying conduct reads as evidence rather than as a release. Any governance design that treats an onchain vote as a settlement instrument is making a legal assumption that this record does not support.

What we could not confirm, and are therefore not printing

Two figures circulate with the Mango incident that will not appear here. The Mango DAO proposal identifier for the settlement, and the exact amount Eisenberg was permitted to retain, which is reported inconsistently across public accounts. Neither could be tied to a primary Mango DAO governance document.

That refusal is deliberate. A reference page that invents a proposal number to look thorough is worse than one saying the number is not established, because the invented one gets quoted, then cited, then treated as settled. The same discipline applies to the claim attached to almost every article in this subject area, that most DAOs run under ten percent governance participation. There is no study behind it. Design your defences against turnout you have measured yourself.

Five controls, and the ones Beanstalk was missing

The named defences against flash loan governance capture are well established: a meaningful delay between a vote passing and its execution; snapshotting token holdings at the time a proposal is submitted rather than at the time of the vote; time weighted voting power that requires tokens to be held for a period before they confer weight; multi stage governance requiring several rounds over an extended period; and contract level detection of a vote occurring in the same transaction as a large deposit.⁵

Beanstalk had none of the first three where it counted. The emergencyCommit path removed the delay, voting weight was read live rather than from a proposal time snapshot, and freshly minted deposit receipts carried full weight immediately.² Any one of those three, on its own, would have broken the sequence. The delay alone would have turned a single private transaction into a public window with hours in it.

Notice what is absent from that list: an audit. Every one of those five is an economic parameter rather than a code property, which is why they get decided by whoever designs the token mechanics and not by whoever writes the tests. This is a tokenomics failure mode that happens to be executed in Solidity.

The question that finds this before an attacker does

For every asset that carries voting weight, ask what it costs to acquire that weight for one block. If the answer involves a lending market, an AMM, or anything else that will lend you the asset and take it back within a single transaction, your governance is priced at the cost of a flash loan fee. Then ask how long the gap is between a vote passing and execution, including every emergency path. Those two numbers are your governance security budget, and most teams have never written either of them down.

In our experience the emergency path is where the check fails. Teams design the main route carefully, then add a fast lane for incidents, and it inherits none of the protections that took a quarter to argue about. Beanstalk's emergencyCommit was that fast lane. Every protocol has one, and it should be reviewed as its own governance surface rather than as an exception to the real one.

The last question is what the vote is protecting. A governance surface is worth attacking in proportion to what sits behind it, so the treasury and revenue you are defending set the budget for defending them. That is an ordinary security decision, and it stops being ordinary only when people forget the voting system is part of the attack surface.