Contents

DAO Security I: Smart Contract Security for DAOs

‍

This guide is the first in a series on DAO security, covering smart contracts, governance, and operations.

‍

Having airtight DAO security starts at the base layer: the smart contracts. Before you can get into the details of governance design, treasury management, and operational security, you must ensure that the smart contracts you’re built upon are safe.

‍

Most DAOs choose to run on an existing DAO framework that has been tested and audited. A few examples of DAO frameworks include Aragon and Open Zeppelin Governor. It’s not common for DAOs to write their smart contracts entirely from scratch, unless they have very complex needs and also the technical capacity to build it.

‍

Let’s run through some of the security decisions that DAOs need to consider in relation to the security of their smart contracts:

Bugs and loopholes
Upgrades
Using forked contracts without a team of developers
Access controls
Time: the Lindy effect

Bugs and loopholes

‍

Smart contracts are the open-source, onchain software behind all web3 applications. Threats such as vulnerabilities and bugs within these programs have been exploited in many high-profile hacks over the years. The first major DAO exploit was the case of the the first DAO, which lost $50 million in 2016 via a reentrancy attack on its smart contract that allowed an attacker to make multiple withdrawal requests on the same funds.

‍

Thankfully, after many years of building, testing and auditing, DAO platforms are now much more secure. The magic of composability also means that smart contract components written by one organization are battle-tested in the wild by the rest of the industry. Together, these dynamics have resulted in a solid base layer of code that supports an ecosystem of $13 billion.

‍

That said, the industry can’t afford to be complacent and it is worth underlining just how important formal audits are. The majority of smart contract attack victims had not been audited. Doing so could have prevented the stealing of over $2billion in users’ funds.

‍

Aragon has undergone rigorous audits by Halborn, a well-respected auditing firm in the space.

‍

In addition to formal audits, many web3 organizations run bug bounty programs that reward whitehat hackers (hackers who have the intention of finding bugs rather than exploiting the code for profit) for finding bugs in their code. Aragon has run Code4rena bounties on our new protocol. For more examples, check out the lists on ImmuneFi and HackenProof.

‍

Another way to increase the security of smart contracts is to make them as simple, lean and efficient as possible. Decreasing complexity is a sure way to decrease risk, so we built Aragon OSx to be as simple as possible.

‍

Upgrades

‍

One particular weakness of smart contracts arises because, once onchain, they are immutable. This means that, to upgrade contracts, you need to reroute method calls to new contracts via intermediary contracts called proxies.

‍

Although this essential architecture is unchanged, the process has been standardized by Ethereum Improvement Proposal (EIP) 1822, which introduced the Universal Upgradeable Proxy Standard.

‍

While upgrades and migrations themselves are not explicitly security threats, the bugs and problems that can arise during the migration process can cause lots of problems. If an upgrade is required, doing so with care is essential!

‍

Using forked contracts without a team of developers

‍

“Forking” is a term in open source software when you use another codebase and edit it to make it your own. For example, Sushiswap forked Uniswap’s contracts to create their own decentralized exchange. So, Sushiswap is nearly a clone of Uniswap, just with some changes.

‍

Forking itself is not a security risk, and is actually an important aspect of building open source software. Forking means that developers don’t need to start from scratch every time they want to build something, and the entire industry can move faster by building on top of each other’s work.

‍

But forking DAO frameworks, the contracts that make up a DAO, can create uncertainty and confusion because it means there are multiple versions of the same codebase that you could use. Each version might be maintained by a different group of developers, or the versions could be not maintained at all. The versions could have different documentation and best practices for use. And there could be different teams to reach out to for help. Tackling all of the uncertainty of using forked contracts without a team of experienced Solidity developers can open your DAO up to vulnerabilities.

‍

Choosing to use a forked version of a DAO, such as by copy/pasting the contracts they use, could create security risks. It’s rare to be able to plug-and-play a DAO’s entire codebase if they have a custom build, meaning they built their own contracts rather than using a common DAO framework. There could be bugs and vulnerabilities you’re not aware of, and the lack of documentation could make it easy to make mistakes without realizing it.

‍

It’s best to use a DAO framework that is actively being maintained and updated, rather than piecing together your own contracts by forking code. Unless you are a Solidity developer or have a robust team of developers helping you, creating a custom solution by using forked contracts is typically not the most secure solution.

‍

We built Aragon OSx, our new DAO framework, to be adaptable and modular, so DAOs don’t need to fork the entire framework to build entirely custom organizations. We did this through the use of plugins, which are like apps you install and uninstall on your phone, but for DAO activities like governance, treasury management, membership management, and more. DAOs built on Aragon can have the confidence that they’re built on a framework that has been rigorously audited and is well-maintained with documentation by a team of developers, while still having the flexibility of creating a custom organization by installing and uninstalling plugins. This significantly decreases the security risk for DAOs that want custom builds, because they don’t need to fork the codebase.

‍

Access controls

‍

You also need to be aware of who is authorized to call the functions on a smart contract or alter the contract itself. In other words, who is in charge of the smart contracts behind the scenes that you may or may not be aware of?

‍

Onchain functions are accessible by all by default, but if users have the ability to mint tokens or otherwise provide a route to other users’ funds, then call access must be restricted to authorized addresses in the case of a multisig, or an autonomous smart contract in the case of a DAO.

‍

If access controls are needed, it’s important for them to be managed by trustworthy parties and decentralized carefully. An explorer like pod.xyz can help you uncover onchain permissions like access controls.

‍

Time: the Lindy effect

‍

The Lindy effect is a principle that states that the longer a non-perishable thing, like an idea or a technology, has been around, the longer it will persist. This is because the idea or technology has been battle-tested enough that it is likely to continue to survive.

‍

Smart contracts that have been in use for a longer period of time have accrued more “Lindy” by proving themselves to be resilient to hacks over the years. A smart contract that is ten years old is typically considered safer and more battle-tested than a contract that was deployed one year ago. The more users and the more time, the more safe.

‍

When a DAO framework has been used for a long time without being hacked, it is a strong indicator of the security of that framework.

‍

There is no shortcut for time, but high usage and large amounts of funds stored in the contracts safely without a hack can also increase confidence in security. The more a contract is used and tested, the more confident you can be in the security of the contracts.