原文标题：Getting ready to launch a token: What you need to know
原文作者：Adina Fischer，Matt Gleason，Justin Simcock
Source: a16zcrypto
Compiler: Lynn, Mars Finance
Given the fast-moving nature of the crypto 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 with their tokens. So, in this particular series of posts, we cover strategies for managing risk, a framework for assessing operational readiness, and: Be sure to subscribe to our newsletter to learn more about tokens and other company-building resources.
Prices are still rising, new tokens abound, and many web3 builders are feeling the pressure to launch their own. In recent months, the influx of meme coins has given the impression that it is easy to issue tokens. Theoretically, it does. Anyone can create, launch, and list tokens with no potential production use cases in less than an hour – it's as simple as sending an email.
But unlocking the token's potential as a new digital primitive, similar to a website in web1, is much more difficult. Launching tokens with productive use cases, tied to products and services that people can use, is much more wide-ranging. Tokens add complexity to the day-to-day operations of startups, and the release of tokens is mostly irreversible.
The most common mistake of web3 projects is to launch tokens too early. This mistake is often fatal, so any project that wants to take this step must determine why and how it intends to launch the token, as well as when it plans to do so.
Asking "when" isn't so much about the calendar as it is about determining a point in time when a project is reasonably positioned to overcome the legal, commercial, and operational challenges that come with launching a token.
So when will the project really be ready? In this article, we discuss the key considerations, as well as some of the risks and trade-offs that the project will encounter along the way.
Product-market fit
For any new project, startup, or product, finding the product-market fit is the most important focus. In the cryptocurrency space, founders should achieve product-market fit before launching a token – as the operational constraints associated with decentralized projects make it very difficult to tweak or adapt projects after they have launched.
Adding tokens to a project too early can also make it harder to find product-market fit. Tokens can distort incentives, influence user behavior, and lock certain elements of a product. For example, it can be difficult to change the token's economic model after the issuance, even if it is done to find product-market fit.
So, while well-designed tokens are a powerful amplifier of product-market fit, they are in no way a substitute for building and launching the right product. Tokens can attract users, but they can't keep them. And they certainly can't compensate for any potential product issues that the team has to diagnose and fix before release.
Of course, achieving product-market fit is easier said than done. Bringing the right product to a wide market takes skill and serendipity. But teams at the beginning of this journey can try a few different strategies to get started, including:
- Design self-reinforcing network effects from the start: Tokens are an extremely powerful new primitive for designing self-reinforcing network effects – through incentives, airdrops, retroactive public goods funding, etc. For the first time in history, builders can design a digitally native, protocol-specific incentive in their product as a way to incentivize good behavior, coordinate stakeholders, engage in distributed communities, and even subsidize demand.
- Build a product roadmap around the smartest customers: "Smart" customers have an innate understanding of the power and potential of new technologies. Identifying these customers early and gaining a deep understanding of their needs is key. Over time, more people are likely to follow their lead, which can increase the project's appeal and market share.
- Rewarding the right users: Each new platform attracts super users who exist for the "right" reasons and arbitrageurs who want to make a quick buck (the "airdrop farmers" of many crypto projects). It's critical to identify and reward power users who can provide long-term value to the network and drive others to participate.
- Invest in developers: Distributing token grants to developers building on the project's platform can encourage compounding growth, nurture early adopters, and enrich the community as a whole. When deciding which teams to support, projects should strategically consider the value they will bring to the network. A simple three-step plan should include:
- Know the key moments and timelines: will it be done in a month, a quarter, or a year?
- Provide milestone-based support and token grants: Avoid the pitfalls of paying upfront for something that never shipped.
- Understand the potential value of each development: The total value created by a particular project on the network should significantly exceed the resources invested.
- Work with the best: A key feature of building in the early stages of a blockchain network is that at any given time, it's easy to distinguish the projects with the strongest teams, use cases, and market appeal. Convincing these teams to build and deploy on a given platform allows them to adapt quickly to the product market, as new developers often follow early adopters.
From in-depth user research to pure alchemy, there are many paths and strategies that can achieve product-market fit. Regardless of the journey, the team must get it right before launching the token. For inspiration, projects can also look to examples such as Uniswap, which captured on-chain transactions with version 2 of its protocol before the token launch, Optimistic, which managed to attract a large number of developers before the token launch, and EigenLayer, which now has a lot of customer and user activity without a real-time token.
Finally, projects that wish to make continuous and substantial iterations of their products after the token launch should consider the alternative token launch strategies discussed here.
Feasible decentralization plans
Decentralization is the surest way to a more durable, compliant token, and it exemplifies the best use case for blockchain – a trusted, neutral network that functions similarly to public infrastructure in Web3. Many projects need tokens to be truly decentralized, to coordinate and make decisions among distributed users, to incentivize participation, and to unlock the promise of blockchain technology.
But decentralization is almost never a simple matter. Projects in the U.S. often face the chicken-and-egg paradox – decentralization requires the use of tokens, but the use of tokens requires decentralization. Compounding this complexity is the fact that for most projects, decentralization is a journey, not a destination.
Whether a project plans to be "fully decentralized" at launch, or intends to use an alternative startup strategy and decentralize over time through "progressive decentralization," most projects should start by preparing a decentralization plan.
The plan should start with high-level goals and then break them down into specific next steps. The framework outlined here lists the many different characteristics of blockchain projects (blockchain and smart contract protocols) and explains how projects can achieve greater decentralization for each project. Especially:
- Compute: Who provides the computing resources to keep the project up and running? Redundancy here may seem inefficient, but it's critical. By definition, a decentralized network cannot rely on any one team or organization for computation. For blockchains, this may mean ensuring that there is a strong set of validators. For smart contract agreements, this may require ensuring that there are multiple applications and websites available to access the protocol. For decentralized social networks or web3 games, this may require a diverse network of off-chain servers or nodes.
- Development: What ongoing development is needed?Who will do this in the future (i.e., core team, third-party developers, etc.)?How will it raise funds?These are some of the most critical questions in the decentralization process of the project. Depending on the project, the answer will look different, but it usually depends on the distributed community of developers deploying or integrating the smart contract protocol. For web3 games or social games, user-generated content may also be included.
- Governance: How decentralized is control of the project? Expecting the community to "solve the problem" when starting a project can lead to frustration. Most projects fail to overcome the complexities and socio-political realities involved in decentralized governance, undermining their legitimacy and utility. Still, it's crucial to distribute control. There are many factors to consider when designing effective governance, but minimizing governance is a good place to start.
- Value accumulation: What drives the economic value of the token, whether it's the cash flow generated by the fees charged or the market demand for the token, the project needs to establish a way for the token to increase in value, and not solely depend on the efforts of the project's founding team or any other sponsor. For blockchain, cultivating a diverse developer community is key. Incentivizing third-party applications and clients is important for smart contract protocols to help prevent "client-led," where one application or client has too much control over other applications or clients. While this decentralization is challenging in practice, projects like Ethereum and Solana are already being implemented today.
- Usage and accessibility: Can anyone use the project?If tokens are required to participate, are those tokens widely available?How broad is the user base?The more freedom a user has to access the project and the broader its user base, the more decentralized it generally becomes.
Decentralization can be different for each project. And projects don't need to be "fully decentralized" in all of these categories, or even "basically decentralized" to be "fully decentralized". On the contrary, decentralization depends on the overall project: the higher the degree of decentralization in some categories, the lower the degree of decentralization in other projects. For example, the more independent developers involved in the project, the more the original founding team will be able to participate in decentralized governance.
Projects also don't need to strictly adhere to the initial start-up plan, as these plans evolve naturally over time and growth. When we say "make a decentralization plan in advance", it simply means having a plan in place before the token launch, which can give the project a real chance to be decentralized, while also serving as a useful guide. Once a project has a decentralization plan in place, they can better determine how their decentralized status can help them refine their token issuance strategy.
Compelling tokenomics model
Tokens are great for bootstrapping and incentives, but they are not magic beans. Projects need a sustainable token model based on real unit economics to be successful. For example, if a project uses never-ending token-based incentives to drive growth – exceeding the potential economic value generated by the protocol – then it will eventually go bankrupt. Most tokens require cash flow to have value.
Therefore, a project should develop a basic economic model that aligns with the purpose of its token before launching.
This doesn't necessarily mean that the token needs to incur fees from the start. Network growth often takes precedence in the early stages. In the traditional start-up world, many companies, including Uber, prioritize growth. They subsidize users or reinvest funds instead of maximizing profits. However, projects need to consider how that value will ultimately flow to the token, and the cost of token incentives should be considered when designing the program.
For Layer 1 blockchains, Ethereum (EIP-1559) implements a base fee for all Ethereum transactions, providing the best economic model. For smart contract protocols, no definitive model has yet been established, but builders can explore many models of stakeholder capitalism – rewarding token holders for contributing to the protocol in a way that benefits the protocol. For example, compensating token holders for participating in decentralized governance, creating content, or providing liquidity.
As this model is implemented, be aware of specific legal pitfalls, including creating tax risks for token holders, bringing value to token holders through illegal activities, or combining voting rights and economic rights in a way that involves U.S. securities laws. Consult your advisor to help address these issues and more.
Robust organizational structure
The organizational structure can significantly influence the success of a token offering and define how well the project will work well in the future. There is no one-size-fits-all structure, so the process of choosing a structure must begin several months before the token launch. Even the simplest structures need to be in place prior to launch to ensure compliance with any regulatory and tax obligations associated with the issuance of an initial token.
Typical structures for web3 projects include original developer companies (also known as DevCos), foreign foundations, decentralized autonomous organizations (DAOs), and third-party protocols or application developers.
Even setting up a simple organizational structure can involve hundreds of decisions. Again, no two projects are alike, but here are some general principles that projects should consider:
- DevCo/Foundation Split: At a high level, the goal of most projects should be to make DevCo one of the many developers and application operators in the ecosystem, while the Foundation coordinates the community's efforts and guarantees the trustworthiness of the project. The Ethereum ecosystem does a good job of separating the relative roles of DevCos and the Ethereum Foundation. It is crucial that the Foundation should not exist only in name. It needs to have real substance and purpose. This could mean adding a founder to lead the foundation, or providing marketing, communications, and go-to-market operations for the foundation, with a focus on bringing new developers into the ecosystem and helping organize the community.
- DAOs and Eliminating Token-Based Governance: While eliminating token-based governance has its merits, it can be difficult in practice. For example, most projects want to build a treasury that contains governance tokens that have not yet been allocated in the initial allocation. While it is true that foreign foundations can control the Treasury Department, consolidating this power could raise centralization concerns. Alternatively, when token holders take control of the vault, they decentralize economic power and decide whether the foundation should continue to receive funds.
- Third-party developers and applications: Attracting third-party developers to build on top of your project is one of the most difficult challenges when it comes to decentralization. Developers typically select projects based on a variety of factors, including: (1) the technical support of the project, (2) the popularity of the project, (3) funding and incentives, and (4) whether the project is a credible neutral public infrastructure, or a proprietary system controlled by the company (i.e., the difference between Ethereum and Apple's App Store). It is critical that the project instills confidence in developers that they are free to build a real business and that the rules are not subject to arbitrary changes.
Two other organizational challenges to be aware of and emerging strategies to address them:
First, using a DAO increases the complexity of a project's operations. DAOs often do not have a legal presence, cannot pay taxes, and may expose their members to unlimited liability, responsible for the project's debts and tax compliance.
These risks are not theoretical, but new solutions may help. In March 2024, Wyoming passed a new form of legal entity called the Decentralized Unincorporated Nonprofit Association (DUNA) – modeled after the recommendations we helped come up with – that could solve all three of the problems of DAOs and provide them with many additional benefits. On top of that, the legal entity structure is permissionless, allowing the DAOs that use it to continue to function like current DAOs. DUNA is not suitable for all DAOs, so projects considering them should discuss with an advisor.
Second, building a foundation that provides meaningful value to the community is especially difficult if the foundation is located without a strong web3 talent pool. To date, most projects have grappled with this issue, as foundations are often located in niche jurisdictions, and hiring staff outside of those jurisdictions could undermine the legal basis of these structures.
Some projects are now beginning to address this challenge by adding operating subsidiaries to their foreign foundations, which are often located in jurisdictions where it is easier to hire employees. The UK, with its strong talent pool, constructive approach to Web3 regulation, and favourable tax treaties, is emerging as a strong candidate for this role. The operating subsidiary of a foreign foundation can be funded by the foundation and carry out all operations for the foundation while reducing the risk that employees are located outside the jurisdiction in which the foundation is located.
Other projects are utilizing independent U.S. foundations to supplement their foreign foundations. These U.S. foundations can initially be funded by DevCo and then receive ongoing funding from DAOs. Their operations can also include running their own grant programs, providing development assistance, and coordinating decentralized governance. The Uniswap Foundation is a great example of this approach, as it has effectively taken over the governance of the Uniswap community and is now driving the participation and activity of independent developers, thereby enhancing decentralization.
Ultimately, the organizational structure of the project will be determined by a number of factors: the governance structure and economic model of the project, the development work of any programs, the technology that supports any products and services, and the geographic location of the project and its target markets. Before launching a token, it is important to work closely with legal and tax advisors to implement an effective structure.
Operational readiness
Launching and owning real-time tokens requires some changes to the project's operations. Starting early can help projects meet operational challenges and ensure that mission-critical tasks aren't an afterthought.
- Funding: Most DevCos aim to have a runway for at least 3 years after the token launch. These funds can be used for additional product and development work, as well as to defend against regulatory encroachment. Fundraising after the token launch can be challenging for DevCos. Launching a token usually means that their main product is now owned by the community, they may not have anything else, and the token sale poses a significant legal risk. Projects should be planned accordingly and ensure that the size and capital of the foundation are appropriate for its intended role.
- Mechanics: The actual mechanics involved in issuing tokens (delivering tokens to employees and investors, setting up locks, etc.) are complex and can take months to put in place. Start early.
- Communication: Public communication before and after the token offering is very important. It is critical to ensure that the project team, especially its leadership, has a strict communication policy in place regarding the token issuance strategy. A single misstatement by the CEO can put the entire project at risk. For more guidance, see this article.
- Employee incentives: Projects often use tokens as incentives for employees and advisors. The structure for the first few years of the token launch is fairly simple, but as the project gets closer to the token launch, new complexities emerge. For example, given the volatility of token prices, some projects find it not meaningful to grant tokens over a multi-year period, preferring instead to offer rewards on an annual basis, usually structured as Restricted Token Units (RTUs). Projects should ask their advisors to carefully study all the changes they see in order to deal with token price fluctuations.
- Partner Incentives: Projects can also use tokens to align indie developer incentives with the project's goals. Prior to launch, rewards for developers can be structured as partner agreements, often featuring development and milestones based on user metrics. Once a project is launched, developers can rely on ecosystem funds and grant programs to incentivize developers, or they can opt for programmatic incentives programs such as Liquity, which automatically rewards front-end operators for introducing users to the protocol, which can more effectively engage and build anyone.
- Operational decentralization: Moving from centralized operational efforts to broad, independent community engagement requires significant change. Off-chain activities – such as protocol development, marketing, and governance – can be critical to a project's success. Decentralization involves the strategic distribution of roles and responsibilities within a community so that no one group or entity has enough influence to risk violating U.S. securities laws. For example, a common pitfall of DAOs is inadvertently centralizing governance, which can lead to regulatory and operational bottlenecks. Guiding projects towards decentralization while remaining compliant and resilient requires detailed planning of on-chain and off-chain activities. The ultimate goal is to drive community interaction and contribution to achieve "full decentralization".
As we've highlighted in other articles in this series, there is no one-size-fits-all guidance for token offerings. Instead, these are just a few criteria to consider when planning a launch, along with a trusted advisor.
The release of each token will vary depending on the actual circumstances of the project, from being deemed sufficiently decentralized to how ready all five categories are. Ultimately, the timing of the token's launch will depend on a variety of circumstances that are beyond careful planning.