a16z: 5 Guidelines You Must Know Before Issuing Tokens

Original Title: 5 rules for token launches

Original Author: Miles Jennings, a16zcrypto

Original Compilation: Lynn, MarsBit

Editor's Note: Given the fast-paced nature of the cryptocurrency industry, "How do I launch a token?" is one of the most common questions founders ask. As prices rise, FOMO begins to set in—everyone else is launching tokens, should I?—it becomes even more important for builders to approach tokens with caution. Therefore, in this special series of articles, we will introduce frameworks for launch preparation, risk management strategies, and assessing operational readiness. Be sure to subscribe to our newsletter for more information on tokens and other resources for building companies.

To onlookers, the tension between blockchain builders and the U.S. Securities and Exchange Commission (SEC) seems overly strained. The SEC believes that almost all tokens should be registered under U.S. securities laws. Builders find this absurd. Despite the disagreement, the fundamental goals of the SEC and builders are aligned—to create a fair competitive environment.

The tension exists because both sides are addressing the same challenge from completely different perspectives. Securities laws aim to provide a fair competitive environment for investors by implementing disclosure requirements designed to eliminate information asymmetry about companies trading publicly. Blockchain systems seek to provide a fair competitive environment for a broader range of participants (developers, investors, users, etc.) through decentralization, using transparent ledgers to eliminate centralized control and reduce reliance on management efforts. While builders need to reach a wider audience, they also want to eliminate information asymmetry regarding the systems and their native assets, tokens.

It is not surprising that regulators are skeptical of the latter approach. This type of decentralization has no parallel in the corporate world. It leaves regulators without a party to hold accountable; moreover, because decentralization is difficult to establish and measure, it is easy to fake.

For better or worse, web3 builders have a responsibility to prove that the blockchain industry's approach is effective and worth considering. While it would certainly be easier if the SEC were a constructive partner, the industry cannot allow the SEC's failures to become its own. Web3 projects must strive to operate within the existing guidance, from the digital asset framework released by the SEC in April 2019 to the latest rulings regarding enforcement actions against Coinbase.

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

Note: These rules are not intended as a roadmap for evading U.S. securities laws. Rather, their purpose is to inform projects on 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’s structure and conduct. Discuss with advisors before executing plans.

Rule 1: Never sell tokens to the public in the U.S. for fundraising purposes

In 2017, Initial Coin Offerings (ICOs) flourished, with dozens of projects promising significant technological breakthroughs seeking to raise funds. While many did (including Ethereum), 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 typically met all the conditions of the Howey test—a contract, scheme, or transaction in which funds are invested in a common enterprise with a reasonable expectation of profits derived from the efforts of others.

Nowhere is it easier to apply the Howey test than in primary transactions (i.e., when token issuers sell tokens to investors). In many ICOs, token issuers made explicit statements and promises to investors that they would use the proceeds from the token sale to fund their operations and provide returns to investors in the future. These cases are all securities transactions, regardless of whether the instruments sold are digital assets or stocks. Case closed.

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

The application of the Howey test to tokens has now become more complicated—airdrops do not involve monetary investment, decentralized projects do not rely on managerial efforts, many secondary token trades clearly do not meet Howey's criteria, and the lack of public marketing means secondary purchasers do not rely on the efforts of others to profit.

Despite progress over the past seven years, ICOs reappear in new forms with each new cycle, seemingly in violation of U.S. securities laws. There are several reasons for this:

• Some industry participants believe that U.S. securities laws are ineffective or unfair, making it reasonable to violate them—a convenient ideological stance for anyone looking to profit.
• Some invent new schemes, hoping that minor changes in facts will lead to different outcomes. Examples include "protocol-owned liquidity" (indirect token sales conducted by decentralized autonomous organizations or DAOs, with the resulting proceeds controlled through decentralized governance) and "liquidity bootstrapping pools" (indirect token sales through liquidity pools on decentralized exchanges).
• Some hope to exploit the uncertainty brought about by the SEC's insistence on regulating through enforcement, leading to many inconsistent and irreconcilable rulings (see: Telegram, Ripple, Terraform Labs, and Coinbase).

Projects need to be careful to avoid these schemes. There is no justification for ignoring or violating U.S. securities laws.

The only legitimate way for a project to avoid applying securities laws to its tokens is to mitigate the risks that these laws are designed to address (e.g., reliance on managerial efforts and information asymmetry). Selling tokens to the public in the U.S. for fundraising purposes is at odds with these efforts, which is why regulators have focused almost exclusively on fundraising as the crypto issue of concern over the years (and its subtle variations).

The good news is that it is relatively easy to avoid legal consequences when publicly selling tokens in the U.S. One can simply not do it—yet still raise funds through other means. Public offerings of equity and tokens outside the U.S., as well as private placements of equity and tokens, can be conducted in a compliant manner without adhering to the registration requirements of securities laws.

Summary:

Public sales in the U.S. are a goal unto themselves. Avoid at all costs.

Rule 2: Let decentralization be your North Star

Builders can employ various token issuance strategies. They can decentralize their projects before launch, launch outside the U.S., or restrict the transferability of their tokens to prevent access to the U.S. secondary market.

I discuss all of this in more detail in this article using the DXR (Decentralized, X-include, Restrict) token issuance framework, which outlines how each strategy reduces risk.

If the project has not achieved "sufficient decentralization," both the X-include and Restrict strategies can help the project comply with U.S. securities laws at launch. But it is crucial that neither can replace decentralization. Decentralization is the only path a project can take to help eliminate the risks that securities laws are designed to address, making their application unnecessary.

Therefore, regardless of which strategy a project initially chooses, those intending to use tokens to convey broad rights (economic, governance, etc.) should always keep decentralization as their North Star. Other strategies are merely stopgap measures.

How does this work in practice? Regardless of how the 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 wish to focus significant development efforts on several technical milestones after the mainnet launch. To mitigate risks associated with "reliance on managerial efforts," they might first exclude the U.S. from the launch and only offer their tokens there after achieving progress in decentralization. These milestones could include making the validator set or smart contract deployment permissionless, increasing the total number of independent builders building on the network, or reducing the concentration of token holdings.

• A web3 gaming project may wish to use restricted tokens in the U.S. to incentivize in-game economic activity. Over time, as more user-generated content is created, more gameplay becomes reliant on independent third parties, or more independent servers come online, the project may lift restrictions on the tokens.

Planning every step of the decentralization process can arguably be the most important work before token issuance. The strategy chosen by the project will have significant implications for how it operates and communicates at launch and in the future.

Summary:

Decentralization is important. Pursue it in every effort.

Rule 3: Communication is everything; manage yourself accordingly

I cannot emphasize enough: communication, no matter how trivial or harmless it may seem, can make or break a project. A single erroneous statement from a CEO can put the entire project at risk.

Projects should develop strict communication policies based on the nuances of their token issuance strategies. So, let’s break this down using the strategies from the token issuance framework:

Decentralization

The goal of this strategy is to ensure that buyers of the project’s tokens do not have a "reasonable expectation of profits to be derived from the efforts of others" (as described in the Howey test). In decentralized projects, token holders should not expect the management team to generate profits, as no single group or individual has that power. The founding team must not imply otherwise, or they may run afoul of securities laws.

So, what constitutes a "reasonable expectation"? This largely depends on how the project or token issuer discusses (and tweets, texts, and emails about) 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 that core team's efforts for returns on their investments. This finding can be used to justify the applicability of securities laws.

In terms of decentralization, a strict communication policy is not a cheap strategy to evade U.S. securities laws—it is a legitimate way to reduce the likelihood that token purchasers will rely on managerial or entrepreneurial efforts to profit, which helps protect web3 projects and their users. The fact is, by refusing to establish constructive rules and weaponizing communication against builders, the SEC has created incentives that are diametrically opposed to its own mission. Web3 builders are, in fact, inclined to disclose less about projects and activities to the public.

So, what would this strategy look like in practice?

First, projects should not discuss or reference their own tokens before launching them. This includes potential airdrops, token allocations, or token economics. The consequences of doing so can be severe—the SEC has successfully prevented companies from issuing tokens, and they may try again. Do not give them the opportunity.

Second, after the token issuance, projects should avoid discussing the price or potential value of the token, or treating it as an investment opportunity. This includes mentioning any mechanisms that could lead to token appreciation, as well as any commitments to continue funding the project’s development and success with private capital. All of these actions increase the likelihood that token holders will have a reasonable expectation of profits.

After decentralization, how members of the project ecosystem (including founders, development companies, foundations, and DAOs) discuss their roles is crucial. Founding teams can easily fall into centralized language, even if the project is extremely decentralized, especially when they are accustomed to discussing achievements, milestones, and other releases in the first person.

Here are several ways to avoid this trap:

• Avoid mentioning oneself in a way that inaccurately implies ownership or control over the protocol or DAO (e.g., "As the CEO of the protocol…," "Today, we launched feature X of the protocol…").

• Avoid forward-looking statements, especially regarding mechanisms that "burn" tokens for pricing targets or stability.

• Avoid commitments or guarantees about ongoing work, and refrain from treating ongoing work as overly significant to the project ecosystem (e.g., use "initial development team" instead of "core development team" or "lead development team" where appropriate, and do not refer to individual contributors as "managers").

• Emphasize efforts that have facilitated or will facilitate greater decentralization, such as contributions from third-party developers or application operators.

• Provide a voice for the project’s DAO or foundation to avoid confusion with the DevCo or founders that launched the project. Better yet: avoid confusing third parties and rename or rebrand the original DevCo so that it does not share a name with the protocol.

Ultimately, what anyone communicates should reflect the principles of decentralization, especially in public settings. Communication needs to be open and aimed at preventing any individual or group from creating significant information asymmetry.

For more information on the practical implications 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. A single mistake can lead to catastrophic consequences.

X-include

When launching outside the U.S., projects can draw inspiration from the traditional financial world and adopt strict communication policies that comply with Regulation S, which allows projects issued outside the U.S. to be exempt 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 communication should avoid "targeted sales efforts" promoting or marketing the tokens in the U.S., risking "regulating the U.S. market" for the tokens (i.e., creating demand for the tokens in the U.S.). Ultimately, the strictness of these policies will depend on whether there is "substantial U.S. market interest" (SUSMI) (i.e., significant market demand for the tokens in the U.S.).

Summary:

If you are not offering tokens in the U.S., do not communicate as if you are offering tokens. Any statements you make on social media about the project’s tokens should specifically emphasize that these tokens are not available in the U.S.

Restrict

Limiting token issuance to restricted transfer tokens or "off-chain" points can allow for more flexible communication policies. Thoughtfully executed projects can shield themselves from legal risks, as individuals cannot make a "monetary investment" to acquire tokens under the Howey test.

However, if a project encourages participants to view its restricted tokens or points as investment products, this separation may quickly unravel. Such statements could severely undermine the legal basis for restricting the tokens.

Summary:

Restrictions do not absolve builders of legal consequences. Careless statements may haunt a project for years to come, making it impossible to change launch strategies or even achieve decentralization.

Rule 4: Exercise caution 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 establish listings on secondary trading platforms so that more people can access their tokens and use them to access blockchain-based products (for example, you need to own ETH to use the Ethereum blockchain). This typically involves ensuring sufficient liquidity on trading platforms; a lack of liquidity can lead to price volatility and increase risks for the project and its users. Why? In the early stages of token launches, larger buys or sells on specific platforms can significantly impact token prices. When prices fall, 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 sufficient liquidity (often through market makers) is better for web3 users. It also helps make markets fairer, more orderly, and more efficient. While this is the SEC's established mission, it has used announcements made by projects about the availability of their tokens on secondary trading platforms to counter the same projects in court. It has also attempted to treat liquidity supply on secondary markets as equivalent to ordinary token sales. No good deed goes unpunished.

Projects that initially did not use decentralized token issuance strategies have greater flexibility regarding secondary market listings and liquidity, as both alternative strategies delay the time at which fully transferable tokens can be offered in the U.S. Before tokens are widely used in the U.S., the public circulation of their tokens (the number of tokens in circulation) can reduce the need for token issuers to address secondary market listings and liquidity issues in the U.S.

Summary:

Projects need to treat these listings and liquidity with extreme caution. Risk/reward analyses are often not worth it. At the very least, projects that are uncertain whether they have achieved "sufficient decentralization" should not publish information about their tokens being listed on exchanges and may not engage in any market-making activities within the U.S.

Rule 5: Always impose a lock-up period of 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 token distribution. These restrictions should apply for at least one year from the date of token issuance.

The SEC has successfully leveraged the absence of a one-year lock-up period to literally prevent token issuers from issuing tokens. It may seek to do so again. Worse, the SEC's precedents provide plaintiff lawyers with a roadmap for filing class-action lawsuits against companies that fail in this regard. This is free money for them, but a painful world for projects.

Ideally, lock-ups and other appropriate transfer restrictions should only begin to release at the end of the one-year period, starting from the token issuance, and should linearly release over the next three years, resulting in a total lock-up period of four years. This approach can help mitigate the legal risks mentioned above. It can also lead to long-term success for projects by reducing downward pressure on token prices and signaling confidence in their long-term viability.

It's a win-win.

Given these obvious benefits, projects should also be wary of investors attempting to demand shorter lock-up periods. Such demands may indicate that investors are not complying with securities laws and may sell tokens at the first opportunity.

For projects issuing tokens outside the U.S., any tokens issued to U.S. employees, investors, and other insiders should follow this guideline. Teams should discuss with lawyers whether it is necessary to apply the lock-up more broadly to retain the exemptions provided by Regulation S.

Finally, anyone using transfer-restricted tokens or points as part of their token issuance strategy should modify this approach so that any transfer restrictions are lifted only one year after the project’s tokens become transferable in the U.S.

Summary:

Applying transfer restrictions for one year from the date of token issuance is mandatory. Extending the release schedule for at least two to three years thereafter benefits project insiders, users, and their futures. Anyone holding an opposing view may have questionable intentions.