Contrary to a common belief in Web3, not every blockchain project needs to issue its own token. Whether a token is necessary depends on the project’s nature, objectives, constraints, and the role it would play within the system.

For this reason, one of the first questions when designing a blockchain project is whether a token is actually required.

A useful starting point is to distinguish between a blockchain project and a tokenized project.

A blockchain project may rely on blockchain infrastructure, smart contracts, or wallets to deliver its product or service without needing to issue its own token. By contrast, a tokenized project depends on a token as a core component of its economic or operational design.

In other words, building in Web3 does not automatically justify creating a token. In some cases, launching a token can even damage a project if it is poorly designed or unnecessary, introducing more complexity than value.

History has shown many examples of projects harming their credibility, reputation, or long-term viability due to poorly justified token launches or incoherent tokenomics models. A token that lacks a clear purpose can create speculation without utility, attract short-term actors, and ultimately undermine the sustainability of the ecosystem.

For this reason, a project should never start with the question “How do we launch a token?” but rather with “Why does our project need a token?”

The central question therefore becomes: What does the token enable that could not be achieved, or could not be achieved as effectively, without it?

When does a blockchain project actually need a token?

Strong tokenomics emerge when the token serves as a means to an end. That end may involve participation, coordination, security, exchange, or ownership within the ecosystem.

Weak tokenomics, by contrast, arise when the token itself becomes the primary focus of attention, disconnected from the underlying product and the value it creates for users.

Although every project is unique, the justification for issuing a token typically falls mainly into three categories.

Decentralization, network security, and incentive coordination

Some protocols require a token because it plays a central role in aligning incentives among participants and maintaining network security.

Decentralized networks rely on distributed actors who contribute resources such as computing power, storage capacity, liquidity, validation, or data. These participants are often unknown to one another and may have no prior relationship or reason to trust each other.

A token helps coordinate these independent actors by rewarding useful behavior, encouraging participation, and penalizing harmful actions through mechanisms such as staking or slashing.

This logic is particularly relevant in:

• consensus systems
• validator or miner networks
• decentralized infrastructure protocols
• distributed compute or storage networks
• protocols requiring open participation from globally distributed actors

In these environments, the network would lack the incentive architecture needed to coordinate independent actors without a token.

The token therefore becomes part of the security and incentive structure that allows the network to operate without centralized control while enabling permissionless participation, meaning that anyone can join, contribute, or exit the network without requiring approval from a central authority.

Economic sovereignty

A project may also choose to issue a token in order to control its own economic system.

In this case, the token acts as an economic primitive through which the ecosystem defines its fees, rewards, access rules, and value flows. By using its own asset rather than relying on external currencies, the project can design incentive structures that are aligned with the internal dynamics of the system.

This approach allows the project to define its economic architecture and coordinate incentives among participants around the long-term growth of the ecosystem.

However, economic sovereignty alone is not sufficient justification. Even if a project controls its own token, it must still demonstrate why users would want to hold, use, or lock that token.

Asset, rights, and identity representation

In some cases, tokens exist because they represent ownership, rights, or information that must be recorded on-chain.

This is particularly common with:

• NFTs
• tokenized real-world assets
• digital credentials
• identity systems
• tokenized financial instruments
• governance rights

In these contexts, the token acts as a programmable representation of ownership or rights, allowing assets or data to be transferred, verified, and managed through blockchain infrastructure.

However, these 3 foundations do not apply equally to every project. Many blockchain initiatives are simply businesses using blockchain infrastructure. In such cases, the token must be justified by the concrete value it adds to the business model.

The substitution test

A strong token thesis begins with a clear explanation of why the token must exist. One useful way to evaluate this is through what can be called the substitution test.

This test asks whether the role of the token could be replaced by another asset or mechanism without significantly weakening the product.

For example, the same function might be performed using:

• stablecoins such as USDC
• an existing cryptocurrency such as ETH
• fiat payments
• loyalty points
• reputation systems
• equity ownership
• traditional subscription models

If users would be just as satisfied interacting with the product without the token, then the case for issuing one becomes significantly weaker.

In such situations, launching a token may introduce unnecessary complexity, speculation, and operational risk without meaningfully improving the product. If the token can easily be replaced by another asset or mechanism, it is unlikely to generate strong or durable demand.

The substitution test therefore helps prevent one of the most common mistakes in Web3: launching a token simply because it is expected rather than because it is necessary.

The risks of launching a token too early or for the wrong reasons

Launching a token is not a neutral design decision. It exposes a project to several layers of risk that may not exist otherwise.

• First, it expands the technical attack surface of the system through smart contracts, integrations, and potential market manipulation.

• Second, it increases product complexity by introducing token volatility, more complex user interactions with wallets and crypto tools, and incentive mechanisms that may encourage opportunistic behavior such as short-term profit seeking or reward farming.

• Third, it can create economic distortions. If token holders can extract value without contributing to the ecosystem, the token economy may become extractive rather than productive. This can create a misalignment between users and token holders, allowing short-term speculators to capture value at the expense of real users and ultimately driving genuine users away from the project.

• Fourth, requiring users to acquire a volatile token simply to access a product can create significant barriers to entry, particularly for non-crypto-native users. It introduces unnecessary friction by complicating onboarding and requiring users to understand wallets and other crypto tools before they can interact with the product, ultimately slowing adoption.

• Fifth, tokens may trigger significant regulatory exposure across multiple jurisdictions, including securities laws, compliance obligations, and tax implications, often generating substantial legal and operational costs.

• Finally, token launches often have a strong “ratchet effect”: once a token is issued and distributed to the market, it becomes extremely difficult to reverse the decision without damaging the project’s credibility and long-term ecosystem. For example, if a token appears unnecessary or poorly designed, the market may interpret it as an attempt to extract value from users rather than strengthen the system, eroding trust among users, investors, and the broader community.

For these reasons, launching a token too early or for the wrong reasons can create structural risks for the project.

Practical examples

Bitcoin: an example of a structurally necessary token

As explained earlier, some protocols require a token because it plays a central role in decentralization, incentive coordination, and network security. Bitcoin provides one of the clearest illustrations of this principle.

Indeed, Bitcoin is a decentralized network designed to enable peer-to-peer value transfer without relying on a central intermediary. Its security model is based on Proof of Work, where miners contribute computing power to validate transactions and secure the network.

In this system, BTC plays several essential roles that cannot easily be substituted.

• First, it acts as the incentive mechanism that rewards miners through block rewards and transaction fees. These rewards encourage participants to contribute computing power and maintain the security of the network. This directly reflects the principle of incentive coordination among independent actors.

• Second, BTC functions as the native unit of account and settlement within the protocol. Transactions and fees are denominated in BTC, making it an integral component of the system’s economic architecture.

• Third, BTC ensures that network security remains endogenous to the protocol. Because miners are rewarded in the native asset of the system, the security of the network does not depend on external payment mechanisms or centralized intermediaries.

From the perspective of the substitution test, replacing BTC with another asset would fundamentally change the system. If miners were paid through fiat or another external mechanism, the network would depend on trusted intermediaries to distribute rewards, reintroducing centralized control.

BTC is therefore not simply associated with Bitcoin, it is a core component that allows the network to operate as a decentralized system.

Etherscan: an example of a blockchain product that does not require a token

Etherscan illustrates how a blockchain product can create value without issuing its own token. It is a blockchain explorer that allows users to view transactions, analyze smart contracts, monitor wallet activity, and access on-chain data on the Ethereum network.

The platform relies on blockchain infrastructure but does not require a token as part of its economic or operational design. Users simply access and analyze public blockchain data, and the service does not depend on incentive coordination or decentralized security mechanisms.

From the perspective of the substitution test, introducing a native token would not improve the product. Etherscan is one example among many showing how some blockchain services create value by building tools around existing networks rather than by creating their own tokenomics.

Key questions before designing tokenomics and launching a token

Before deciding to launch a token, founders or tokenomics designers should ask a series of questions:

• What is the core product, and what problem does it solve?

• Is the project inherently tokenized, or is it simply a product using blockchain infrastructure?

• What are the current and intended flows of value within the ecosystem?

• What behaviors does the token incentivize?

• Does the system require its own asset for security, coordination, or decentralized participation?

• Could the same outcome be achieved using stablecoins, other cryptocurrencies, fiat, equity, points, subscriptions, or reputation systems?

• What does the token enable that could not be achieved, or could not be achieved as effectively, without it?

• What specific utility will the token provide, and who will demand it?

• Is that demand tied to real usage of the product or mainly to speculation?

• Will the token strengthen the long-term sustainability of the project and its ecosystem?

Key takeaways

Not every blockchain project requires a token. A token should only be introduced when it plays a necessary role within the system’s economic or operational design.

It is typically justified when it enables functions that cannot be achieved as effectively through other mechanisms, such as decentralized security, incentive coordination, or the on-chain representation of assets and rights.

When a token lacks a clear purpose or can easily be replaced by existing assets or systems, it is unlikely to generate sustainable demand and may introduce unnecessary complexity, risk, and speculation.

The most robust token economies are those in which the token emerges naturally from the project’s economic logic rather than being added as an artificial feature.