Written by: Miles Jennings, General Counsel and Head of Decentralization at a16z Crypto
Editor: Karen, Foresight News
Editor’s Note: “How do I launch a token?” is one of the most common questions we receive from founders. Given the rapid evolution of the cryptocurrency industry, FOMO is spreading as prices rise. Everyone else is launching tokens, should I do it too? But for builders, it’s even more important to be cautious about token launches. In this post we’ll explore the preparations before launching a token, risk management strategies, and an operational readiness assessment framework.
To an outside observer, the tension between Blockchain Builders and the U.S. Securities and Exchange Commission (SEC) may appear overblown. The SEC believes that almost every token should be registered under U.S. securities laws, while Builders believe this is ridiculous. Despite this difference of opinion, the fundamental goal of the SEC and Builders is the same, namely, to create a level playing field.
This tension exists because both parties are on completely different sides of the fence. Securities laws create a level playing field for investors by applying disclosure requirements designed to eliminate information asymmetry, which applies to companies that publicly issue securities. Blockchain systems, on the other hand, create a level playing field for a wider range of participants (developers, investors, users, etc.) through decentralization, using transparent ledgers, eliminating centralized control, and reducing reliance on administrative work. Although Builders need to reach a wider audience, they also want to eliminate information asymmetry about the system and its native asset (token).
It’s not surprising that regulators are skeptical of the latter approach. This type of decentralization has no precedent in the corporate world, it leaves regulators with no single party to hold accountable, and because decentralization is difficult to establish and measure, it can be easily falsified.
For better or worse, the onus is on Web3 Builders to prove that the blockchain industry’s approach is viable. From the SEC’s Digital Asset Framework, released in April 2019, to its recent ruling on the Coinbase enforcement action, we must realize that Web3 projects must attempt to work within the guidance provided by the SEC.
After deciding when and how to issue tokens, projects can follow these five rules for issuing tokens:
Note: These rules are not intended to circumvent U.S. securities laws. All of these guidelines depend on the specific facts and circumstances of your project structure and conduct. Please discuss your plans with legal counsel before implementing them.
Guideline 1: Do not sell tokens publicly in the U.S. for fundraising purposes
In 2017, there was a boom in initial coin offerings (ICOs), with dozens of projects promising important technological breakthroughs and seeking to raise funds. While many projects did achieve their goals (including Ethereum), many more did not.
At the time, the SEC’s response was both forceful and reasonable. The SEC sought to apply securities laws to ICOs, which often met all of the conditions of the Howey Test—a contract, plan, or transaction that included the investment of funds in a common enterprise with a reasonable expectation of profit based on the managerial or entrepreneurial efforts of others.
The Howey test applies more easily than in any other context involving a principal transaction, where the token issuer sells tokens to investors. In many ICOs, the token issuer clearly represents and promises to investors that they will use the proceeds from the token sale to fund operations and provide potential returns to investors. These situations are securities transactions, regardless of whether the instrument being sold is a digital asset or a stock.
Since 2017, the industry has moved away from fundraising methods based on public token sales in the United States. We have entered a different era. ICOs are no longer a thing. Instead, tokens allow holders to govern networks, participate in games, or build communities.
Now, applying the Howey test to tokens is much more difficult — airdrops don’t involve capital investment, decentralized projects don’t rely on management work, many secondary token transactions clearly don’t meet Howey’s conditions, and without public marketing, secondary buyers may not be dependent on the efforts of others to make a profit.
Despite the progress made over the past seven years, ICOs re-emerge in new forms with each new cycle. Project owners seem to ignore U.S. securities laws for several reasons:
1. Some industry participants believe that U.S. securities laws are invalid or unfair, so violating securities laws is justified and a convenient ideological position for anyone who can profit from it. 2. Some people have devised new schemes, arguing that minor factual changes can lead to different results. For example, "protocol-owned liquidity" (indirect sales of tokens through decentralized autonomous organizations or DAOs, and then controlling the proceeds through decentralized governance) and "liquidity bootstrapping pools" (indirect sales of tokens through liquidity pools on decentralized exchanges). 3. Some people hope to take advantage of the uncertainty caused by the SEC's insistence on regulation through enforcement, which has led to some inconsistent and irreconcilable rulings (see: Telegram, Ripple, Terraform Labs, and Coinbase).
Projects need to be careful to avoid these schemes or plans. None of these are sufficient grounds to ignore or violate U.S. securities laws. The only legal way for projects to do so is to mitigate the risks these laws are designed to address. Selling tokens publicly to Americans to raise funds runs counter to these efforts, which is one of the reasons why regulators have paid the most attention to the crypto space in years.
The good news is that there are still other ways to raise capital. Public sales of equity and tokens outside the United States and private sales of equity and tokens can be conducted in a compliant manner without the registration requirements of the securities laws.
Summary: Public sales in the United States are a mistake that affects your own interests and should be avoided at all costs.
Principle 2: Pursue decentralization
Builders can use a number of different token issuance strategies. They can decentralize their projects before they launch, launch them outside of the U.S., or restrict the transferability of their tokens to prevent a secondary market in the U.S.
I discuss these issues in detail in this post, using the DXR (Decentralize, X-clude, Restrict) token issuance framework, which describes how each strategy can mitigate risk.
If a project has not yet achieved sufficient decentralization at the time of issuance, both X-clude and Restrict strategies can help the project comply with U.S. securities laws. However, it should be clear that neither strategy is a substitute for decentralization. Decentralization is the only path a project can take to help eliminate the risks that securities laws are designed to address.
Therefore, no matter which strategy a project initially chooses, projects that intend to use tokens to convey broad rights (economic, governance, etc.) should always keep decentralization as their "North Star". Other strategies are just stopgap measures.
How does this work in practice? Regardless of how a project evolves over time, it should always strive to make progress toward greater decentralization. Here are some examples:
1. The founding team of a Layer1 blockchain may want to invest a lot of development work to achieve several technical milestones after the mainnet is launched. To reduce the risk of "dependency management", they can first exclude the United States and then offer tokens here after achieving decentralization progress. These milestones may include making the verification node set or smart contract deployment permissionless, increasing the total number of independent Builders built on the network, or reducing the concentration of token holdings.
2. A Web3 gaming project may wish to use restricted tokens in the United States to incentivize in-game economic activity. As user-generated content increases, gameplay becomes more dependent on independent third parties, or more independent servers come online, the project may gradually lift token restrictions.
Planning each process in your decentralization plan is arguably the most important work before launching a token. The strategy a project chooses will have a significant impact on how it operates and communicates at launch and in the future.
Summary: Decentralization is important, pursue decentralization in every attempt.
Principle 3: Communication is crucial
Once again, no matter how insignificant the communication may seem, it can make all the difference in a project. One wrong comment from a CEO can put the entire project at risk.
Projects should develop strict communication policies based on the nuances of their token launch strategy. Let’s explain this using the strategies in the token launch framework:
Decentralization
The goal of this strategy is to ensure that purchasers of a project’s tokens do not have a “reasonable expectation of profiting from the managerial or entrepreneurial efforts of others” (as stated in the Howey test).
In a decentralized project, token holders will not expect the management team to bring profits because no single team or individual has that power. The founding team may not imply otherwise, otherwise it will involve securities laws.
So what is a “reasonable expectation”? This largely depends on how the project or token issuer talks about the token (including tweets, texts, and emails). Courts have repeatedly ruled that when a project announces that a core team is driving progress and economic value, investors reasonably rely on the efforts of the core team for a return on their investment. This finding can be used to prove the application of securities laws.
In terms of decentralization, a strict communication policy is not a cheap tactic to evade U.S. securities laws, but rather a way to legally reduce the likelihood that token purchasers will become dependent on management or entrepreneurial efforts for profits, thereby protecting Web3 projects and their users.
So what would this strategy look like in practice?
First, projects should not discuss or mention their tokens before they are launched. This includes potential airdrops, token distributions, or token economics. The consequences of doing so could be severe — the SEC has successfully stopped companies from launching tokens before, and they may try to do so again. Don’t give them the chance.
Second, after the token is issued, projects should avoid discussing the price or potential value of the token or framing it as an investment opportunity. This includes mentioning any mechanisms that could cause the token to appreciate in value, as well as any promises 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 may be perceived as having a legitimate expectation of profit.
How project ecosystem members (including founding teams, development companies, foundations, and DAOs) talk about their roles after a project is decentralized is very important. It’s easy for founding teams to fall into language that frames things as centralized, even if the project is extremely decentralized, especially when they are used to talking about achievements, milestones, and other initial rollouts in the first person.
A few ways to avoid this trap:
1. Avoid statements that inaccurately imply ownership or control of the protocol or DAO (e.g., “As the CEO of the protocol…”, “Today, we turned on feature X of the protocol…”).
2. Avoid forward-looking statements as much as possible, especially with respect to mechanisms such as programmatic destruction of tokens to achieve pricing targets or stability.
3. Avoid promises or guarantees of ongoing effort, and avoid referring to such effort as having undue importance to the project ecosystem (e.g., use “initial development team” instead of “core development team” or “main development team” where appropriate, and don’t refer to individual contributors as “managers”).
4. Highlight efforts that have promoted or will promote greater decentralization, such as contributions from third-party developers or application operators.
5. To avoid confusion with the DevCo or founder who started the project, give the project’s DAO and foundation an independent voice. A better way is to avoid confusing third parties and rename or reshape the original DevCo so that it does not share a name with the protocol.
Most importantly, any communication should reflect the principles of decentralization, especially in a public setting. Communication needs to be open and designed to prevent any individual or group from generating significant asymmetric information.
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 an independent and different living system. Just one mistake can have catastrophic consequences.
X-clude
When launching outside the U.S., projects can take inspiration from the world of traditional finance and adopt strict communications policies that comply with Regulation S. This regulation exempts projects that issue products outside the U.S. from certain registration requirements under U.S. securities laws.
The goal of this strategy is to prevent tokens from flowing back to the U.S., so communications should avoid “targeted sales efforts” in the U.S. to promote tokens. Ultimately, the stringency of these policies will depend on whether there is “substantial market interest” (SUSMI) in the U.S., meaning whether there is significant market demand for the token in the U.S.
Bottom line: If you are not offering tokens in the U.S., don’t communicate as if you are offering tokens. Any statements you make on social media about your project’s tokens should specifically highlight that these tokens are not available in the U.S.
Restrict
Limiting token issuance to restricted transfer tokens or off-chain credits can allow for more flexible communication policies. Well-thought-out projects will not face legal risks because individuals cannot make a “capital investment” to acquire tokens under the Howey test.
However, if a project encourages participants to view restricted transfer tokens or credits as investment products, these statements could seriously undermine the legal basis for restricted tokens.
Summary: Restrictions do not protect Builders from legal consequences. Improper representations can haunt a project for years to come, preventing it from changing its issuance strategy or even decentralizing.
Guideline 4: Be cautious with secondary market listing and liquidity
Projects often want to list on secondary exchanges so that more people can acquire their tokens and use them to access blockchain-based products (e.g., you need to own ETH to use the Ethereum blockchain). This often involves ensuring there is enough liquidity on the exchange; insufficient liquidity can lead to price volatility and increased risk for both the project and its users. Why is this the case?
In the early stages of a token launch, a large purchase or sale on a particular platform can significantly drive the price of a token. When the price drops, everyone loses money. When the price rises, FOMO-driven investors may push the price higher and face greater risk after the price stabilizes.
Increasing accessibility and ensuring there is enough liquidity (usually through market makers) is better for Web3 users, and it also helps make markets more fair, orderly, and efficient.
Despite this being the SEC’s stated mission, it has used announcements made by projects about the availability of their tokens on secondary trading platforms to bring cases against these projects. It has also sought to treat the provision of liquidity on secondary markets the same as regular token sales.
Projects that do not initially use a decentralized token issuance strategy have greater flexibility in terms of secondary market listing and liquidity, as both alternative strategies would delay the time to offer a fully transferable token in the United States.
Summary: Projects need to be extremely cautious when dealing with these listing and liquidity issues. Risks and rewards are usually not equal. At the very least, projects that are not sure whether they have achieved "sufficient decentralization" should not post about listing their tokens on exchanges, and probably should not conduct any market making activities in the United States.
Principle 5: Tokens must be locked for at least one year after TGE
This is critical. Projects should impose transfer restrictions on all tokens issued to insiders (employees, investors, advisors, partners, etc.), affiliates, and anyone who may participate in the token distribution. Tokens should be locked up for at least one year from the date of issuance.
The SEC has successfully used the lack of a one-year lockup period to prevent token issuers from issuing tokens. It may seek to do so again. Worse, this SEC precedent allows plaintiffs’ lawyers to help these companies file class-action lawsuits, which is free money for them, of course, but endless pain for the projects.
Ideally, tokens should be locked up (or subject to other appropriate transfer restrictions) for at least one year before vesting, and vest linearly over the next three years from that point in time, for a total lock-up period of four years.
This practice can help mitigate the legal risks mentioned above, and can also position the project for long-term success by reducing downward price pressure on the token and demonstrating confidence in its long-term viability. It’s a win-win situation.
Projects should also be wary of investors who attempt to request a shorter lockup period. Such a request could indicate that the investor is not paying enough attention to securities laws and may want to sell the tokens in the first place.
For projects that issue tokens outside the U.S., any tokens issued to U.S. employees, investors, and other insiders should follow this guidance. Teams should discuss with their legal counsel whether a more extensive lockup is necessary to preserve exemptions under Regulation S.
Summary: Enforce transfer restrictions for one year from the token issuance date. Extending the issuance schedule to at least two to three years beyond that date is beneficial to project insiders, users, and the future. Anyone who argues otherwise probably has questionable intentions.
As we mentioned throughout this article, every token launch is different, but there are some guidelines that apply to most projects. Avoiding public fundraising, developing a decentralization plan, implementing strict communication guidelines, carefully considering secondary markets, and locking tokens for at least one year can help projects avoid the most common token launch pitfalls. Not only that, adhering to these general guidelines can also help Builders consolidate legitimacy and security innovation and drive industry progress.
