Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
How to launch a token_ Operational guidelines from creation to custody - a16z crypto.pdf
1. Adina Fischer, Matt Gleason and Justin Simcock
COMPANY BUILDING TOKEN LAUNCH PLAYBOOK
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.
4.25.24 SHARE
How to launch a token: Operational guidelines
from creation to custody
Table of contents
search follow us
2. 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.
#1: Coordinate with custodians
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
search follow us
3. 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.
#2: Conduct security audits
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:
search follow us
4. 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.
#3: Allocate and distribute 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
search follow us
5. 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?
#4: Ensure enforcement of lockups
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.)
search follow us
6. 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?
#5: Enable staking and governance
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.)
search follow us
7. 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
search follow us
8. 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.
newsletter: web3 weekly
A newsletter from a16z crypto, and your go-to guide to the next internet
Enter email address Subscribe
search follow us