“How can I launch a token” is one of the most common questions we get from founders, given the rapidly evolving nature of the crypto industry. As prices rise, and FOMO sets in – everyone else is launching a token, should I? – it’s even more important for builders to approach tokens with caution and care. So in this special series of posts, we cover strategies for managing risk, frameworks for assessing operational readiness, and a few more rules for launch. Be sure to sign up for @A16ZCRYPTO">our newsletter for more on tokens and other company building resources.

Prices are still up, new tokens abound, and many web3 builders feel pressure to launch tokens of their own. The influx of memecoins in recent months has created the impression that launching a token is easy. And in theory, that’s true. Anyone can create, launch, and list a token with no potential productive use case in less than an hour — it’s as easy as sending an email.

But unlocking the potential of tokens as a new digital primitive (similar to what websites were in web1), is much harder. Launching tokens with productive use cases, tied to products and services that people can use, is much more involved. Tokens add layers of complexity to a startup’s day-to-day operations, and the launch of a token is mostly irreversible.

The most common mistake that projects make in web3 is launching tokens too early. This mistake is often fatal, so any project looking to take this step must establish why and how it’s intending to launch a token, along with when it plans to.

Asking “when” isn’t so much about calendaring as it is about establishing the point at which a project is reasonably positioned to overcome the legal, commercial, and operational challenges that come with launching a token.

So when is a project really ready? In this post, we discuss key considerations, and some of the risks and tradeoffs projects will encounter along the way.

Product-market fit

Finding product-market fit is the single most important focus for any new project, startup, or product. In crypto, founders should aim to achieve product-market fit prior to launching a token — as operational constraints associated with decentralized projects make it very difficult to adapt or pivot a project post-launch.

Adding a token to a project prematurely can also make it even more difficult to find product-market fit. Tokens can skew incentives, influence user behavior, and lock in certain elements of a product. Changing a token’s economic model after launch, for example, can be difficult, even when making this change in order to find product-market fit.

So, while well-designed tokens are a powerful amplifier for product-market fit, they are in no way a substitute for building and launching the right product. Tokens can attract users, but they cannot make them stick around. And they certainly cannot compensate for any underlying product issues that teams must diagnose and fix before launch.

Of course achieving product-market fit is much easier said than done. It takes both skill and serendipity to bring the right product to a great market. But teams at the beginning of this journey can try a few different strategies to start, including:

• Designing self-reinforcing network effects from the start: Tokens are an incredibly powerful new primitive for designing self-reinforcing network effects – through incentives, airdrops, retroactive public goods funding, and more. For the first time in history, builders can design a digitally native, protocol-specific incentive mechanism into their product as a way to incentivize good behavior, align stakeholders, engage a distributed community, and even subsidize demand.
• Building product roadmaps around the smartest customers: “Smart” customers have an innate understanding of the power and potential of a new technology. Identifying these customers early and cultivating a deep understanding of their needs is key. In time, more people will likely follow their lead, which can increase a project’s traction and share of the market.
• Rewarding the right users: Every new platform attracts both power users who are there for the “right” reasons and arbitrageurs (“airdrop farmers,” for many crypto projects) who are out to make quick money. It’s essential to identify and reward the power users, who can provide long-term value to the network and bring others along, too.
• Investing in developers: Distributing token grants to developers building on a project’s platform encourages compounding growth, nurtures early adopters, and enriches the whole community. When deciding which teams to support, projects should think strategically about the value they will bring to the network. A simple three-step plan should include:
  1. Understanding key moments and timelines: Will it be done in a month, a quarter or a year?
  2. Offering milestone-based support and token grants: Avoid the trap of paying up front for something that never ships.
  3. Understanding the potential value of each development project: The total value created on the network by a given project should significantly exceed the resources invested.
• Working with the best projects: A key feature of building in this early stage of blockchain networks is that, at any given time, it’s easy to separate out the projects with the strongest teams, usage, and market traction. Convincing these teams to build and deploy on a given platform can catapult it toward product-market fit, since new developers often follow early adopters.

Many paths and strategies can lead to product-market fit, from in-depth user research to pure alchemy. No matter the journey, teams must be well on their way before launching a token. For inspiration, projects can also look to examples like Uniswap, which captured on-chain trading with version 2 of its protocol prior to token launch; Optimism, which was successfully attracting a robust array of developers prior to token launch; and EigenLayer, which now has significant customer and user activity without a live token.

Finally, projects that expect to make ongoing and substantial iterations to their product post-token launch should consider alternative token launch strategies discussed here.

An actionable plan for decentralization

Decentralization is the surest route to a longer-lasting, more compliant token that embodies the best use cases of blockchains – credibly neutral networks that function like public infrastructure in web3. Many projects need tokens to truly decentralize, to align and make decisions across distributed users, to incentivize participation, and to unlock the promise of blockchain technology.

But decentralization is almost never straightforward. Projects in the U.S. are often confronted with a chicken-or-the-egg paradox – decentralization requires the use of tokens, but the use of tokens requires decentralization. Compounding this complexity, for most projects decentralization is a journey, not a destination.

Whether a project plans on being “sufficiently decentralized” at launch or intends to use an alternative launch strategy and decentralize over time through “progressive decentralization,” most projects should begin by preparing a plan for decentralization.

This plan should start with high-level goals, and then break those down into specific next steps. The framework outlined here maps out a number of different characteristics for blockchain projects (both blockchains and smart contract protocols) and explains how projects can achieve greater decentralization for each. In particular:

• Computational: Who is providing the computational resources that enable the project to function? Redundancy here may seem inefficient, but it is critical. By definition, a decentralized network cannot depend on any one team or organization for its computation. For a blockchain, this might mean ensuring there’s a robust validator set. For a smart contract protocol, this could entail ensuring there are diverse applications and websites available for accessing the protocol. For a decentralized social network or a web3 game, this might entail a diverse network of off-chain servers or nodes.
• Development: What ongoing development is required? And who is going to be doing it (i.e., the core team, third-party developers, etc)? How is it going to be funded? These are some of the most critical questions along a project’s pathway to decentralization. Answers will look different depending on the project, but will typically hinge on a distributed community of developers deploying or integrating with smart contract protocols. For a web3 game or social, that might also include user-generated content.
• Governance: How is control of the project being decentralized? Launching with the expectation that a project’s community will just “figure things out” will likely lead to disappointment. Most projects have failed to overcome the complexities and sociopolitical realities involved in decentralized governance, and their legitimacy and utility has suffered as a result. Nevertheless, it’s critical to distribute control. A lot of considerations go into designing effective governance, but minimizing governance is a good place to start.
• Value accrual: What is driving the economic value of a token? Whether that’s cash flows from collecting fees or market demand for tokens, projects need to establish a method by which their tokens will accrue value that does not entirely depend on the efforts of the project’s founding team or any other promoter. For blockchains, fostering a diverse community of developers is key. For smart contract protocols, incentivizing third-party applications and clients is important and helps safeguard against “client dominance,” where one app or client has outsized control given its position relative to others. While this kind of decentralization is challenging in practice, projects like Ethereum and Solana have achieved it 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 freely users can access a project, and the wider its user base, the more decentralized it usually is.

Decentralization can look different for every project. And projects don’t need to be “fully decentralized” or even “substantially decentralized” across all of these categories to be “sufficiently decentralized.” Rather, decentralization depends on the totality of a project’s circumstances: Greater decentralization in some categories means that projects can be less decentralized in others. For instance, the more independent developers are involved in a project, the more the original founding team can participate in decentralized governance.

Projects also don’t need to strictly adhere to their original launch plans, as these will naturally evolve with time and growth. When we say “have a plan for decentralization up front,” it simply means that mapping it out before token launch gives the project a real shot at achieving decentralization, and also acts as a helpful guide along the way. Once projects establish a plan for decentralization, they can then better determine how their decentralization status might help them refine their token launch strategy.

Compelling token economic model

Tokens can be great for bootstrapping and incentives, but they aren’t magic beans. Projects need a sustainable token model grounded in real unit economics to succeed. For example, if a project uses never-ending token-based incentives to drive growth – which outpaces underlying economic value accruing to the protocol – then it will eventually go bust. Most tokens will need cash flow in order to have value.

As a result, projects should develop a foundational economic model that aligns with the purpose of their token, before launching.

This doesn’t necessarily mean fees need to accrue to the token from the outset. Network growth often takes priority in early innings. In the traditional startup world, many companies, Uber included, prioritize growth. They subsidize users or reinvest funds rather than maximize profits. But, projects need to think through how that value will eventually flow to the token, and should consider the cost of token incentives when designing that plan.

For Layer 1 blockchains, Ethereum, with EIP-1559 which implemented a base fee to be burned for all Ethereum transactions, offers the best economic model. For smart contract protocols, no definitive model has been established yet, but builders can explore many models of stakeholder capitalism – rewarding tokenholders to contribute to the protocol in a manner that benefits the protocol. For example, compensating tokenholders for participating in decentralized governance, creating content, or providing liquidity.

As this model comes to life, look out for specific legal pitfalls, including creating tax risks for tokenholders, accruing value to tokenholders from illicit activity, or combining voting and economic rights in a way that implicates U.S. securities laws. Consult your counsel to help navigate these and more.

Robust organizational structure

Organizational structure can significantly influence the success of a token launch, and define how the project operates well into the future. There is no one-size-fits-all structure, so the process of choosing one must start several months ahead of a token launch. Even the most straightforward structure needs to be in place before launch to ensure compliance with any regulatory and tax obligations tied to issuing the initial token.

A typical structure for a web3 project includes the original developer corporation (also known as DevCo), a foreign foundation, a decentralized autonomous organization (DAO), and third-party protocol or app developers.

Hundreds of decisions go into setting up even a simple organizational structure. Again, no two projects are alike, but here are some overarching principles projects should think through:

• DevCo/foundation split: At a high level, most projects should aim to make the DevCo one of many developers and app operators in the ecosystem, while the foundation coordinates community efforts and safeguards the credible neutrality of the project. The Ethereum ecosystem does a good job of separating the relative roles of DevCos and the Ethereum Foundation. Critically, a foundation should not exist in name only. It needs to have real substance and purpose. This could mean adding a founder to lead the foundation, or providing the foundation with marketing, communications, and go-to-market operations that are focused 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’s difficult in practice. For instance, most projects will want to establish a treasury with governance tokens that haven’t been allocated in the initial distribution. While it is true that a foreign foundation could control the treasury, consolidating this power could raise centralization concerns. Alternatively, when tokenholders control the treasury, they decentralize economic power and determine whether the foundation should continue to receive funding.
• Third-party developers and applications: Attracting third-party developers to build on top of a project is one of the most difficult challenges when decentralizing. Developers generally choose projects based on a number of factors, including: (1) the tech underpinning a project, (2) the popularity of a project, (3) funding and incentivization, and (4) whether the project is credibly neutral public infrastructure, or a proprietary system that is controlled by a corporation (i.e., the difference between Ethereum and the Apple App Store). Critically, projects need to instill confidence in developers that they will be free to build a real business, and that the rules won’t be subject to arbitrary changes.

Two more organizational challenges to note, and emerging strategies for addressing them:

First, using a DAO adds a layer of complexity to a project’s operations. DAOs generally do not have legal existence, they can’t pay taxes, and they can potentially expose their members to unlimited liability, where they are liable 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 legal entity form called a Decentralized Unincorporated Nonprofit Association (DUNA) – modeled on recommendations we helped make – which can solve all three problems for DAOs and afford them many additional benefits. Most importantly, the legal entity structure is permissionless and enables DAOs that use it to continue to function just like DAOs do currently. DUNAs are not suitable for all DAOs, so projects considering them should discuss with counsel.

Second, setting up a foundation that delivers meaningful value to the community is especially difficult if the foundation is located in a place that doesn’t have a strong web3 talent pool. To date, most projects have struggled with this problem as foundations are typically located in niche jurisdictions and hiring outside of those jurisdictions risks undermining the legal basis for these structures.

Some projects are now beginning to address this challenge by adding an operational subsidiary to their foreign foundation, typically located in a jurisdiction where it is easier to hire employees. The United Kingdom – with its strong talent pool, constructive approach to web3 regulation, and favorable tax treaties – is emerging as a strong candidate for this role. A foreign foundation’s operational subsidiary can be funded by the foundation and conduct all operations for the foundation, while reducing the risk of having employees located outside the foundation’s home jurisdiction.

Other projects are using independent U.S. foundations to supplement their foreign foundations. These U.S. foundations can initially be funded by the DevCo, and then receive ongoing funding grants from the DAO. Their operations can also include operating their own grant programs, providing development assistance, and coordinating decentralized governance. The Uniswap Foundation is a great example of this approach because it has effectively taken over stewardship of the Uniswap community and is now driving independent developer engagement and activity, thereby enhancing decentralization.

Ultimately, the organizational structure of a project will be determined by a number of factors: The project’s governance structure and economic model, any planned development work, the technologies underpinning any products and services, and the geographic location of the project and its target market. Be sure to work closely with counsel and tax advisors to implement an effective structure before launching a token.

Operational readiness

Launching and having a live token requires a number of changes to a project’s operations. Getting started early can help projects get ahead of operational challenges, and ensure critical tasks are not an afterthought.

• Funding: Most DevCos aim to have at least 3 years of runway post-token launch. These funds can go towards additional products and development work, as well as defending against regulator encroachments. Fundraising after a token launch can be challenging for DevCos. Launching a token typically means that their primary product is now owned by a community, they may not have additional products lined up, and token sales introduce significant legal risk. Projects should plan accordingly, and also make sure that foundations are appropriately sized and capitalized for their expected role.
• Mechanics: The actual mechanics involved in launching a token – delivering tokens to employees and investors, setting up lockups, and more – are complex and can take several months to get into place. Get started early.
• Communications: Public communications leading up to and following a token issuance matter … a lot. Ensuring the project team, and especially its leadership, have a strict communications policy in place that’s tailored to the token launch strategy is critical. A single errant statement by a CEO can put an entire project at risk. For more guidance, see this post.
• Employee incentives: Projects often use tokens as incentive-based rewards for employees and advisors. Structuring in the years prior to a token launch is fairly straightforward, but as projects approach a token launch, new complexities arise. For example, given the volatility of token prices, some projects find that it doesn’t make sense to grant tokens over multiple-year periods, and instead prefer to offer awards on a yearly basis, typically structured as restricted token units (RTUs). Projects should ask their counsel to run through all of the variations they have seen to combat token price volatility.
• Partnership incentives: Projects can also use tokens to align the incentives of independent developers with the project’s goals. Before launch, awards to developers can be structured as partnership agreements, often featuring development and user metric-based milestones. After launch, projects can rely on ecosystem funds and grant programs to incentivize developers; or they can choose programmatic incentive programs (like Liquity, which automatically rewards frontend operators for bringing users to the protocol), which can more effectively enable anyone to participate and build.
• Operational decentralization: Shifting from centralized operational efforts to a broad, unaffiliated community engagement requires significant changes. Off-chain activities – like protocol development, marketing, and governance – may be critical to a project’s success. And decentralizing them involves a strategic distribution of roles and responsibilities within the community so that no single group or entity has enough influence to risk encroaching on U.S. securities laws. A common pitfall for DAOs, for example, is inadvertently centralizing governance, which can lead to regulatory and operational bottlenecks. Steering a project toward decentralization while remaining compliant and resilient requires detailed planning with respect to both on-chain and off-chain activities. Ultimately, the goal is to drive community interactions and contributions to achieve “sufficient decentralization.”

As we stress in other pieces in this series, there is no one-size-fits-all guidance for token launches. Rather, these are just a few criteria to consider when planning a launch, alongside trusted counsel.

Every token launch will look different, depending on the practical realities of the project, from what’s considered sufficient decentralization to the degree of readiness across all five of these categories. Ultimately when a token launches will depend on a variety of circumstances that exist beyond careful planning.

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

Disclaimer：

1. This article is reprinted from [a16z]. All copyrights belong to the original author [Miles Jennings、Jason Rosenthal]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.