原文标题：5 rules for token launches
原文作者：Miles Jennings
Source: a16zcrypto
Compiler: Lynn, Mars Finance
Editor's note: Given the fast-moving nature of the cryptocurrency industry, "how do I launch a token" is one of the most common questions founders ask. As the price rises, FOMO starts to emerge – everyone else is launching tokens, should I? — It's more important for builders to be cautious about tokens. So, in this particular series of articles, we're going to cover launch readiness, risk management strategies, and a framework for assessing operational readiness. Be sure to subscribe to our newsletter to learn more about tokens and other company-building resources.
To an onlooker, the tension between blockchain builders and the U.S. Securities and Exchange Commission (SEC) appears to be overstrained. The SEC believes that almost all tokens should be registered under U.S. securities laws. Builders think it's ridiculous. Despite differences of opinion, the fundamental goal of the SEC and builders is the same – to create a level playing field.
The tension exists because both sides are approaching the same challenge from completely different angles. The securities law seeks to level the playing field for investors by implementing information disclosure requirements designed to eliminate information asymmetries in publicly traded securities. The blockchain system seeks to level the playing field for a wider range of participants (developers, investors, users, etc.) through decentralization, using a transparent ledger, eliminating centralized control, and reducing reliance on stewardship. While builders need to face a wider audience, they also want to eliminate asymmetric information about the system and its native asset, the token.
It's no surprise that regulators are skeptical of the latter approach. This type of decentralization in the corporate world is nothing like it. It holds no regulator accountable, and because decentralization is difficult to establish and measure, it's easy to fake.
For better or worse, web3 builders have a responsibility to prove that the blockchain industry's approach works and is worth considering. While this task would indeed be easier if the SEC were a constructive partner, the industry cannot allow the SEC's failure to become its own. Web3 projects must strive to work within existing guidance, from the SEC's digital asset framework issued in April 2019 to the latest ruling on enforcement actions against Coinbase.
So, where should a project start, and after determining when and how to launch a token, a project can start with the following five token launch rules:
Note: These rules are not intended as a map to circumvent U.S. securities laws. Rather, they are intended to inform projects how to self-manage so that the risks associated with holding their tokens are significantly different from those associated with investing in securities. All of these guidelines depend on the specific facts and circumstances of the project structure and behavior. Discuss with an advisor before executing the plan.
Rule 1: Never sell tokens publicly in the U.S. for fundraising purposes
In 2017, initial coin offerings (ICOs) flourished, with dozens of projects seeking to raise capital by pledging important technological breakthroughs. While many did (including Ethereum), many more did not. At the time, the SEC's response was both forceful and reasonable. The commission sought to apply securities laws to ICOs, as ICOs typically meet all the conditions of the Howie test – a contract, plan, or transaction in which money is invested in an ordinary business with a reasonable expectation of profit based on the expectations of the executives. or someone else's entrepreneurial endeavor.
Nowhere is it easier to apply the Howey test than in primary trading, where a token issuer sells tokens to investors. In many ICOs, token issuers make clear representations and promises to investors that they will use the proceeds from the token sale to fund their operations and provide investors with future returns. These cases are all securities transactions, regardless of whether the instrument sold is a digital asset or a stock. The case is closed.
The industry has evolved since 2017, moving away from fundraising methods based on public token sales in the United States. We are in different times. ICOs are everywhere. Instead, tokens allow holders to manage the network, join games, or build communities.
The application of the Howey test on tokens is now more difficult – airdrops do not involve monetary investment, decentralized projects do not rely on management efforts, many secondary token transactions clearly do not meet Howey's conditions, and there is a lack of public marketing aspects, and secondary buyers are not allowed to rely on the efforts of others to make a profit.
Despite the progress made over the past seven years, ICOs reappear in a new form with each new cycle and appear to be in violation of U.S. securities laws. This can happen for a variety of reasons:
- Some industry participants believe that U.S. securities laws are invalid or unfair, and therefore a violation of securities laws is justified—a convenient ideological stance for anyone who wants to profit from them.
- Some people invent new plans in the hope that a small change in facts will lead to a different outcome. The ones that come to mind are "protocol-owned liquidity" (an indirect token sale by a decentralized autonomous organization or DAO and then controlling the resulting yield through decentralized governance) and "liquidity bootstrap pools" (indirect token sales through a decentralized exchange's liquidity pool).
- Some want to take advantage of the uncertainty created by the SEC's insistence on regulation through enforcement, which has led to a number of inconsistent and irreconcilable rulings (see: Telegram, Ripple, Terraform Labs, and Coinbase).
Projects need to be careful to avoid these scenarios. There is no reason to ignore or violate U.S. securities laws.
The only legal way for projects to avoid applying securities laws to their tokens is to mitigate the risks that these laws are designed to address (e.g., reliance on management efforts and information asymmetry). The public token sale to Americans for fundraising purposes is antithetical to these efforts, which is why regulators have barely focused on crypto issues (and their subtle changes) over the years than fundraising.
The good news is that raising funds by selling tokens publicly in the U.S. can easily avoid legal consequences. People can not do this at all – but there are still other ways to raise money. Public offerings of equity and tokens outside of the U.S., as well as private offerings of equity and tokens, can be conducted in a compliant manner without compliance with the registration requirements of the securities laws.
summary
Selling publicly in the U.S. is a goal of its own. Avoid it at all costs.
Rule number two: Make decentralization the North Star
There are a number of different token issuance strategies that builders can use. They can diversify their projects before they launch, launch outside the United States, or restrict the transferability of their tokens to prevent access to the U.S. secondary market
I've discussed all of this in more detail in this post using the DXR (Decentralized, X-Contain, Limit) token issuance framework, which lays out how each strategy mitigates risk.
If the project has not yet achieved "sufficient decentralization", both X-include and Restrict strategies can help the project comply with U.S. securities laws at launch. But crucially, neither is a substitute for decentralization. Decentralization is the only avenue that projects can take to help eliminate the risks that securities laws are designed to address, making their application unnecessary.
Therefore, regardless of the strategy the project chooses at the beginning, those who intend to use tokens to convey broad rights (economy, governance, etc.) should always have decentralization as their North Star. Other strategies are just stopgaps.
How does this work in practice, and no matter how the project evolves over time, it should always seek to make progress towards a greater degree of decentralization. Some examples:
- The founding team of a Layer 1 blockchain may want to invest a lot of development efforts into several technical milestones after the mainnet launches. To reduce the risks associated with "reliance on stewardship efforts," they could first exclude the US from the launch and then only make their tokens available here once progress has been made in decentralization. These milestones may include making validator sets or smart contract deployments permissionless, increasing the total number of independent builders building on top of the network, or reducing the concentration of token holdings.
- Web3 gaming projects may want to use restricted tokens in the U.S. to incentivize in-game economic activity. Over time, the project may lift restrictions on tokens as more user-generated content is created, more gameplay becomes dependent on independent third parties, or as more independent servers come online.
Planning each step in the decentralization plan is arguably the most important work before the token launch. The strategy chosen for a project will have a significant impact on how it is operated and communicated at launch and in the future.
summary
Decentralization is important. Pursue it in every endeavor.
Rule 3: Communication is everything, manage yourself accordingly
I can't stress it enough: communication, no matter how inconsequential or harmless it may seem, can make or break a project. A single misstatement by the CEO can put the entire project at risk.
Projects should have a strict communication policy based on the nuances of their token issuance strategy. So let's break this down using the strategy in the token issuance framework:
Decentralization
The purpose of this strategy is to ensure that purchasers of the project's tokens do not "generate reasonable profit expectations based on the managerial or entrepreneurial efforts of others" (as described in the Howie test). In a decentralized project, token holders do not expect the management team to bring in profits, as no single group or individual has that power. The founding team must not state otherwise, otherwise securities laws may be involved.
So what is a "reasonable expectation"? It depends a lot on how the project or token issuer talks about (as well as tweets, texts, and emails) tokens. The court has repeatedly found that when a project declares that its core team is driving progress and economic value, it is reasonable for investors to rely on the efforts of that core team to obtain a return on investment. This finding can be used to justify the application of securities laws.
When it comes to decentralization, a strict communication policy isn't a cheap strategy to evade U.S. securities laws – it's a way to legitimately reduce the likelihood that token buyers will rely on management or entrepreneurial efforts for profit, which can help protect web3 projects and their users. The truth is that by refusing to set constructive rules and weaponizing communications against builders, the SEC has created incentives that are diametrically opposed to its own mission. Web3 builders actually tend to disclose fewer projects and activities to the public.
So what does this strategy look like in practice?
First of all, projects should not discuss or reference their own tokens before launching them. This includes potential airdrops, token distributions, or tokenomics. The consequences of doing so could be serious – the SEC has successfully blocked companies from issuing tokens, and they can try again. Don't give them a chance.
Second, after the token issuance, projects should refrain from discussing the price or potential value of the token, or viewing it as an investment opportunity. This includes mentioning any mechanisms that could lead to token appreciation, as well as any commitment to use private capital to continue to fund the development and success of the project. All of these actions increase the likelihood that token holders have a reasonable expectation of profit.
Once the project is decentralized, how members of the project's ecosystem, including founders, development companies, foundations, and DAOs, talk about their roles is crucial. It's easy for founding teams to get caught up in centralized language, even if the project is extremely decentralized, especially when they're used to talking about achievements, milestones, and other releases in the first person.
A few ways to avoid this trap:
- Avoid referring to yourself in a way that inaccurately implies ownership or control of the protocol or DAO (e.g., "as the CEO of the protocol......", "Today, we turned on the X feature of the protocol......").
- Avoid forward-looking statements as much as possible, particularly with respect to mechanisms such as programmatic "burning" of tokens to achieve pricing targets or stability.
- Avoid committing to or guaranteeing work in progress, and avoid treating work in progress as being unduly important to the project ecosystem (e.g., using "initial development team" instead of "core development team" or "main development team" where appropriate, and not referring to individual contributors as "managers").
- Highlight efforts that have facilitated or will facilitate greater decentralization, such as contributions from third-party developers or app operators.
- Give the DAO or Foundation of the project its own voice to avoid confusion with the DevCo or founder who started the project. Better yet: avoid confusing third parties and rename or rebrand the original DevCo so that it doesn't share the name with the protocol.
Ultimately, the content of any communication should reflect the principle of decentralization, especially in public. Communication needs to be open and designed to prevent significant asymmetric information from any individual or group.
For more information on the practical impact of decentralization, see here and here.
summary
Once decentralized, no individual or company is the spokesperson for the project. The project's ecosystem is its own living system, independent and unique. Just one mistake can have catastrophic consequences.
X-contained
When launching outside the U.S., projects can draw inspiration from the world of traditional finance and adopt a rigorous communication policy that follows the requirements of Regulation S, which provides that projects issued outside the U.S. are exempt from certain registration requirements under U.S. securities laws
The goal of the strategy is to prevent tokens from flowing back into the United States, so communication should avoid "targeted sale efforts" to promote or advertise tokens in the United States and risk "regulating the U.S. market" tokens (i.e., creating demand for U.S. tokens). Ultimately, the severity of these policies will depend on whether the token has a "substantial U.S. market interest" (SUSMI) (i.e., a huge U.S. market demand for the token).
summary
If you do not offer tokens in the United States, please do not communicate in the same way that you offer tokens. Any statements you make on social media about the project's tokens should specifically emphasize that these tokens are not available in the United States
limit
Restricting token issuance to transmission-restricted tokens or "off-chain" points allows for more flexible communication policies. A well-thought-out executed project is immune to legal risks because, according to the Howie test, individuals cannot make an "investment of funds" to acquire tokens.
Still, if the project encourages participants to treat their transferred restricted tokens or points as investment products, this segregation could quickly disintegrate. These statements could seriously undermine the legal basis for restricting tokens.
summary
The restriction does not exempt the builder from the legal consequences. Careless statements can haunt a project for years to come, making it never able to change its startup strategy or even be decentralized.
Rule 4: Be cautious about secondary market listings and liquidity
Secondary market listings and liquidity are another area where the incentives generated by the SEC's enforcement regulation run counter to its own mission.
Projects typically seek to build listings on secondary trading platforms so that more people can access their tokens and use them to access blockchain-based products (e.g., you need to own ETH to use the Ethereum blockchain). This usually involves ensuring that there is sufficient liquidity on the trading platform, as this lack of liquidity can lead to price volatility and increase risk to the project and its users. In the early days of a token's launch, a larger purchase or sale on a particular platform can greatly affect the price of the token. When the price falls, everyone loses money. When prices rise, FOMO-driven investors may push prices to unsustainable levels, and when prices stabilize, they may suffer greater losses.
Increasing access and ensuring adequate liquidity (usually through market makers) is better for web3 users. It also helps to make the market fairer, more orderly, and more efficient. Although this is the stated mission of the SEC, it used the project's announcement on the secondary trading platform about the availability of its token against the same project in court. It also tries to treat the liquidity supply in the secondary market as the same as a regular token sale. No good deed will go unpunished.
Projects that did not initially use a decentralized token issuance strategy have more flexibility in terms of secondary market listing and liquidity, as both alternative strategies delay the availability of fully transferable tokens in the United States. The public circulation of their tokens (the number of tokens in circulation) before the tokens were widely used in the United States, reducing the need for token issuers to deal with U.S. secondary market listings and liquidity issues
summary
Projects need to be extremely cautious about these listings and liquidity. Risk/benefit analysis is often not worth it. At the very least, projects that are unsure whether they have achieved "sufficient decentralization" should not publish information about the listing of their tokens on exchanges and may not engage in any market-making activity within the United States
Rule Five: Always keep the token lock-up period for at least one year from the date of token issuance
This is critical. The project shall impose transfer restrictions on all tokens issued to insiders (employees, investors, advisors, partners, etc.), affiliates, and anyone who may be involved in the distribution of tokens. These restrictions shall apply for at least one year from the date of issuance of the tokens.
The SEC successfully took advantage of the absence of a one-year lock-up period to literally prevent token issuers from issuing tokens. It may seek to do so again. To make matters worse, the SEC's precedent provides a roadmap for plaintiff attorneys to file a class action lawsuit against a company that has failed in this regard. It's free money for them, but it's a miserable world for the project.
Ideally, lock-up and other appropriate transfer restrictions should only begin to be released at the end of the one-year period, starting with the token issuance, and linearly from that point to the next three years, for a total lock-up period of four years. This approach can help mitigate the legal risks mentioned above. It can also enable the project to achieve long-term success by reducing downward pressure on the token's price and demonstrating confidence in its long-term viability.
It's a win-win.
Given these obvious benefits, projects should also be wary of investors trying to request a shorter lock-up period. This type of demand may indicate that the investor is not complying with securities laws and may sell the token in the first place.
For projects that issue tokens outside of the United States, any token issuance to U.S. employees, investors, and other insiders should follow this guidance. The team should discuss with counsel whether a broader application of the prohibition is necessary to preserve the exemption under Regulation S.
Finally, anyone who uses transfer-restricted tokens or credits as part of their token issuance strategy should modify this method so that any transfer restrictions are lifted only one year after the date on which the project's tokens are transferable in the United States
Summary:
It is mandatory to apply transfer restrictions for one year from the date of token issuance. Extending the release schedule for at least two or three years after that is good for project insiders, users, and their future. Anyone who holds the opposite view may have questionable intentions.