Hacking a DAO Without Breaking the Code

In April 2022, Beanstalk lost roughly $181 million in a governance exploit.

The strange part was not that the attacker somehow bypassed the protocol's permission system.

The permission system said yes.

Beanstalk's governance contract checked whether enough voting power supported a proposal. The attacker temporarily acquired enough voting power. The threshold was satisfied. The proposal executed.

The code did not forget to check authorization.

The problem was what the system was willing to accept as authorization.

Governance Is More Than Voting

It is easy to think of DAO governance as a crypto version of an election: token holders discuss proposals, vote, and the majority wins.

But in many on-chain systems, a successful vote can do much more than express an opinion. Governance may be able to change protocol parameters, upgrade contracts, assign privileged roles, mint tokens, or move treasury assets.

That makes governance part of the security perimeter.

A voting token is not literally a password, but economically it can behave like an access credential. Enough voting power may grant the authority to tell the protocol what to do next.

And once authority is represented by a transferable financial asset, a new security question appears:

How expensive is it to acquire enough authority?

A Flash Loan Gives You Capital, Not Authority

This is where flash loans enter the story.

A flash loan lets someone borrow a large amount of crypto without ordinary collateral, provided the funds are returned within the same atomic transaction. If the loan cannot be repaid by the end, the entire transaction reverts.

That can sound almost supernatural: borrow hundreds of millions, use them, return them, and finish with no long-term debt.

But a flash loan by itself cannot take over a DAO.

Temporary money becomes temporary political power only if the governance system allows it.

A well-designed voting system may ask:

How much voting power did this address have before the proposal began?

A vulnerable one may effectively ask:

How much voting power does this address have right now?

That difference can be enormous.

Beanstalk: Borrowing a Supermajority

Beanstalk made that difference painfully visible.

Before the April 17, 2022 exploit, the attacker had prepared governance proposals and allowed the protocol's required waiting period to pass. Then, in one transaction, the attacker borrowed more than $1 billion in assets from DeFi liquidity sources and converted those temporary funds into positions that generated Beanstalk governance power, known as Stalk ^[1].

That temporary position gave the attacker more than the supermajority required by Beanstalk's emergency governance path.

The attacker then used that authority to execute a malicious proposal through the protocol's own governance machinery.

After the proposal transferred protocol assets, the temporary positions were unwound and the flash loans were repaid — all inside the same atomic transaction.

Security analyses estimated the broader protocol loss at roughly $181–182 million, while Beanstalk described about $77 million in non-Beanstalk user assets as stolen. Those are different numbers measuring different parts of the damage.

The important point is not the exact total.

It is the authorization path:

borrow capital
      ↓
convert capital into voting power
      ↓
cross governance threshold
      ↓
authorize proposal
      ↓
execute
      ↓
repay borrowed capital

The attacker did not need to hold a permanent controlling stake in Beanstalk.

For one transaction, temporary capital was enough to become temporary authority.

The Missing Security Feature Was Time

Beanstalk reveals something counter-intuitive about security:

delay can be protection.

Governance systems do not only need to ask how many votes support a proposal. They also need to ask when those votes were acquired and how long the system should wait before acting on them.

Modern governance frameworks therefore use mechanisms such as historical voting snapshots and execution timelocks ^[2].

A snapshot can measure voting power at an earlier block rather than at the instant someone casts a vote. Borrowing tokens and returning them inside the same transaction then does not magically create historical voting power.

A timelock solves a different problem. Even after a proposal passes, execution waits.

That delay gives users, delegates, security teams, and protocol guardians time to notice what was approved and react before the command becomes irreversible.

In ordinary software, delay often feels like friction.

In governance, friction can be a security feature.

Build Finance: No Billion-Dollar Loan Required

Beanstalk might make governance attacks sound like exotic financial engineering.

Build Finance showed the much simpler version.

In February 2022, an attacker accumulated enough BUILD governance tokens to propose giving themselves control over important parts of the protocol ^[3].

The first attempt was noticed and defeated.

The attacker then moved the tokens to another wallet and tried again. According to reporting based on the project's own account, the second proposal was not surfaced by the community's usual Discord alert bot and received far less opposition.

It passed.

Once the governance proposal granted the attacker control over the minting and governance infrastructure, the attacker created new BUILD tokens, sold them into available liquidity, accessed treasury-related assets, and caused losses of roughly $470,000.

No enormous flash loan was necessary.

The protocol had authority available for capture, and too little effective opposition appeared before that authority changed hands.

How Decentralized Is the Decision?

This is where counting token holders can become misleading.

A DAO may have thousands of wallets holding its governance token and still have decision-making power concentrated in very few hands.

Feichtinger and colleagues studied 21 on-chain governance systems and found that in 17 of them, fewer than ten token holders or delegates were sufficient to control more than half of the relevant voting power ^[4].

That does not mean every one of those DAOs was maliciously controlled.

It means the important governance metric is not simply:

How many holders exist?

It is:

How many independent actors are needed to determine the outcome?

Those can be very different numbers.

Then Votes Get a Price

There is another consequence of turning governance into a tokenized asset.

If voting determines where money flows, voting power itself becomes economically valuable.

Curve's gauge system made this especially visible. Holders of governance-linked voting power can influence where token emissions are directed, and platforms such as Votium emerged to coordinate incentives around those votes ^[5].

This is not the same thing as a hostile treasury takeover.

The system is explicitly designed to let economic actors compete for governance influence.

But that makes the broader point unusually clear:

governance power has a market price.

Once a vote controls cash flows, protocols can calculate what that vote is worth. Other actors can do the same.

What Does It Cost to Become the DAO?

This changes the way governance security should be imagined.

The important question is not merely whether an attacker can find a bug.

It is also whether acquiring control is economically practical.

Conceptually, the cost depends on several things:

how much voting authority is required
×
how expensive that authority is to acquire
×
how long it must be held
+
the risk that somebody notices and stops you

That is not a literal equation. It is a way to see the attack surface.

A protocol becomes harder to capture when voting power must exist before a proposal, when authority must remain committed over time, when dangerous actions wait behind a timelock, and when obviously hostile proposals can be cancelled or contained before execution.

In other words, DAO security has an economic dimension.

The protocol needs to make hostile authority expensive enough to acquire and slow enough to detect.

More Friction Can Mean More Security

The obvious answer might be: make everyone vote on everything.

That does not scale particularly well.

Governance requires attention, expertise, coordination, and time. Small holders may rationally decide that researching every parameter change is not worth the effort.

So mature governance systems often add structures that sound less purely decentralized:

• delegates who specialize in governance;
• proposal thresholds that prevent trivial spam;
• historical voting snapshots;
• timelocks before execution;
• guardians or councils with tightly limited emergency powers;
• veto windows for clearly dangerous changes.

Every one of those mechanisms introduces friction or trust somewhere.

That creates a real design tension.

Remove too many brakes and hostile authority may move faster than the community can react.

Add too many guardians and special permissions, and the system begins to look less autonomous.

There is no purity setting that makes that trade-off disappear.

The Right to Tell the Code What to Do

A smart contract is very good at answering mechanical questions.

Did this proposal reach the required threshold?

Did the voting period end?

Did the timelock expire?

What it cannot determine by itself is whether the voting power represented broad agreement, one dominant holder, delegated concentration, or temporarily assembled capital.

Those are properties of the governance system around the contract.

That is why secure code is only part of DAO security.

The treasury may be protected by flawless permission checks.

But somebody still has to decide who is allowed to satisfy them.

Sometimes the code is not what gets hacked. What gets hacked is the right to tell the code what to do.