Common Vulnerabilities: Protocol Governance and DAOs - Smart Contracts

Decentralised Autonomous Organisations (a.k.a “DAOs") were conceptualised early in Ethereum’s development as onchain entities that could manage decisions and capital in a manner similar to a traditional company. Due to the low barriers to formation and the magical ability to turn code into cash, these structures have had a Cambrian explosion in popularity for managing new protocols, in spite of their murky fit with regulation and traditional legal structures.

In this article we will document and discuss the causes of some of the more influential DAO exploits, explaining how these issues occurred and what steps could have been taken to mitigate them.

Reentrancy

Where better to start than one of the first protocols developed on Ethereum, “The DAO”, which caused an early Ethereum governance crisis in 2016. The DAO was designed as a general purpose ETH based investment vehicle, and implemented an onchain voting system, whereby token holders could vote on proposals to execute them.

At the time, the DAO had received about $150 million in ETH from more than 11,000 investors. This represented about 14% of the circulating ETH back in 2016. The exploit was based around a reentrancy vulnerability that allowed draining of the DAO funds into an identical contract, a sort of subDAO structure. While most smart contract developers are familiar with reentrancy risks nowadays, this was a relatively novel attack in 2016. Thankfully, as the reentrancy attack hinged on the use of identical contracts to the original DAO, this meant the stolen funds were then locked for 28 days and could not be immediately moved.

The stasis caused by the 28 day lock allowed time for a coordinated response, a luxury most hacks do not normally have. Faced with the threat of fund clawback, the hacker (or someone claiming to be them) made legal threats claiming they had obtained the funds legitimately and they would fight attempts to return the funds to original DAO participants. The Ethereum community decided to fork the network, first a soft fork was proposed, but this was ruled out for technical reasons. The result was a hard fork of Ethereum. As Ethereum was then a Proof of Work network, this required more than minor coordination, miner coordination. For a PoW network to hard fork requires a majority of the network nodes to update their client software, given the diversity of miners worldwide, coordinating this can be a difficult task.

Some in the community disagreed with the choice to fork, claiming “Code is Law” and that the DAO hacker was the rightful owner, thus spawning Ethereum Classic. Since then, regardless of how large hacks have been, there has been a strong resistance to the use of hard forks to resolve them, especially since the DeFi ecosystem has grown tremendously and any hard fork would potentially split or damage existing protocols.

Mitigation:

Do not allow reentrancy via use of nonReentrant modifiers such as OZ’s reentrancyGuard.
Do not allow arbitrary votes, do not rely on hard forks or other protocols freezing assets to recover value.
Make use of the "Checks-Effects-Interactions" pattern so that the contract state is up-to-date before making external calls.
Add invariant checks to end of functions (only applicable in some circumstances).

Insider Threats

The next DAO event on the timeline related to DGD from Digix DAO, who in 2016-2020 were a large DAO having crowdfunded $5.5million in ETH during their ICO for the purpose of building an onchain gold backed token DGX. This proved to be one of the first successful attempts to tokenize real world assets. Digix operated successfully for several years and chose to wind down operations in 2020.

The wind down of Digix was notable as it was partially motivated by the rise of Ethereum’s price. At the time of the DAO’s operation, the underlying ICO assets were now worth more than DGX - the treasury having 386,000 ETH valued at $69million, while the total supply of DGX was valued at only $29million at the time of the dissolution announcement in November 2019. The disparity in price had been noted by traders who then drove sentiment to dissolve DGX, and as a result, the price of DGX closed in on the expected ETH redemption rate value.

Digix stands alone as a victim of their own success, and is a questionable victim at that. Many DAOs would most likely want their treasury funds to exceed the token valuation. Hence, there is no smart contract mitigation for this issue, other than just being wary of traditional business hostile takeovers when managing large amounts of assets. While not seen in the Digix case, DAOs must also be wary of actors who notice large token reserves and look to siphon off funds for little or no work from the inside, taking advantage of their decentralized nature to act unopposed.

The company behind DigixDAO, Digix, continued to operate DGX without DGD until 2023 when the project closed completely.

A topical case of contentious voting was with Compound Finance, where a large voter called Humpy repeatedly attempted to pass votes over a period of four months, eventually succeeding due to low voter interest and turnout. As a result of this, Humpy was able to pass proposal 289 which sought to grant his group, the Golden Boys, 499,000 COMP tokens. These tokens would have made them the largest voting delegate for Compound. The issue was thankfully resolved by reaching a compromise that allocated some profits to users staking COMP tokens, which in turn led to proposal 289 being cancelled. The issue called into light the idealistic nature of some DAOs, while COMP is held by around 290,000 addresses only 57 addresses voted on proposal 289. A further lesson on this topic is that DAOs should aim to align token holder incentives with active participation, one noted method was requring long lock times for token holders who wish to vote, aiming to prevent short term outlooks.

Flash Loan Voting

Digix attracted attention due to the large holdings of its DAO compared to the token price. This has also happened to other DAOs, but in more hostile circumstances. Beanstalk DAO was a more recent instance of this, operating beanstalk.money, a decentralised credit based stablecoin protocol.

In April 2022 a hacker exploited Beanstalk DAO's voting system having noticed that a prior proposed vote could be executed in one block, enabling the use of a flash loan to purchase sufficient voting tokens BEAN to force the voting outcome desired. This vote approved the transfer of assets from protocol liquidity pools to the hacker, netting a giant $77 million profit for the hacker, who subsequently liquidated all assets for ETH and disappeared into the maelstrom that is Tornado Cash.

The Beanstalk exploit was possible as emergency governance votes had no time delay, and so could be executed in the same block as a flash loan, which was used as the source of capital needed to gain the majority voting rights.

Mitigation:

Enforce execution of vote to occur in different block from voting.
Restrict execution to trusted parties.
Use multi block snapshots for voting balances, either through offchain voting such as Snapshot or onchain mechanisms such as Merkle proofs of all voter balances. This is becoming increasingly important as Multiblock MEV becomes possible under Proof of Stake.

Proposal Execution

It is clear to see that voting structures can be difficult to get right. Another consideration for DAOs can be transaction ordering of legitimate proposals, as Sonne Finance found out in May 2024 when attempting to add a new collateral token VELO to their Optimism lending market.

As a fork of Compound Finance, the Sonne Finance team were aware of previously discovered accounting vulnerabilities inherent in opening a new empty market to the public, and so had planned to make the first market order to prevent this exploit from occurring. However, as the execution of proposals was decentralized, anyone could trigger them, and if doing so, there was no restriction on the ordering or inclusion of all proposal transactions. The hacker knew this and included the transaction opening the new market but not the initial market order, replacing it with their own order which exploited the accounting bug to enable the theft of $20 million of various assets from the lending market.

Mitigation:

Ensure multi-step proposals can only be executed in a certain order.
Package multi-step proposals into one transaction to enforce ordering using contracts such as OpenZeppelin’s Multicall library

Fake Proposals

Legitimate proposals are difficult to get right, but given the permissionless nature of DAOs, illegitimate ones can be just as difficult to notice. Tornado Cash, a well-known Ethereum-based privacy tool, enables users to mix their funds, making transactions harder to trace. Though some courts would have you believe Tornado Cash was controlled by the developers, it was controlled by a DAO with the TORN governance token.

In May 2023 a storm was brewing, proposal C503893 had been submitted and claimed to be identical to a preceding proposal, however everything was not as it seemed. The contract contained a function called emergencyStop() that self-destructed the proposal contract, a seemingly harmless escape hatch.

Through clever contract crafting and via careful application of CREATE and CREATE2 instructions, the malicious proposer managed to deploy a different contract at the same address as the original C503893 proposal. This Trojan horse vote allowed the attacker to wait for the original proposal to pass, then substitute their malicious payload in its place. The malicious payload gave the attacker control of all locked TORN tokens, allowing them to gain control of the DAO by holding the majority vote. These TORN tokens were then removed and sold to net about $1 million. Ironically, the funds were then mixed through Tornado Cash’s otherwise unaffected mixing pools.

Mitigation:

Carefully analyse submitted proposals contracts.
Make use of a proposal template to prevent creative use of CREATE and CREATE2 or enforce the choice that all proposals must be directed created by an EOA only.
Larger DAOs should practice emergency response war games. Sigma Prime as part of SEAL helped Aave test their protocol monitoring and response capabilities, submitting genuine and decoy proposals for the Aave team to attempt to filter.

Anonymous Developers/Quorum Failure

While the Tornado Cash developers faced legal battles, other DAOs choose to be anonymous to avoid similar legal issues. Swerve Finance were a DeFi clone of Curve Finance, launched anonymously due in part to Curve’s copyrighted code, with governance entrusted to a multi-sig operated by known characters of DeFi, including FTX’s Sam Bankman-Fried.

The multi-sig would turn out to be the straw that broke the camel’s back - when it came to signing governance operations, the signers were nowhere to be found, leaving the protocol to a grinding halt as developments could not be enacted.

Mitigation:

Carefully plan who is involved on a multi-sig, ensure actors are different people with reputations to risk and do not have ulterior motives.
If possible, have multiple voting systems as a backup, i.e. allow a slow decentralized token voting system that can be used if the mutli-sig quorum becomes untenable.

Insecure quorums/excessive DAO control

Swerve circled back to governance misadventure in March 2023 again. In light of the multi-sig failure, control was handed to the holders of SWRV tokens who could then vote on issues, and the project was summarily abandoned by the development team. This was noticed by an actor who determined the cost of buying enough SWRV to fix voting outcomes was profitable for exploits. The attacker created a governance vote that allowed them to direct accrued fees and the liquidity of a pool to their address.

Mitigation:

Be wary of leaving funds in abandoned projects.
Monitor accrual of voting tokens.
Restrict power of votes to not be able to access user funds directly.
Add a time lock delay to successful vote execution.

Timelocks

One common method to protect protocol users from such malicious votes is the use of timelocks. Timelocks require a successful vote to be delayed for a certain time period prior to execution, which allows protocol users to exit the system if they disagree with the enacted changes.

While timelocks are popular among DAOs, they can have their own drawbacks, namely making emergency governance response times longer.

One instance of timelock delays being problematic was a vote from Compound Finance, a leading Ethereum-based lending market. Compound Labs had professionally reviewed the proposed code change that had been voted on, however due to a change of base units from 0 to 1e36, a previously acceptable optimisation including > sign was required to be changed to >=. As a result of this code change, numerous token suppliers found themselves eligible for COMP rewards they should not be able to claim. The protocol voters could only look on as approximately $70million of COMP tokens were erroneously claimed, whilst the timelock used for Compound governance prevented any swift reaction. To add insult to the injury, before the governance fix had passed its purgatory period, a user discovered that anyone could call a function called drip() to enable the contract with wonky logic to distribute more COMP tokens. In total about $147 million of COMP were released.

Mitigation:

Perform careful simulation of proposal changes on testnets and forked networks.
Minor gas optimisations can become costly, straightforward designs can be more important.
Multiple different speed governance routes may be beneficial, such as pause only mechanisms that can be instantaneous or have much shorter timelocks i.e. 1 day instead of 7 days.

Conclusion

It’s plain to see that the organisation of a DAO and governance in general is a tricky process with many potential pitfalls.

One way to bypass common mistakes is to build upon the work of other successful open source DAOs, allowing you to utilise their battle tested and audited work. A common path is to adopt the Compound Finance Governor Alpha & Bravo frameworks. These modules were designed for the governance of lending markets via delegated token voting and use of timelocked proposals, they are commonly used with forks of the Compound market but can also be adapted for other projects.

It is also recommended to check if OpenZeppelin’s libraries fit your needs, as they also offer governance related plugins. The base Govenor plugin offers extensions that handle different voting styles and the use of timelocks with proposals.

Whatever pathway you choose, forming a DAO is a complex and difficult undertaking, make sure to work with your team and if possible other DAOs in the space to share ideas. Plan for unexpected events and observe the problems faced by other protocols, ensure your code is audited prior to deployment and engage with security experts during your design to aid adopting best practices. Good luck!