a16z: Three Ways to Avoid DAO Governance Attacks

Original text from a16z

Authors: Pranav Garimidi, Scott Duke Kominers, and Tim Roughgarden

Compiled by: DeFi之道

Many Web3 projects use fungible and tradable native tokens for permissionless voting, which can provide numerous benefits, from lowering barriers to entry to increasing competition. Token holders can use their tokens to vote on a range of issues, from simple parameter adjustments to a complete overhaul of the governance process itself. (For a review of DAO governance, see the article "Lightspeed Democracy.") However, permissionless voting is susceptible to governance attacks, where attackers gain voting power through legitimate means (such as purchasing tokens on the open market) and then use that power to manipulate the protocol for their own benefit. These attacks are purely "in-protocol" attacks, meaning they cannot be resolved through cryptographic means. Instead, preventing them requires thoughtful mechanism design. To this end, we have developed a framework to help DAOs assess threats and respond to potential attacks.

Governance Attacks That Have Occurred in Reality

The issue of governance attacks is not merely theoretical; it has occurred multiple times in the real world and will continue to do so.

A prominent example is Steemit, a startup building a decentralized social network on its Steem blockchain, which has an on-chain governance system controlled by 20 validators (witnesses). Voters use their STEEM tokens to elect validators. As Steemit and Steem developed, Justin Sun devised a plan to merge Steem into Tron. To gain sufficient voting power, Sun contacted one of the founders of Steem and purchased tokens equivalent to 30% of the total supply. When Steem's validators discovered Sun's purchases, they froze his tokens. Subsequently, a public dispute ensued between Sun and Steem, with Sun aiming to control enough tokens to elect a new list of validators. With the help of some exchanges, Sun ultimately prevailed and effectively took control of the Steem network.

In another example, the stablecoin protocol Beanstalk was found to be vulnerable to flash loan governance attacks. An attacker obtained a loan to acquire enough Beanstalk governance tokens and immediately passed a malicious proposal that allowed them to control Beanstalk's $182 million reserve fund. Unlike the governance attack on Steem, the Beanstalk attack occurred within the timeframe of a single block, meaning the attack was over before anyone could react.

While these two attacks occurred in public and under public scrutiny, governance attacks can also take place secretly over a long period. Attackers may create numerous anonymous accounts and slowly accumulate governance tokens while behaving like any other holder to avoid suspicion. In fact, given that voter participation in many DAOs is often low, these accounts may remain dormant for extended periods without raising suspicion. From the DAO's perspective, the attackers' anonymous accounts may help present a healthy level of decentralized voting power. But ultimately, attackers may reach a threshold where these "witch" wallets have the unilateral right to control governance, and the community cannot respond. Similarly, malicious actors may gain enough voting power to control governance when voter turnout is sufficiently low and then attempt to push through malicious proposals while many other holders remain inactive.

While we might think that all governance actions are the result of market forces at play, in practice, governance can sometimes yield inefficient outcomes due to incentive failures or other flaws in protocol design. Just as government decision-making can be captured by interest groups or even simple inertia, DAO governance can lead to poor outcomes if structured improperly.

So, how can we respond to such attacks through mechanism design?

Fundamental Challenge: Indistinguishability

The market mechanisms of token distribution cannot distinguish between users who want to make valuable contributions to the project and attackers who highly value disrupting or otherwise controlling the project. In a world where tokens can be bought and sold on public markets, from a market perspective, these two groups behave indistinguishably, both willing to purchase large amounts of tokens at increasingly higher prices.

This indistinguishability issue means that decentralized governance is not free. Instead, protocol designers face a fundamental trade-off between enabling public decentralized governance and protecting their systems from attackers attempting to exploit governance mechanisms. The more governance power and influence community members have over the protocol, the easier it is for attackers to use the same mechanisms for malicious changes.

This indistinguishability problem is common in the design of proof-of-stake (PoS) blockchain networks. Additionally, the high liquidity of tokens makes it easier for attackers to acquire enough stake to undermine the network's security. Nevertheless, the combination of token incentives and liquidity design makes PoS networks possible. Similar strategies can help protect DAO protocols.

Framework for Assessing and Addressing Vulnerabilities

To analyze the vulnerabilities faced by different projects, we use a framework captured by the following equation:

For a protocol to be secure (resistant to governance attacks), the attacker's profit should be negative. When designing governance rules for a project, this equation can serve as a guide for assessing the impact of different design choices. To reduce the incentive to exploit the protocol, the equation implies three clear choices: reduce the value of the attack, increase the cost of obtaining voting power, and increase the cost of executing the attack.

1. Reduce the Value of the Attack

Limiting the value of an attack can be challenging, as the more successful a project is, the more valuable a successful attack becomes. Clearly, a project should not intentionally undermine its own success merely to reduce the value of an attack.

However, designers can limit the value of an attack by restricting the scope of governance functions. If governance only includes the power to change certain parameters in the project (e.g., interest rates in a lending protocol), then the potential scope of attacks is much narrower than if governance allows for comprehensive control over governance smart contracts.

The scope of governance can be a function of the project's stage. In the early stages of a project, when it is finding its footing, there may be broader governance, but in practice, governance may be tightly controlled by the founding team and the community. As the project matures and decentralization increases, introducing a certain degree of friction in governance may make sense—at least, the most important decisions may require the participation of a large number of community members.

2. Increase the Cost of Obtaining Voting Power

Project teams can also take steps to make it more difficult to obtain the voting power needed for an attack. The stronger the liquidity of the tokens, the easier it is for attackers to acquire voting power, which is almost paradoxical; project teams may want to reduce liquidity to protect governance. People can attempt to directly reduce the short-term tradability of tokens, but this may not be technically feasible.

To indirectly reduce liquidity, project teams can provide incentives that make individual token holders less willing to sell. This can be achieved through staking incentives or by giving tokens independent value beyond pure governance. The more value token holders receive, the more aligned they are with the project's success.

The benefits of independent tokens may include participation in events or social experiences. Crucially, such benefits are valuable to individuals collaborating with the project team but are useless to attackers. Providing these benefits raises the effective price attackers face when acquiring tokens: due to the independent benefits, current holders will be less willing to sell, which will drive up market prices. However, while attackers must pay a higher price, the existence of independent functions does not increase the value of acquiring tokens for attackers.

3. Increase the Cost of Executing the Attack

In addition to raising the cost of voting power, we can introduce friction that makes it more difficult for attackers to exercise their voting power even after acquiring tokens. For example, designers may require some form of user verification to participate in voting, such as KYC checks or reputation score thresholds. One might even restrict the ability of unverified participants to acquire voting tokens initially, possibly requiring some existing validators to attest to the legitimacy of new participants.

In a sense, this is precisely how many projects allocate their initial tokens, ensuring that trusted parties control a significant portion of the voting power. (Many proof-of-stake solutions use similar techniques to protect their security, namely strictly controlling who is entitled to early stakes and then gradually decentralizing.)

Alternatively, project teams can make it so that even if attackers control a large amount of voting power, they still face difficulties when attempting to push through malicious proposals. For example, some projects have time-lock settings, preventing tokens from being used for voting for a period after being exchanged. Thus, attackers attempting to purchase or borrow large amounts of tokens will face additional costs, as they will need to wait before they can actually vote, and voting members may notice and mitigate the risk of their potential attack. Delegation is also helpful here; by granting active but non-malicious participants the right to vote on their behalf, individuals who do not wish to play a particularly active role in governance can still contribute their voting power to protect the system.

Some projects also employ veto mechanisms that allow votes to be delayed for a period to alert inactive voters to potentially dangerous proposals. In such schemes, even if attackers propose malicious proposals, voters have the ability to respond and shut them down. The idea behind these designs is to prevent attackers from sneaking through malicious proposals and to give the project community time to formulate a response. Ideally, proposals that clearly align with the interests of the protocol should not face these obstacles.

For example, in Nouns DAO, the veto power is held by the Nouns Foundation until the DAO itself is ready to implement alternatives. As they state on their website:

"The Nouns Foundation will veto proposals that pose significant legal risks or threats to the Nouns DAO or the Nouns Foundation."

Project teams must strike a balance to allow for a certain degree of openness to changes in the community (which may sometimes be unpopular) while not allowing malicious proposals to slip through the cracks. Generally speaking, it only takes one malicious proposal to render a protocol ineffective, so it is crucial to clearly understand the risk trade-offs of accepting and rejecting proposals. Of course, there is a high level of trade-off between ensuring governance security and making governance possible, as any mechanism that introduces friction to deter potential attackers will also make the governance process more challenging.

The solutions we outline here lie between fully decentralized governance and sacrificing some decentralization for the overall health of the protocol. Our framework highlights the different paths that project teams can choose when seeking to ensure that governance attacks are not profitable. We hope that communities will use this framework to further develop these mechanisms through their own experiments, making DAOs more secure in the future.