Examining Exploits | Beanstalk, Build, and Better Governance

Since the inception of decentralized finance (DeFi), protocols with imperfect code, insufficient economics, or faulty governance structures have been hacked and exploited. Exploits most commonly take advantage of vulnerable code or poor economic design. A smaller portion of exploits, two of which I review here, occur by manipulating protocol governance.

Decentralized governance promises to allow groups of people to change software without relying on a central authoritative party to decide to implement new code. However, it’s sometimes possible for bad actors to use decentralized governance to accumulate enough voting power to make governance decisions on their own. The exploitation of Beanstalk and Build Finance may reveal which governance changes can prevent exploitation in the future.

Truly decentralized governance can work at a large scale, but many problems in governance are a direct result of low participation or low capital requirements for vote buying. Resolving governance problems at early stages may involve temporarily implementing mechanisms that do not maximize decentralization.

Beanstalk — $77 million

April 17, 2022

Beanstalk is a stablecoin protocol that issues credit in order to oscillate the price of the native stablecoin, Bean, across its $1 peg. It’s also the subject of the largest governance exploit in DeFi to date. Prior to the exploit, users could deposit ETH, 3CRV or LUSD into the various Bean liquidity pools in return for a distribution of Bean seigniorage. The LP tokens for BEAN:ETH, BEAN:3CRV and BEAN:LUSD were held in the Beanstalk contract, which could be arbitrarily changed via the governance mechanism.

Voting power in Beanstalk governance is acquired by depositing Beans or whitelisted LP tokens into the Silo, which can be thought of as the Beanstalk bank. On April 17th, 2022, an exploiter used a flash loan to buy Beans and deposited them in the Silo. They acquired enough voting power to immediately pass a governance proposal as soon as it became possible to do so. They passed their own proposal, executing code that transferred all of the deposited assets from the Beanstalk contracts to an address they controlled.

Beanstalk’s governance mechanism was designed to maximize decentralization. The exploit revealed some problems with its ambitious design. There were two main enabling factors in the exploitation of Beanstalk:

1. The governance structure allowed a proposal to execute immediately when it passed.
2. It was possible to immediately accumulate enough voting power to pass a governance proposal.

In the case of Beanstalk, it’s possible but still unclear whether resolving the first issue would have prevented the exploit. The structure of the code used in the exploit was incredibly obfuscated and the main exploit code did not exist on-chain until immediately before it was executed. For technical details of the exploit, see the methodology here.

Public code is not public knowledge.

The portion of the code used in the Beanstalk exploit that was malicious was private until moments before it was called. The implications of its execution were not clear to governance participants before it was deployed. The potential for exploitation through the proposed code would likely have been identified if the code was audited and tested on-chain before it could be used. Ideally, members of the community could verify that the code accomplishes exactly what the written proposal says it will before they vote on the proposal.

This issue is part of a general trend in open-source decentralized protocols: although anyone can access smart contracts, the code is complex enough that information about how the technology works and the implications of its implementation are not widely understood. Governance decisions are made by users with varying degrees of familiarity with the relevant code and economic mechanisms. There are two main solutions to this problem: create systems where voting power is delegated to knowledgeable representatives, or translate code into actionable knowledge that can be easily understood by governance participants.

Accumulating voting power should take time.

The primary enabling factor of the Beanstalk exploit was that a supermajority of voting power could be accumulated immediately by buying Beans on the market. Enough potential voting power was held in liquidity pools that a single flash loan transaction allowed the exploiter to acquire over two-thirds of it.

The most straightforward answer to this problem is to incentivize illiquid voting power. However, the more general issue is that (regardless of how and when it’s accumulated) it was not difficult or expensive enough to immediately accumulate and use voting power. Many factors contribute to this difficulty: the ability of the exploiter to use a flash loan, the liquidity of voting power, the cost of voting power, quorum requirements, and more. Ensuring that voting power changes relatively slowly allows governance participants to anticipate and proactively prevent threats.

Token-weighted voting (sometimes called coin voting) is the standard in DeFi governance. When tokens are transferable, token-weighted voting means votes can be bought. In addition to creating vulnerabilities, vote buying is undemocratic and naturally tends toward plutocracy. Any token-weighted voting system that allows for voting power to be transferred is susceptible to the pitfalls of vote buying. For a robust criticism of coin voting governance, see Vitalik Buterin’s essay.

A partial solution to the problems associated with token-weighted voting may come directly from Beanstalk’s governance system. Voting power on Beanstalk is accumulated by depositing whitelisted assets into the protocol and is a function of (1) the value of deposited assets and (2) the amount of time they have been deposited. The system by which voting power is distributed leads to power being less concentrated over time. In a more mature protocol, heavily weighting time as an input in the calculation of voting power makes it difficult to gain voting power through a flash loan or otherwise immediately acquire a significant portion of voting power.

If the voting power of participants increases over time and is non-transferable (the latter is not the case on Beanstalk), it’s possible that although total voting power is predicated on just $10 million of deposits, after some time, it will cost $10 billion to immediately acquire that level of power. This solution introduces new problems because it becomes almost impossible for new depositors to acquire a significant level of voting power once the protocol has been around for a long time.

Massive and immediate voting power shifts can also be prevented by locking voting power when a proposal is submitted. By taking a snapshot of token-holders, DAOs can ensure power distribution does not change because people are interested in voting on a single proposal.

Build Finance — $470,000

February 10, 2022

Build Finance was a venture capital DAO that assisted new projects on Ethereum with funding and operations. At the time of its exploitation, Build Finance had both its own treasury and a BUILD token, both of which were managed through a decentralized governance process.

The attacker had a large holding of the governance token used to vote on proposals, but also took steps to ensure that the catastrophic governance proposal had as few eyes on it as possible. They made documentation unavailable and disabled a bot that publicized new governance proposals. The Build Finance exploit is a straightforward example of exploitation by controlling information flows.

The quorum required for the exploit was relatively low, and although the attacker did not own the majority of tokens in circulation, they were able to exploit a lack of oversight and participation in governance to implement code that gave them control of the token contract.

The attacker took control of the Build token contract, minted more tokens, and used those tokens to drain liquidity pools, collecting around $470,000.

Effective governance requires active participation.

The Build Finance exploit was enabled by both a lack of attention paid to a new governance proposal and a governance system that allowed proposals to pass despite low participation. While low participation criteria can prevent protocols from becoming stagnant when governance participants are inactive, it can also lead to changes being made without the knowledge of interested parties. The primary factor that led to the exploitation of Build Finance was a lack of awareness and information. The exploit could have been prevented by systems that ensured governance participants were aware of new proposals and their implications and gave them ample time to react.

Building Better Governance

Governance exploits reveal two key insights for decentralized governance:

• Exploitation of DeFi protocols can occur at the informational rather than technological level.
• Significant changes in voting power should take time.

The Beanstalk and Build Finance exploits both resulted directly from the ability of a single entity to propose and implement changes to a protocol. The exploits both involved an intentional obfuscation of information. In Beanstalk’s case, the exploit code was spread out across multiple contracts, one of which was not publicly available on Ethereum Mainnet. In the case of Build Finance, the attacker revoked access to timely information about governance proposals and processes.

A key piece of information that governance participants need is the distribution of governance power over a protocol. Equipping participants with knowledge about governance power dynamics involves making power shifts predictable. The most straightforward way to provide predictability is to design systems that distribute governance power over time.

Making decisions in a decentralized fashion requires that many parties with different sets of knowledge are adequately informed enough to make good decisions. Tools for democratizing information–especially by rendering technical information understandable and available–will become increasingly important for building robust governance systems. In cases where information cannot be adequately democratized, governance participants must identify delegates they can trust to act on their behalf.

If you’re interested in decentralized governance or are looking for experienced delegates to represent you, follow Flipside Governance on Twitter and Medium to stay in the loop.

You can also find me on Twitter: @quasimatt