.png)
A16z wrote a helpful token launch playbook outlining the legal, commercial, and operational risks for projects launching a token. When it comes to risk mitigation, all roads lead to decentralization. There are many measures projects have taken to avoid legal and regulatory risk, from creating legal entities to geoblocking jurisdictions. However, none of them are a substitute for decentralizing your project.
“Launching decentralized systems that stand the test of time is incredibly difficult, but it’s why most of us are working in web3. We can choose to see these challenges as a path to regulatory purgatory, or we can reframe them as opportunities for thoughtful innovation, and treat them as a set of constraints for designing better systems.” - How to navigate token launch risks
Miles Jennings, a16z
When launching a token, there are many decisions to make and factors to consider. Governance is often overlooked or kicked down the road, but it is key to achieving decentralization goals and ultimately designing better systems. These systems also need to take into account the new risks that decentralization introduce, such as operational and security risks. Planning ahead can help smooth out the bumps in the road.
We’ve listed some technical considerations for your governance stack, in a way that will help support your decentralization efforts not and into the future.
In order to decentralize, it’s critical to distribute control over some decisions to token holders. In order to give token holders control, they need to make and execute decisions onchain. Ideally, without the interference of trusted intermediaries. Many projects have settled for offchain signaling votes, followed by execution with a trusted multisig. In these cases, the multisig takes on the responsibility of executing transactions and likely the risk of these actions and their corresponding outcomes.
If you go through the hard work of decentralizing certain decisions to mitigate your risk exposure, be careful not to undercut your efforts with the technical capabilities and setup of your governance stack. Although there may be legal workarounds, it’s important to understand the limitations and implications of offchain signaling votes. If decentralization is important for you, plan to minimize trust with onchain execution. There are ways to do this that keep your protocol and assets secure.
Not all tokens are made equal. When it comes to governance tokens, the devil is in the details.
Launching a token is an irreversible decision. Failing to consider your governance needs when you launch your token can quickly become limiting and problematic. If decentralization is important to you, you’ll want to consider token standards and tradeoffs in advance of your launch.
For tokens to compute and execute votes onchain, you need to plan for additional functionalities in your token or in your governance stack. Otherwise, the votes cannot be computed and executed onchain. If decentralization and onchain governance is a priority, you’ll want to consider adding critical extensions, such as ERC20Votes.
You may have other priorities for your token, and want to keep your token contract as lean as possible. In that case, there are workarounds you can implement in your governance stack, such as using a token wrapper or locker that give tokens governance functionality.
ERC20 is the most common token standard. For most projects, this is a good place to start and often the best option.
It’s important to know that the ERC20 standard is missing critical functionalities that limit its compatibility with onchain governance.
ERC20Votes is the main standard used by projects that need onchain governance. It adds both snapshotting and delegation functionality to your token.
In order to compute votes onchain, your token needs snapshotting functionality. A snapshot allows a smart contract to calculate voting power at a precise moment in time. Without snapshotting functionality, voting power can change while a proposal is live, making it impossible to calculate vote results.
Many projects now include delegation as a non-negotiable in their governance plans. If delegation is non-negotiable for you, you’ll want to integrate ERC20Votes.
ERC165 is an extension that allows for callers of your token (ex. dApps) to verify that your token matches the standards above. It’s an optional feature that can be very useful for integrating with other applications. It’s a best practice that makes the ecosystem more interoperable.
Depending on the intended use of your token, you may want to avoid adding extensions to your token contract in order to keep it as lean as possible, or you may need to prioritize other extensions and functionalities. If you are set on ERC20 without any governance functionality, there are external contracts that can make your token compatible with onchain governance.
Token holders can “wrap” their ERC20 tokens to get the same functionality as ERCVotes. When they “wrap” their tokens, they receive non-transferable and governance-compatible tokens in return.
This unfortunately creates friction and opportunity costs for your token holders. By wrapping tokens, they might need to forego other activities, like using the token in DeFi.
It’s also important to note that your governance parameters will be based on the wrapped supply, rather than the total supply. In addition, tokens must be wrapped before the snapshot begins, otherwise they can’t vote. In the case of malicious or emergency proposals, this can be a dangerous dynamic. You’ll want enough time between a proposal and start of the voting period (ie. snapshot), as more tokens may need to be wrapped.
Locking mechanisms are another way to add governance functionality to ERC20 tokens.
veTokens can address the opportunity costs of wrapping for token holders, by incorporating incentives to the locking mechanism. veToken contracts require token holders to lock their tokens for a certain period of time in exchange for increased voting power and other benefits, such as increased yield on the tokens they LP in the protocol. Users who lock their tokens in the veToken contract receive non transferable "vote-escrowed" (ve) tokens that represent their voting power. The longer you lock, the more voting power you receive. Curve pioneered veTokens back in 2020, and built their DAO on the Aragon legacy stack. Learn about their governance model here.
If you simply want your token holders to participate in governance without the additional incentives, you can add a LocktoVote function to your DAO contracts. In this case, token holders need to lock their tokens for the voting period of the proposal in order to vote.
The key difference is that tokens can be locked at any time during the voting period, they do not need to be locked before the voting period begins and the snapshot is taken. It can be a more secure setup for emergency situations.
For more detailed step-by-step instructions, see our guide to Navigating Token Standards for Onchain Governance.
“(...) projects don’t need to be “fully decentralized” or even “substantially decentralized” across all of these categories to be “sufficiently decentralized.” (...) Greater decentralization in some categories means that projects can be less decentralized in others.”
- Getting ready to launch a token: What you need to know, Miles Jennings and Jason Rosenthal, a16z
Giving token holders control over certain decisions helps mitigate against certain risks, such as censorship and regulatory uncertainty. However, decentralization adds complexity and opens up other risk vectors.
Giving complete control over every aspect of a project to token holders, whether they delegate their voting power or not, can throw projects into chaos. This is normally what people mean by “DAOs don’t work”, but it doesn’t need to be that way.
Most web3 projects include different legal entities and disjointed bodies representing different groups of stakeholders. These groups of stakeholders play different roles, and that’s part of decentralization, too. Having different stakeholders own different types of decisions moves the needle on decentralization, allows you to be effective, and avoids the chaos that comes with broad stroke one-token-one-vote governance.
In order to give different stakeholders groups different roles in your governance, your stack should support multi-body and multi-process customization.
Multi-body capabilities allow you to give different groups control over different decisions. This can include a mix of token holders, multisigs, subDAOs, and other creative ways to build a voting census (such as whitelisting addresses based on different conditions).
A popular example of this is “Optimistic Dual Governance”, where a multisig or allowlisted wallets are given permission to propose and execute decisions more efficiently, and token holders are given ultimate control with veto power over those decisions.
It’s likely that your project makes different types of decisions regarding different types of assets. Not all proposals are the same, and different types of proposals could benefit from different processes.
Choosing different stages, approval thresholds, and time delays can help you create processes that are more specific to the decisions you need to make. By working with different variables along the decision-making process, you can make decisions in a way that reflects the complexity of decentralized organizations.
In addition, having the ability to run many different processes in parallel leads to more effective decision-making in complex decentralized projects.
Not only is it helpful for your governance stack to support multiple bodies and processes to make decisions, granular permission management can make operations more secure. Access control is at the heart of onchain governance and is key to making decentralized decision-making more effective and secure. You can implement safeguards by limiting actions with thresholds, such as the amount of funds to be withdrawn or the range within which parameters can be adjusted.
When you limit specific actions with a limited scope, you can give token holders more control and fine tune your governance to the unique needs of your project at every stage.
You may also want to execute actions and grant permissions across chains. A robust permission management system can manage and execute actions across chains.
The complex and evolving structure of web3 projects requires ongoing flexibility. New teams, legal entities, and communities are created over time. People come and go. Your governance plans should account for these inevitable changes. Investing in a trustless and decentralized governance setup allows for dynamic organizations, while keeping your protocol and assets safe.
Building a robust and resilient decentralized system takes time. There is no way around it. Projects need a long-term plan to account for different stages along the journey.
Additionally, in web3 we’re building early-stage technology that has yet to find product-market fit and reach mass adoption. Most projects will need to continuously pivot as the technology and market continues to evolve.
In this context, you want to consider how your governance can evolve. As your protocol and assets grow in value, they become riskier to move. Be careful not to get locked into a governance model that is extremely difficult to change. This can open up enormous security risks, not to mention high costs.
A governance stack that is easier to customize and adapt can lead to safer changes down the road. Sovereignty and immutability is key to security. It’s critical that the right stakeholders, likely token holders, own your governance contracts. Considering the inevitability of change and evolution in governance, it may also be wise to plan for how changes can be made, if needed. Namely, you’ll want to consider how token holders can participate in approving these changes via your governance process.
Security is always paramount when building onchain, particularly when you are managing valuable assets such as a protocol or treasury. There is a wide range of considerations when it comes to the security of your governance stack.
The first is the track record of the builder and their tools. The track record of a project, team, and protocol should be one of the leading considerations when choosing your stack.
The next are rigorous and ongoing audits. Code should be audited by reputable auditors. Public and open audits with significant bounties are also a good thing to look for. Be aware that projects often change their smart contracts over time, and with each major change and upgrade, there should be an audit.
Finally, there are other considerations when looking more deeply into the codebase. Although a particular set of smart contracts may have the track record of securing a large amount of assets over time, forking its code can come with vulnerabilities. The contracts may be outdated, after having been forked multiple times and made difficult to track. These codebases might not be actively maintained, leaving you on your own to deploy and troubleshoot. In addition, these codebases require deep and rare expertise. Make sure you have developers on hand in case of emergencies. Choosing a clean and actively maintained codebase can go a long way for your project’s security.
Governance protocols, platforms, and tools are disjointed across web3. This has been a predicament for many DAOs, creating friction, frustration, and overwhelm for token holders. Having a consolidated UI for your governance can improve participation and transparency.
Some projects will also require more resilience and censorship-resistance. It’s important to think about this across the stack. Smart contracts are sovereign deployments, most UIs are not. Depending on the needs of your project, you may need to consider either the decentralization of your front end architecture and/or self-hosting it, to ensure your DAO members can access your DAO easily no matter where in the world they’re located.
Finally, when it comes to the wide range of risk mitigation strategies, it’s helpful for UIs to be made flexible enough to integrate compliance requirements where needed. This said, these can vary widely and shouldn’t be imposed across the board (ie. some projects may strategically choose to KYC as part of their risk mitigation strategy, while others will choose geoblocking high risk jurisdictions).
Launching a token may be overwhelming, but it’s an important milestone for your project, creates exciting opportunities for your community, and is a step towards advancing decentralization in our industry. While launching a token can require a lot of planning, there are tons of tools and examples at your disposal to build the best token for your unique needs. Decentralization is a journey, and it doesn’t need to happen overnight. This guide is here to help you make better informed technical decisions up front, and prevent costly headaches later down the road.
When thinking about risk and making decisions about your project’s structure, you’ll always need legal advice that is specific to you. Share this companion guide with your lawyer to make sure they understand the technology underpinning your decentralization efforts.
We’re here to help. Reach out to explore a custom build for your project and get support from our team. We can also connect you to our network of industry experts, including web3-native lawyers who understand DAOs and onchain governance.
-
Aragon has been building onchain governance infrastructure for over 7 years, with its tech securing billions of assets. Govern your protocol onchain with Aragon OSx: the secure and modular DAO framework with customization built in. Or, launch a DAO in 10 minutes or less without writing any code on the Aragon App.
Developer Portal | Aragon App | Custom DAO Builds | Mirror | X | Newsletter
.png){kind=icon}
