a16z: How to Avoid DAO Governance Attacks

By Pranav Garimidi, Scott Duke Kominers, Tim Roughgarden

Source: a16z

Many web3 projects use fungible and tradeable native tokens for permissionless voting. Permissionless voting has many benefits, ranging from lower barriers to entry to increased competition. Token holders can use their tokens to vote on a range of issues, from simple parameter adjustments to overhauls of the governance process itself. However, permissionless voting is vulnerable to governance attacks, where an attacker acquires voting power through legal means (such as buying tokens on the open market) and uses that voting power to manipulate the protocol for the attacker's own benefit. These attacks are purely "intra-protocol" attacks, meaning they cannot be solved cryptographically. Instead, preventing these attacks requires thoughtful mechanism design. To this end, we design a framework to help DAOs assess threats and respond to potential governance attacks.

Attacks on Governance in Practice

The problem with governance attacks is not just theoretical. Not only can they happen in the real world, but they have and will continue to happen.

Let's look at this obvious example . Steemit is a startup building a decentralized social network on its blockchain Steem, with an on-chain governance system controlled by 20 witnesses. Voters use their STEEM tokens (the native token of the platform) to elect witnesses. When Steemit and Steem became more and more attractive, Justin Sun made a plan to merge Steem into Tron. Tron is the blockchain protocol he founded in 2018. To gain voting rights, Sun approached one of Steem's founders and bought tokens equivalent to 30% of the total supply. When Steem witnesses discovered his transaction, they immediately froze Sun’s tokens. What followed was a public back-and-forth between Sun and Steem to gain control of enough tokens to allow himself to pick the top 20 witnesses he wanted. After taking part in major deals and spending hundreds of thousands of dollars on tokens, Justin Sun ultimately emerged victorious and effectively had free reign over the network.

Look at the Beanstalk example again. Beanstalk, a stablecoin protocol, was found to be vulnerable to Flashloan governance attacks. The attackers took out a loan in order to obtain enough Beanstalk governance tokens to immediately pass a malicious proposal that would allow them to forfeit Beanstalk’s $182 million in reserves. Unlike the attack on Steem, this one happened on the scale of a single block, meaning it was over and no one had time to react yet.

While these two attacks took place in the open and in front of the public, governance attacks could also have been carried out in secret for extended periods of time. An attacker could create a large number of anonymous accounts and slowly accumulate governance tokens while behaving normally like any other holder to avoid giving away. In fact, given the often low voter participation rates of many DAOs, these accounts can remain dormant for long periods of time without arousing suspicion. From the DAO's perspective, the attacker's anonymous account might help demonstrate a healthy level of decentralized voting power. However, attackers could eventually reach a threshold where these Sybil wallets have the power to unilaterally control governance without the community being able to respond. Likewise, when turnout is low enough, malicious actors may gain enough voting power to take control of governance and then attempt to pass malicious proposals when many other token holders are inactive.

While we might think of all governance actions as simply the result of market forces at work, in practice governance can sometimes produce inefficient outcomes due to incentive failures or other loopholes in protocol design. Just like government policymaking can be swayed by interest groups or simple inertia, DAO governance can lead to poor outcomes if not properly structured.

So, how do we deal with this kind of attack through mechanism design?

Fundamental Challenge: Indistinguishability

The market mechanism for token distribution fails to distinguish between users who want to make valuable contributions to the project and attackers who want to control the project by interfering or otherwise. In a world where tokens can be bought and sold on the public market, neither group behaves indistinguishably from a market perspective: both are willing to buy large quantities of tokens at increasingly higher prices.

This problem of indistinguishability means that decentralized governance comes at a cost. Instead, protocol designers need to make a fundamental trade-off between open decentralized governance and protecting their systems from attacks that attempt to exploit governance mechanisms. The more freedom community members have to gain governance power and influence the protocol, the easier it is for attackers to use the same mechanism to make malicious changes.

This problem of indistinguishability is common in the design of proof-of-stake blockchain networks. Additionally, a highly liquid market in tokens makes it easier for attackers to gain enough stake to compromise the security of the network. Nonetheless, the combination of token incentives and liquidity design makes proof-of-stake networks possible. A similar strategy could help secure the DAO protocol.

A Framework for Assessing and Addressing Vulnerabilities

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

To ensure that the protocol is immune to governance attacks, it should make the profit of the attacker negative. When designing governance rules for a project, this formula can be used to guide the evaluation of 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 performing the attack.

Reduce the value of the attack

Limiting the value of an attack can be difficult because the more successful the project, the more valuable the attack. Clearly, a project should not deliberately sabotage its own success in order to reduce the value of an attack.

Nonetheless, designers can limit the value of attacks by limiting the scope of governance. If governance only includes the power to change certain parameters in the project (for example, the interest rate on a loan agreement), the scope of potential attacks is much narrower than when governance allows full control over smart contracts.

Governance scope can be a function of project phases. In the early days of a project, when it finds its footing, it may have broader governance, but in practice, governance may be tightly controlled by the founding team and community. As the project matures and controls are decentralized, it may be positive to introduce some level of friction in governance - at least a large quorum is required to make the most important decisions.

Increase the cost of obtaining voting rights

Projects can also take steps to make it more difficult for an attacker to gain the voting power needed for an attack. The more liquid a token is, the easier it is to claim voting rights - so almost paradoxically, projects may want to reduce liquidity in order to protect governance. We could directly try to reduce the short-term tradability of tokens, but this may not be technically feasible.

To indirectly reduce liquidity, projects can provide incentives to make individual token holders less inclined to sell tokens. This can be done by incentivizing staking or by giving tokens a value independent of pure governance. The more value token holders receive, the more aligned they are with the success of the project.

Standalone token benefits may include participation in face-to-face events or social experiences. Crucially, such benefits are of high value to individuals aligned with the project, but useless to attackers. Providing such benefits increases the effective price an attacker faces in acquiring tokens: current holders are less willing to sell because the benefit of independence increases the market price; however, while the attacker must pay a higher price, independent The existence of benefits does not increase the value that attackers can obtain after obtaining tokens.

Increases the cost of performing an attack

In addition to raising the cost of voting power, friction can be introduced that makes it harder for attackers to exercise voting power, even if they have earned tokens. For example, a designer could require some kind of user authentication to vote, such as KYC verification or a reputation score threshold. It is even possible to limit the ability of unauthenticated participants to obtain voting tokens in the first place, possibly requiring some existing validators to verify the legitimacy of new participants.

In a sense, this is exactly how many projects distribute their initial tokens, ensuring trusted parties control a significant portion of voting power. (Many proof-of-stake solutions use a similar technique to secure themselves — tightly controlling who gets early stake, and gradually decentralizing from there.)

Alternatively, projects can do so that even if an attacker controls a large amount of voting power, they still face difficulties in passing malicious proposals. For example, some projects have timelocks, so tokens cannot be used for voting for a period of time after the swap. As a result, attackers trying to buy or borrow large amounts of tokens face the added cost of waiting to vote — and the risk of their potential attack being noticed and blocked by voting members in the meantime. Delegations can also be helpful in this regard. By empowering active but non-malicious participants to vote, individuals who do not want to take a particularly active role in governance can still use their votes to protect the system.

Some projects use vetoes, allowing voting to be postponed for a period of time to alert inactive voters to potentially dangerous proposals. According to this scheme, even if an attacker makes a malicious proposal, voters have the ability to respond and close it. The idea behind these and similar designs is to deter attackers from sneaking through malicious proposals and give the project community time to respond. In an ideal world, proposals that are clearly in the interests of the agreement would not have to face these hurdles.

For example, in the Nouns DAO, the veto power rests with the Nouns Foundation until the DAO itself is ready to implement an alternative governance model. As they write on their website, "The Nouns Foundation will veto proposals that pose significant legal or existential risk to the Nouns DAO or the Nouns Foundation."

Projects must strike a balance that allows for a degree of openness (which can sometimes be unwelcome) to community changes, while not allowing malicious proposal loopholes. It usually only takes a malicious proposal to invalidate the protocol, so it is critical to have a clear understanding of the risk tradeoffs of accepting and rejecting proposals. Of course, there are high trade-offs between securing governance and making governance possible - any mechanism that introduces friction to deter potential attackers will of course also make the governance process more challenging.

The solution we outline here is somewhere between fully decentralized governance and partially sacrificing some desirable decentralization for the overall health of the protocol. Our framework highlights the different paths projects can take, trying to ensure that governance attacks are not profitable. We hope the community will start utilizing this framework and further develop these mechanisms through their own experiments to make DAOs even more secure in the future.