a16z: Five principles for avoiding token issuance “pitfalls”

Author: Miles Jennings, General Counsel and Head of Decentralization, a16z Crypto; Translated by Karen, Foresight News

Editor's Note: "How to issue a token?" is one of the most common questions we receive from founders. Given the rapid evolution of the cryptocurrency industry, FOMO sentiment spreads as prices rise. Others are issuing tokens, should I do it too? But for Builders, it is more important to be cautious about token issuance. In this article, we will explore the preparations before token issuance, risk management strategies, and operational readiness assessment frameworks.

To the outside observer, the tension between Blockchain Builders and the U.S. Securities and Exchange Commission (SEC) may seem exaggerated. The SEC believes that almost every token should be registered under U.S. securities laws, while Builders believes this is ridiculous. Despite this disagreement, the fundamental goal of the SEC and Builders is the same, that is, to create a level playing field.

This tension exists because both sides are on completely different sides. 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, which uses a transparent ledger, eliminates centralized control, and reduces reliance on management work. Although Builders need to target a wider audience, they also want to eliminate information asymmetry about the system and its native assets (tokens).

It is not surprising that regulators are skeptical of the latter approach. This kind of decentralization has no precedent in the corporate world, it leaves regulators with no party to hold accountable; and, because decentralization is difficult to establish and measure, it can be easily faked.

For better or worse, the onus is on Web3 Builders to prove that the blockchain industry's approach is viable. From the SEC’s April 2019 release of its Digital Asset Framework to its recent ruling on Coinbase’s enforcement action, we must be aware that Web3 projects must attempt to work within the guidance provided by the SEC.

After determining when and how to issue a token, projects can follow these five rules for issuing tokens:

Note: These rules are not intended as a way to circumvent U.S. securities laws. All of these guidelines depend on the specific facts and circumstances of your project’s structure and conduct. Discuss your plans with legal counsel before executing them.

Guideline 1: 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 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 has attempted to apply securities laws to ICOs, which often meet all the conditions of the Howey Test—a contract, scheme, or transaction that includes 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 primary transaction, where a token issuer sells tokens to investors. In many ICOs, token issuers make it clear and promise to investors that they will use the proceeds of the token sale to fund operations and provide potential returns to investors. These situations are securities transactions regardless of whether the vehicle sold is a digital asset or stock.

Since 2017, the industry has moved away from fundraising based on public token sales in the United States. We have entered a different era. ICOs no longer exist. Instead, tokens allow holders to manage networks, participate in games, or build communities.

It is much more difficult to apply the Howey test to tokens now - airdrops do not involve capital investment, decentralized projects do not rely on management work, many secondary token transactions clearly do not meet Howey's conditions, and without public marketing, secondary buyers may not rely on the efforts of others to make a profit.

Despite the great progress made in the past seven years, ICOs reappear in new forms in each new cycle. Project parties seem to ignore US securities laws for several reasons:

1. Some industry participants believe that US securities laws are invalid or unfair, so violating securities laws is justified and a convenient ideological position for anyone who can make a profit. 2. Some people have designed new schemes, believing that minor factual changes can lead to different results. For example, "protocol-owned liquidity" (indirectly selling tokens through decentralized autonomous organizations or DAOs, and then controlling the proceeds through decentralized governance) and "liquidity bootstrapping pools" (indirectly selling 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).

Project parties need to be careful to avoid these schemes or plans. These are not enough to justify ignoring or violating US securities laws. The only legal way for projects is to mitigate the risks that these laws are designed to address. Publicly selling tokens to Americans to raise funds runs counter to these efforts, which is one of the reasons why regulators have paid the most attention in the crypto field in many years.

The good news is that people can still raise funds in other ways. 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 complying with the registration requirements of the securities laws.

Summary: Public sales in the United States are a wrong move that affects their 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 outside of the United States, or restrict the transferability of their tokens to prevent a secondary market in the United States.

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.

Both the X-clude and Restrict strategies can help projects comply with U.S. securities laws if they have not yet achieved sufficient decentralization at the time of issuance. However, to be clear, 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 the project initially chooses, projects that intend to use tokens to convey broad rights (economic, governance, etc.) should always use decentralization as their "North Star". Other strategies are just stopgap measures.

How does this work in practice? No matter how the project develops over time, it should always strive to make progress towards 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 goes live. To reduce the risk of "dependency management", they can exclude the United States first, and then offer tokens here after achieving decentralization progress. These milestones may include making the validation 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 game project may want to use restricted tokens in the United States to incentivize economic activities within the game. As more user-generated content grows, gameplay becomes more dependent on independent third parties, or more independent servers come online, the project may gradually lift the restrictions on the token.

Planning each process in the decentralization plan is arguably the most important work before the token launch. 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

I emphasize again that no matter how insignificant the communication content may seem, it may play a critical role in the project. One wrong statement from a CEO can put the entire project at risk.

Projects should have a strict communication policy based on the nuances of their token launch strategy. Let’s use the strategy from the token issuance framework to explain this:

Decentralization

The goal of this strategy is to ensure that purchasers of a project’s tokens do not have a “reasonable expectation of profit from the management or entrepreneurial efforts of others” (as described in the Howey test).

In a decentralized project, token holders will not expect the management team to generate profits because no single team or individual has that power. The founding team may not imply otherwise, or securities laws will be implicated.

So what is a “reasonable expectation”? This depends largely 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 the 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 justify the application of securities laws.

In terms of decentralization, a strict communication policy is not a cheap ploy to evade U.S. securities laws, but rather a way to legally reduce the likelihood that token purchasers will be 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 prior to the token launch. 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 before, and they may try to do so again. Don’t give them the chance.

Second, after the token launch, 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 project’s development and success. All of these actions increase the likelihood that token holders may be perceived as having a legitimate expectation of profit.

After a project is decentralized, how project ecosystem members (including founding teams, development companies, foundations, and DAOs) talk about their roles is very important. It is 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.

Several ways to avoid this trap:

1. Avoid inaccurate ways of implying ownership or control over the protocol or DAO (for example, "As the CEO of the protocol...", "Today, we turned on X feature of the protocol...").

2. Avoid forward-looking statements as much as possible, especially in terms of mechanisms such as programmatic token destruction to achieve pricing targets or stability.

3. Avoid promises or guarantees of ongoing efforts, and avoid referring to such efforts as having excessive importance to the project ecosystem (for example, use "initial development team" instead of "core development team" or "main development team" when appropriate, and do not refer to individual contributors as "managers").

4. Emphasize 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 image (own voice). A better way is: 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 environment. 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 single person or company is the face of the project anymore. Projects’ ecosystems are separate and distinct living systems. Just one mistake can have disastrous consequences.

X-clude

When launching outside the U.S., projects can take inspiration from the world of traditional finance and adopt a strict communications policy that complies with the requirements of Regulation S. This regulation exempts projects that are issued outside the U.S. from certain registration requirements imposed by 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 U.S. market interest” (SUSMI) in the token, i.e., whether there is significant market demand for the token 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 your project’s tokens should specifically highlight that these tokens are not available in the U.S.

Restrict

Restricting token issuance to restricted transfer tokens or off-chain credits can allow for more flexible communication policies. Well-thought-out projects are not at legal risk because, under the Howey test, an individual cannot make a “capital investment” to acquire the tokens.

However, if the project encourages participants to treat restricted transfer tokens or credits as investment products, these statements could seriously undermine the legal basis for restricting tokens.

Summary: Restrictions do not insulate Builders from legal consequences. Misrepresentations can haunt a project for years to come, preventing it from changing its launch strategy or even decentralizing.

Guideline 4: Be Careful with Secondary Market Listings and Liquidity

Projects often want to list on secondary exchanges so that more people can get 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 exchanges; insufficient liquidity can lead to price volatility and increase risk for projects and 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 can lose 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 the market more fair, orderly, and efficient.

Despite this being the SEC’s stated mission, it has used announcements from projects regarding the availability of their tokens on secondary trading platforms to bring cases against these projects. It has also attempted to treat the provision of liquidity on secondary markets as equivalent to a normal token sale.

Projects that did not initially use a decentralized token issuance strategy have greater flexibility with secondary market listings and liquidity, as both alternative strategies would delay the time to offer fully transferable tokens in the U.S.

In summary: Projects need to be extremely cautious when dealing with these listing and liquidity issues. The risks and rewards are often not equal. At a minimum, projects that are unsure whether they have achieved “enough decentralization” should not post about listing their tokens on exchanges, and likely should not engage in any market making activities in the U.S.

Guideline 5: Tokens should be locked up for at least one year after the TGE

This is critical. Projects should impose transfer restrictions on all tokens issued to insiders (employees, investors, consultants, partners, etc.), affiliates, and anyone who may participate in the token distribution. The 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 to prevent token issuers from issuing tokens. It may seek to do so again. Worse, the SEC's 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 project.

Ideally, tokens should be locked up (or otherwise appropriately restricted from transfer) for at least one year before they begin to vest, and vest linearly from that point through the next three years, for a total lockup of four years.

Such an approach can help mitigate the legal risks mentioned above, and 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 try to demand a shorter lockup period. This demand may indicate that investors are not paying much attention to securities laws and may sell the tokens in the first place.

For projects that issue tokens outside the United States, any tokens issued to U.S. employees, investors, and other insiders should follow this guideline. Teams should discuss with their legal counsel whether a more extensive lockup is necessary to preserve the exemption under Regulation S.

Summary: Enforce transfer restrictions for one year from the date of token issuance. Extending the release schedule for at least two to three years after that date is beneficial to project insiders, users, and the future. Anyone who argues otherwise may have questionable intentions.

As we have mentioned throughout this article, every token offering is different, but there are some guidelines that apply to most projects. Avoiding public fundraising, developing a decentralization plan, enforcing strict communication guidelines, carefully considering secondary markets, and locking tokens for at least one year can help projects avoid the most common token issuance pitfalls. Not only that, adhering to these common principles can help builders reinforce legality and safety innovation and drive progress in the industry.