Operational guidelines for token launches, from creation to custody

Editor’s note: “How can I launch a token” is one of the most common questions we get from founders, given the rapidly evolving nature of the crypto industry. As prices rise, and FOMO sets in — everyone else is launching a token, should I? — it’s even more important for builders to approach tokens with caution and care. So in this special series of posts, we cover getting ready for launch, strategies for managing risk, and a few more rules and guidelines for tokens. Be sure to sign up for our newsletter for more on tokens and other company building resources.

When you want to launch a token, there are several steps you need to think about from an operational perspective. This applies even more so if you’re working with any stakeholders who are regulated by the U.S. Securities and Exchange Commission (SEC). The purpose of this post is to lay out the logistics required to establish a protocol, ensure its security, and enable SEC-regulated entities to satisfy compliance requirements.

The first thing to know when launching a token is that it takes time and teamwork. The process involves several types of stakeholders — protocol developers, third party custodians, staking providers, investors, employees, and others — all of whom must be on the same page when preparing for the creation and custody of a new digital asset. Therefore, it is imperative to understand and allocate enough time for every step of the process. 

Please note that the set of guidelines that follows represents a snapshot in time. As the market changes, new products arrive, and the regulatory environment develops, best practices are likely to evolve. In the meantime, these guidelines can be a helpful resource for protocol developers to consider when preparing for a token launch. 

For regulatory reasons, certain stakeholders may not be in a position to take custody of a token until it is supported by a third-party custodian that meets certain requirements, including being registered with a state or federal authority and subject to supervision and examination, engaged in safeguarding crypto assets as a regular substantial part of its business, and subject to regular financial, operational, and security reporting and auditing.

It’s important to note that all custodians are not created equally. If your protocol has large investors involved in helping to secure the network with either staking or governance upon launch, it is imperative to work with a high quality third-party custodian months in advance so they can build out support. If you’re unsure about the standards for quality, ask your investors to clarify their needs. Do not assume that any custodian will be equipped to handle your tokens from the start. Plan accordingly.

Start conversations early. High quality custodians can take around six-to-nine months or longer to support new layer 1 blockchains (L1s). Protocols with more complexity — such as ones that use SNARKs, have privacy features, or that interact with layer 2 (L2) networks — can lengthen the process. Meanwhile, tokens built on Ethereum, such as ERC-20s and NFTs, or ones built on Solana, such as Solana Program Library (SPL) tokens, are more straightforward and can take less time, say three-to-five months, assuming no hitches. Please note that these timelines are just rough estimates and can vary widely depending on the demands on custodians. 

If your protocol entails staking and governance on day one, expect the build-out to take even more time. Alert partners as early as possible. (See guideline five for more on enabling staking and governance.) Also factor in that stakeholders will need to conduct due diligence on any custodians, staking providers, or other third party vendors, including assessing their information security (infosec) and operational security practices. 

To reduce the likelihood of issues during or after the token launch, all code you’ve written related to the token should be thoroughly reviewed. This typically takes the form of a code audit, performed either in parts throughout the development of a project or all at once at the end of development. Audits should be performed by a reviewer with experience reviewing similar products with some focus on the potential for code misuse or software security.

Selection of auditors is a non-trivial task as there are currently no governing bodies certifying auditors. As such, it is your responsibility to perform due diligence to ensure the auditor is sufficiently qualified. When reviewing an audit company’s qualifications, you should ask yourself the following questions:

1. Does the auditor have a well defined testing methodology that can be provided to potential customers?
2. Does the methodology address the main concerns of the protocol being reviewed?
3. Does the methodology include the use of industry standard techniques and tooling for detection of software vulnerabilities?
4. Does the auditor have experience reviewing projects similar to the protocol being reviewed?
5. Has the auditor been involved with a project that suffered a high-profile security breach after the auditor’s review? If so, was the error or flaw exploited part of the code reviewed by the auditor?

The answers to these questions should clarify if the auditor is prepared and capable of performing reviews of your protocol in a manner sufficient to detect and resolve errors prior to the software being launched.

After commissioning the audit and receiving the initial report from the auditor, you are expected to resolve all severe issues (issues of high or critical severity, and often ones of medium severity as well) and to selectively resolve less pressing, lower-severity issues. For any issues you’ve chosen not to resolve, you should provide reasoning. Once you’ve addressed the issues in the initial report, task the auditor with verifying the completeness of the remediation efforts.

Upon successfully verifying the resolution of reported issues, a final report should be created and either published publicly alongside the protocol source code or be made available to all parties receiving or handling the tokens.

After creating a timeline in coordination with high quality custodians and other stakeholders and conducting security audits, it’s time to start thinking about allocating and delivering tokens.

Protocol developers can allocate tokens in one of two ways: either before or after the token launch (also called the token generation event). Many stakeholders prefer to receive allocations prior to launch. In other words, they prefer to have their wallet addresses embedded in the genesis block, the first block on a blockchain, at the time of its creation. This is by no means a requirement though. Tokens allocated post-launch can be delivered to stakeholders in tranches, wherein each tranche amounts to a percentage of the total token supply. 

When it is time to distribute tokens keep in mind where you are sending tokens, how many wallets you are distributing to, and trust but verify addresses. SEC-regulated stakeholders such as RIAs will likely require tokens to be delivered directly to their custodians. Stakeholders should have the option to have as many wallets as they like. This enables them to minimize the concentration of tokens in any given wallet and thereby spread their risk and is due in part to insurance policies, including per-wallet or per-account maximums. Before distributing tokens, always send test transactions and verify receipt as this can reduce the possibility of errors in delivery. 

In summary, protocol developers should ask themselves:

1. When will stakeholders receive assets (e.g., pre- or post-launch)? 
2. Where will stakeholders ask for tokens to be sent and how many wallets will each stakeholder request? 
3. Will stakeholders receive all tokens at once or in tranches? 

Token lockups are one of the best mechanisms for demonstrating conviction in the long-term success of a project and for aligning the interests of stakeholders over the long-term. This can be determined at various time periods, potentially far in advance of other token considerations; for example, in seed rounds when token warrants are signed.

A best practice is for all insiders (employees, investors, advisors, partners, etc.), to be subject to the same token vesting and lockup periods. If any insiders have different lockup periods, or if the enforcement of these lockups is unclear, then that may inadvertently create unpredictable incentives and some insiders may try to sell tokens preemptively. This can create mistrust about the protocol and otherwise negatively impact it. Everyone involved should be operating on a similar timeline, and that timeline should orient everyone toward the project’s long-term success. (Note that these considerations should not preclude users from using the token in a blockchain network or app even if that usage comes sooner than lockups may otherwise permit.)

Once you decide on the vesting and lockup periods (which should not be less than one year from token launch), you can choose to have tokens distributed either by a third party custodian, programmatically, or both. Many  stakeholders will seek, ideally, to have a custodian receive the tokens and enforce the lockups and vesting schedule from both a legal and technical standpoint. Other options include claiming tokens in accordance with a vesting schedule via audited smart contracts or other third party token vesting tools.

The key questions to ask at this stage:

1. Are all stakeholders subject to the same lockup and vesting periods?
2. Can the custodian(s) enforce terms for lockups? 
3. How will unlocked tokens be distributed per the vesting schedule?

As mentioned in the first guideline, if you need stakeholders to participate in staking and governance to secure your protocol, then you may need to coordinate with custodians ahead of time. Protocol developers should not assume that custodians will support staking and governance for their tokens by default. Custodians need time — often months — to build out staking and governance support.

Here’s a list of questions you may want to ask yourself if your protocol relies on stakeholders for staking or governance.

Staking questions:

• Will the custodian allow arbitrary delegation to staking providers or will the custodian have a preselected group of providers? (It may be helpful to work with staking providers that explored the protocol and provided feedback in the testnet phase.)
• If the custodian has preselected a group of staking providers how will this affect the security of the network and decentralization efforts of the protocol? (Choosing a variety of staking providers that have validators globally can help decentralize the protocol.) 
• Do rewards compound or will stakeholders need to restake? (Ideally, the rewards are automatically – rather than manually – restaked.)
• Is there a minimum/maximum amount to be staked per wallet? 
• Are there token minimums/maximums for validator nodes, and will this change over time? 

Governance questions:

• If you are expecting your stakeholders to participate in governance, is the custodian going to enable this participation technically or will it execute votes on stakeholders’ behalf? 
• Will there be onchain or off-chain (e.g., via Snapshot) voting for the protocol? 

—

To recap, if you’re preparing to launch a token and if that plan includes SEC-regulated stakeholders, make sure to leave enough time for high quality custodians to build out support for your protocol. Expect the development time frame to vary by custodian and to depend on the complexity of the protocol. The build-out can range anywhere from three-to-five months for more standard tokens, like Ethereum ERC-20s or Solana SPLs, to nine months for new blockchains, or even longer for tokens involving SNARKs, privacy features, or interactions with layer 2 (L2) networks. Start conversations early.

After establishing realistic timelines, prepare for the next steps. You can allocate tokens either by embedding wallets in the genesis block pre-launch, or by doling out tokens in tranches post-launch. Either way, all stakeholders should be subject to the same token lockup periods and vesting schedules to ensure alignment. Get in any necessary audits and security assessments. And finally, work through the staking and governance details of your protocol, which custodians and other stakeholders will need to know and prepare for to help ensure its security.

If you follow these steps, you’ll have a good handle on the logistics required for a successful token launch. 

***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.