Launching a token is a big decision. Leading up to the token launch, there are many elements to consider, from initial distribution, to capping the supply, to providing liquidity, to choosing token standards. And many of them are irreversible.
We’ve talked to many projects of all sizes and stages. Too often, the decisions made when a token is launched become a blocker for governance and decentralization efforts down the road. Projects that launch without considering the governance compatibility of their token are left with less-than-ideal workarounds in their governance stack.
We don’t want this to happen to you, so we created a guide to help you navigate technical standards when launching your token. If you plan to decentralize and governance is a priority, there are contract standards you’ll want to take into consideration.
Whether you integrate governance into your token contracts or opt for external contracts that add governance functionality to your token, we want you to help you make an informed decision.
First, we’ll help you navigate building a basic token:
.png)
ERC20 is the most common token standard. For most projects, this is a good place to start and often the best option.
The base ERC20 token includes the ERC20Permit standard, which enables token holders to approve token transfers using a digital signature, bypassing the need for a transaction. This signature is made offchain and includes permissions that are verified and executed onchain, simplifying approvals and saving transaction costs.
One of the most important decisions you’ll need to make is whether your token supply is capped, or whether you can continue to mint tokens after launch.
Most will choose to cap the token supply. Capping your token supply is a security measure often demanded by token holders, as well as required by exchanges. If you want to cap the token supply, adding the ERC20Capped extension is a clean and simple way to do it. Without this extension, you can mint all of the tokens at launch and remove the minting function or access controls in your token contract. But this approach can be a bit more messy and cumbersome to execute.
Otherwise, you can include the mint functionality in your contract so you can continue to mint tokens after launch. But you’ll need to carefully manage access control to the mint function, as whoever has permission to mint tokens can increase the supply and dilute the token’s value.
You’ll also want to think through whether your token is upgradeable or not. Upgradeable tokens add complexity and potential attack vectors compared to non-upgradeable tokens. Token holders tend to trust non-upgradable tokens, as they are more predictable.
If your token is upgradeable, the UUPSUpgradeable extension will be best in most cases. It’s crucial to ensure that the upgrade process is secure, transparent, and well-defined, with proper access control. Upgrading a token contract can have serious consequences for token holders, so you will want to consider having proper safeguards in place.
Access control is an important aspect of your token contract’s security, determining who can interact with the contract's functionalities. These include minting, burning, or freezing tokens. If you include the function to mint tokens or upgrade your token contracts, you need to carefully manage access control.
Access control can be granted based on ownership, roles, or attributes. To start, you’ll likely want to assign the appropriate roles in your token contract to the right stakeholders. When you’re ready, you can also give full ownership of the token contract to your token holders, via a token-based DAO.
Your token contract will specify the clock mode it uses: block numbers or timestamps. The vast majority of tokens use block numbers and unless you have very good reason to do otherwise, yours should too. Block-based clocks are more secure, as they are tied to the immutability of the blockchain. It also ensures compatibility with your governance contracts and interface.
It’s important to know that the ERC20 standard is missing critical functionalities that limit its compatibility with onchain governance. 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.
.png)
There are many ERC20 extensions that introduce different functionalities and tradeoffs: from saving gas, to improving security, to increasing useability. One functionality you can add is governance, and the main standard is ERC20Votes.
If you don’t add governance standards to your token contract, your users will need to interact with external contracts, adding additional steps and friction. If governance isn’t high on your priority list, that may not be a problem. However, it is an important tradeoff to consider, as it can drastically effect voter participation and power dynamics. If governance is important to you now or down the road, strongly consider adding the standards below directly in your token contract.
ERC20Votes is the main standard used by projects who need onchain governance. It adds both snapshotting and delegation functionality to your token. Many projects now include delegation as a non-negotiable in their governance plans. If that is your case, 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 additional standards. The extension can be very useful for integrating with other applications. It’s a best practice that makes the ecosystem more interoperable. We highly recommend including ERC165 in your governance token, it’s a minor addition that will make it easier for your token to interact with governance tooling.
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 standards, there are external contracts that can make your token compatible with onchain governance.
Rather than integrating ERC20Votes in your token contract, you can use an ERC20Wrapper to add governance functionality. Essentially, you just add ERC20Votes to an ERC20Wrapper.
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 forgo 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.
If you have protocols and assets deployed across chains, you may want to consider adding a multichain extension to your token. These extensions facilitate transactions across chains, including governance. You can add multichain functionality in your token contract or in a token wrapper.
One example is the Omnichain Fungible Token (OFT) standard by LayerZero, which allows tokens to be transferred across multiple blockchains without asset wrapping or middle chains. The OFT standard has become popular recently as multichain deployments continue to grow. We incorporated the OFT standard in our multichain governance plugin, to give your standard ERC20 token governance functionality across chains.
There are several tools to launch a governance token. We recommend the following:
When you launch a token, you may not need to decentralize your governance overnight. But thinking about governance compatibility ahead of time can save you major headaches down the road. If you have any doubts, don’t hesitate to reach out to our team. We can help you navigate the tradeoffs and evaluate custom solutions to meet your needs.
-
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}
.png)
