Original title: 5 rules for token launches

Original author: Miles Jennings, a16zcrypto

Original translation: Lynn, MarsBit

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 from founders. As prices rise, FOMO sets in — everyone else is launching tokens, should I? — it's even more important for builders to be cautious with their tokens. So in this special series of articles, we'll cover launch preparations, 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 the onlooker, the tension between blockchain builders and the U.S. Securities and Exchange Commission (SEC) seems overwrought. The SEC argues that nearly all tokens should be registered under U.S. securities laws. Builders think that's ridiculous. Despite the differences in opinion, the SEC and builders share the same fundamental goal — to create a level playing field.

The tension exists because both sides approach the same challenge from completely different angles. Securities laws seek to level the playing field for investors by imposing disclosure requirements designed to eliminate information asymmetries about companies with publicly traded securities. Blockchain systems seek to level the playing field for a wider range of participants (developers, investors, users, etc.) through decentralization, which uses a transparent ledger, eliminates centralized control, and reduces reliance on administrative work. While builders need to address 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 has no analogue in the corporate world. It leaves regulators with no one 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 works and is worthy of consideration. 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 failure. Web3 projects must strive to work within existing guidance, from the SEC’s Digital Asset Framework published in April 2019 to the recent ruling in the enforcement action against Coinbase.

So where should projects start? After determining when and how to launch a token, projects can begin with these five token launch rules:

Note:These rules are not intended to serve as a map for circumventing U.S. securities laws. Rather, they are intended to inform projects on how to govern themselves so that the risks associated with holding their tokens differ significantly from the risks associated with investing in securities. All of these guidelines depend on the specific facts and circumstances of a project’s structure and conduct. Discuss your plan with your advisors before executing it.

Rule One: Never Publicly Sell Tokens in the United States for Fundraising Purposes

In 2017, initial coin offerings (ICOs) were booming, with dozens of projects promising important technological breakthroughs seeking to raise funds. While many did so (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 because ICOs generally meet all the conditions of the Howey test—a contract, scheme, or transaction in which money is invested in a common enterprise with a reasonable expectation of profits based on the management or entrepreneurial efforts of others.

Nowhere is the Howey test more easily applied than in primary transactions, where token issuers sell tokens to investors. In many ICOs, token issuers make clear representations and promises to investors that they will use the proceeds of token sales to fund their operations and provide future returns to investors. These cases are securities transactions, regardless of whether the instrument sold is a digital asset or stock. Case closed.

The industry has evolved since 2017, moving away from fundraising methods based on public token sales in the United States. We are in a different era. ICOs are everywhere. Instead, tokens allow holders to govern networks, join games, or build communities.

The application of the Howey test to tokens is now more difficult — airdrops do not involve monetary investment, decentralized projects do not rely on management effort, many secondary token transactions clearly do not satisfy Howey’s conditions, and lacking the public marketing aspect, secondary purchasers must not rely on the efforts of others to make a profit.

Despite the progress made over the past seven years, ICOs reappear in new forms with each new cycle and appear to violate U.S. securities laws. This occurs for a variety of reasons:

· Some industry participants believe that U.S. securities laws are ineffective or unfair, and therefore violating securities laws is justified — a convenient ideological position for anyone who wants to profit from it.

· Some invent new schemes in the hope that a slight change in the facts will lead to a different outcome. I’m thinking of “protocol-owned liquidity” (indirect token sales by a decentralized autonomous organization, or DAO, which then controls the resulting proceeds through decentralized governance) and “liquidity bootstrapping pools” (indirect token sales through liquidity pools on decentralized exchanges).

· Some hope to exploit 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 schemes. There is no good reason to ignore or violate U.S. securities laws.

The only legal way for projects to avoid the application of securities laws to their tokens is to mitigate the risks those laws are designed to address (e.g., reliance on management effort and information asymmetry). Publicizing token sales to U.S. persons for the purpose of fundraising is antithetical to these efforts, which is why regulators have had few crypto issues (and their slight variations) more focused on over the years than fundraising.

The good news is that it’s easy to avoid legal consequences by raising money by selling tokens publicly in the US. One can simply not do it — and still raise money in other ways. Public sales of equity and tokens outside the US, as well as 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 US are a goal unto themselves. Avoid them at all costs.

Rule Two: Make Decentralization Your North Star

Builders can use a number of different token launch strategies. They can decentralize their project before launch, launch outside the US, or restrict the transferability of their tokens to prevent access to US secondary markets

I discuss all of this in more detail in this post using the DXR (Decentralized, X-Contained, Restricted) Token Launch Framework, which lays out how each strategy mitigates risk.

Both X-include and Restrict strategies can help projects comply with U.S. securities laws at launch if they are not yet “sufficiently decentralized.” But crucially, neither is a substitute for decentralization. Decentralization is the only path a project can take that can help eliminate the risks that securities laws are designed to address, thereby making their application unnecessary.

Therefore, no matter which strategy a project chooses at the outset, those who 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 seek to make progress toward greater decentralization. Some examples:

· The founding team of a layer 1 blockchain may want to invest a significant amount of development effort into a few technical milestones after the mainnet launches. To reduce the risks associated with “dependency on governance efforts,” they could initially exclude the U.S. from launch, and then only make their tokens available here once they have made progress toward decentralization. These milestones might include making the validator set or smart contract deployment permissionless, increasing the total number of independent builders building on top of the network, or reducing the concentration of token holdings.

· A Web3 gaming project might want to use a restricted token in the U.S. to incentivize in-game economic activity. Over time, as more user-generated content is created, more gameplay becomes dependent on independent third parties, or as more independent servers come online, the project might lift restrictions on the token.

Planning each step in the decentralization plan is arguably the most important work before a token launch. The strategy a project chooses will have a significant impact on how it operates and communicates both at launch and in the future.

Summary:

Decentralization is important. Pursue it in every endeavor.

Rule Three: Communication is Everything, Manage Yourself Accordingly

I cannot stress this enough: communications, no matter how inconsequential or innocuous they may seem, can make or break a project.One false statement from the CEO can put the entire project at risk.

Projects should have strict communication policies in place depending on the nuances of their token issuance strategy. So let’s break this down using the strategies from the Token Issuance Framework:

Decentralization

The purpose of this strategy is to ensure that purchasers of a project’s tokens do not “have a reasonable expectation of profits based on the managerial or entrepreneurial efforts of others” (as described in the Howey Test). In a decentralized project, token holders do not expect the management team to generate profits because no single group or individual has that power. The founding team may not state otherwise, or securities laws may be implicated.

So what is a "reasonable expectation"? This depends largely on how the project or token issuer talks about (and tweets, texts, and emails) the token. Courts have repeatedly found that when a project announces that its core team is driving progress and economic value, it is reasonable for investors to rely on the efforts of that core team for a return on their investment. This finding can be used to justify the application of securities laws.

On the decentralization side, a strict communications policy is not a cheap tactic to evade U.S. securities laws — it is a way to legally reduce the likelihood that token purchasers will be dependent on management or entrepreneurial efforts for profits, which helps protect web3 projects and their users. The fact is that by refusing to enact 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 less of their projects and activities to the public.

So what would this policy look like in practice?

First, projects should not discuss or reference their own tokens before launching them. This includes potential airdrops, token distributions, or token economics. The consequences of doing so can be severe — the SEC has successfully stopped companies from launching tokens, and they can try again. Don’t give them the chance.

Second, after a token is launched, projects should avoid discussing the price or potential value of the token, or posing it as an investment opportunity. This includes mentioning any mechanisms that could lead to appreciation of the token value; and any commitment to use private capital to continue to fund the project’s development and success. All of these actions increase the likelihood that token holders have a reasonable expectation of profit.

Once a project is decentralized, how members of the project’s ecosystem (including founders, development companies, foundations, and DAOs) talk about their roles is critical. It’s easy for founding teams to fall into the language of centralization, even when the project is extremely decentralized, especially when they are accustomed to talking about achievements, milestones, and other releases in the first person.

A few ways to avoid this trap:

· Avoid referring to yourself in ways that inaccurately imply ownership or control over the protocol or DAO (e.g., “As the CEO of the protocol…”, “Today, we turned on feature X of the protocol…”).

· Avoid forward-looking statements whenever possible, especially with regard to mechanisms like programmatic “burning” of tokens to achieve pricing targets or stability.

· Avoid promises or guarantees about work in progress, and avoid treating work in progress as having undue importance to the project’s 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”).

· Highlight efforts that have promoted or will promote greater decentralization, such as contributions from third-party developers or application operators.

· Give the project’s DAO or foundation its own say to avoid confusion with the DevCo or founders who started the project. Even better: avoid confusing third parties, and rename or rebrand the original DevCo so that it doesn’t share a name with the protocol.

Ultimately, anything anyone communicates should reflect the principles of decentralization, especially in public. Communication needs to be open and designed to prevent any individual or group from generating significant asymmetric information.

For more information on the practical impacts of decentralization, see here and here.

Summary:

Once decentralized, no single individual or company is the face of the project anymore. The project’s ecosystem is its own living system, independent and unique. Just one mistake can have disastrous consequences.

X-INCLUSION

When launching outside of the US, projects can take a cue from the world of traditional finance and adopt a strict communications policy that follows the requirements of Regulation S, which provides that projects offering outside of the US can be exempt from certain registration requirements under US securities laws

The goal of this strategy is to prevent tokens from returning to the US, so communications should avoid "directed sales efforts" that promote or advertise tokens in the US and risk "regulating the US market" for tokens (i.e., creating demand for tokens in the US). Ultimately, the stringency of these policies will depend on whether there is "substantial US market interest" (SUSMI) for the token (i.e., significant market demand for the token in the US).

Summary:

If you are not offering tokens in the US, do not communicate in a way that suggests 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.

Restrictions

Restricting token issuance to transfer restricted tokens or “off-chain” points allows for a more flexible communications policy. Thoughtfully executed projects can be insulated from legal risk because individuals cannot make a “funding investment” to acquire tokens under the Howey test.

Nevertheless, this insulation can quickly fall apart if a project encourages participants to treat their transfer restricted tokens or points as an investment product. These statements could seriously undermine the legal rationale for restricting tokens.

Summary:

Restrictions do not exempt builders from legal consequences. Careless statements can haunt a project for years to come, preventing it from ever changing its launch strategy or even decentralizing.

Rule Four: Be Careful with Secondary Market Listings and Liquidity

Secondary market listings and liquidity are another area where the incentives created by the SEC’s enforcement oversight run counter to its own mission.

Projects often 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 often involves ensuring there is enough liquidity on the trading platform; a lack of liquidity can lead to price volatility and increase risk for the project and its users. Why? In the early days of a token launch, larger buys or sales on a particular platform can dramatically affect the token’s price. When the price drops, everyone loses money. When the price rises, FOMO-driven investors may push the price to unsustainable levels, and when the price stabilizes, they may suffer even greater losses.

Increasing access and ensuring there is adequate liquidity (usually through market makers) is better for web3 users. 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 on secondary trading platforms about the availability of their tokens to fight the same projects in court. It has also attempted to treat the provision of liquidity on secondary markets as the same as regular token sales. No good deed goes unpunished.

Projects that did not initially use a decentralized token issuance strategy have more flexibility with secondary market listings and liquidity, as both alternative strategies delay the time to offer fully transferable tokens in the U.S. The public float (number of tokens in circulation) of their tokens before the tokens are widely used in the U.S., thereby reducing the need for token issuers to deal with U.S. secondary market listing and liquidity issues

Summary:

Projects need to approach these listings and liquidity with extreme caution. The risk/benefit analysis is generally not worth it. At a minimum, projects that are unsure whether they have achieved "sufficient decentralization" should not announce that their tokens are listed on exchanges, and probably should not engage in any market-making activities within the U.S.

Rule Five: Always keep token lockups at least one year from the date of token issuance

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. These restrictions should apply for at least one year from the date of token issuance.

The SEC successfully used the absence of a one-year lockup period to literally stop token issuers from issuing tokens. It may seek to do so again. Worse, the SEC precedent provides plaintiffs’ lawyers with a roadmap for class-action lawsuits against companies that fail in this regard. It’s free money for them, but a world of pain for the project.

Ideally, lockups and other appropriate transfer restrictions should only begin to release at the end of a one-year period, starting with the token issuance, and release linearly from that point to the next three years, for a total lockup period of four years. This approach can help mitigate the legal risks noted above. It can also position a project for long-term success by reducing downward pressure on the token price and demonstrating confidence in its long-term viability.

It’s a win-win.

Given these clear benefits, projects should also be wary of investors who attempt to demand a shorter lockup period. This type of demand could indicate that the investor is not abiding by securities laws and may be tempted to sell the tokens in the first place.

For projects that issue tokens outside of the United States, any tokens issued to U.S. employees, investors, and other insiders should follow this guidance. Teams should discuss with counsel whether a broader application of the lock-up is necessary to preserve the exemptions provided by Regulation S.

Finally, anyone using transfer-restricted tokens or credits as part of their token launch strategy should modify this approach so that any transfer restrictions are not lifted until one year after the project’s tokens become transferable in the United States.

Summary:

Applying transfer restrictions within one year of the date of token launch is mandatory. Extending the launch timeline by at least two or three years beyond that is good for project insiders, users, and its future. Anyone who argues otherwise may have questionable intentions.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia