Should you launch a token?

Share Dialog

There is still confusion around the nature and use of tokens because of their complex history, the different emphases of different stakeholders, and overlapping definitions. Tokens are being criticized for all kinds of different reasons: not being useful, not being valuable, being issued too much or too little.

This debate continues to evolve with market cycles. During bear markets, founders face skepticism with questions like "Does your protocol really need a token?". While in bull markets, the conversation shifts to an eager "Wen token?". Regardless of market conditions, founders must carefully consider whether and how a token can genuinely benefit their protocol's ecosystem. This article provides a guide to help determine whether launching a token makes sense for a given protocol, elaborating on the trade-offs between incentivization & distribution and capital formation.

The relationship between protocols and tokens can be structured in two different ways.

1. First of all, there are indeed cases where a token is needed to make the protocol work in the first place.

2. Much more common are cases where the protocol can benefit from a token, but doesn’t strictly need a token to function.

We will now go through both of these cases and illustrate with examples of existing projects in each category. There are also potential pitfalls of tokens that founders need to be aware of for making an informed decision, which we will address before summarizing our considerations with a decision flow chart.

In reality, there are only a handful of protocols that strictly need a token, meaning that they could not provide their core functionality without it. For these, incentivization and distribution is crucial, especially in early phases.

Most notably, they include Layer 1 blockchains (L1s): In order to secure the blockchain, a native monetary asset is needed for all types of consensus algorithms in order to incentivise stakers/miners and to ensure their incentive alignment. Usually, the token is also required as a means of payment for transaction fees for using the blockchain. This was the original use case for native tokens with blockchains such as Bitcoin and Ethereum, and is still best practice for more recent sovereign chains such as Sui or Monad. Note that with the advent of Eigenlayer and other restaking protocols, it is now also possible to launch a chain without its own native token.

However, Eigenlayer would only work in a much more limited way without its native token EIGEN that is needed for “intersubjective consensus”, adjudicating slashing conditions that are not objective/on-chain. We can generalize that a subset of crypto-economic protocols, most importantly staking/slashing mechanisms, require native tokens to work. In these mechanisms, participants need to put capital in the native token at risk for the right to perform work on behalf of the protocol. If this work is performed correctly (e.g. participating in consensus of a blockchain), participants earn more of the native token, often as an annual percentage return (APR) on the provided capital. A native token is required to issue those rewards to participants.

One could also argue that DePin (Decentralized Physical Infrastructure) networks that provide infrastructure from storage to connectivity in a decentralized manner realistically need their own token to work. While such a network could theoretically run without its own token at maturity, the cold-start problem (see the chapter below) is so significant that they would be unlikely to get there without first launching a token. Examples for DePin include IPFS/Filecoin or Impossible Cloud for storage and Helium for connectivity.

More frequently, certain types of protocols can be improved significantly with the addition of a token, even though they could also be built without. The benefits of adding a token are mostly around incentivization and distribution: either for initial adoption, to improve performance, or to reward loyalty.

Even when it is not strictly required, the addition of a staking/slashing mechanism can increase the quality of services provided by external stakeholders. For example, services such as injecting off-chain data or curation can be improved if there is capital at stake for the providers. Chainlink uses a staking mechanism to improve the quality of its oracles.

Potentially the largest category of protocols that can significantly benefit from tokens are any protocols that rely on a network effect to provide their service and need to overcome a “cold-start” problem in order to be useful. The cold-start problem describes a situation where both supply and demand sides are needed for a protocol to work, and neither wants to join without the other one already being there. By issuing its own native token, a protocol can pay the supply side without the demand being there to pay yet and, therefore, overcome this problem. For example, the Filecoin token successfully bootstrapped the supply side of IPFS. Similarly, “X-to-earn projects” from games like Axie Infinity or health data protocols like Sweatcoin use token incentives to bootstrap an initial user base. Other examples include L2s like Blast and Zircuit, which have successfully scaled their total value locked (TVL) to billions of dollars by using this strategy (starting as points programs).

A third category of protocol improvements through tokens can be broadly summarized as loyalty programs. Whether by locking tokens upfront (as originally proposed by Curve and still practiced by many DeFi protocols) to receive benefits or by accruing boosts over time (for example, as with Kamino Finance), tokens can incentivize long-term participation. Loyalty mechanisms can often be effectively combined with staking mechanisms.

There are other ways that tokens can improve protocols, and innovation in this area will continue. The most common ways that tokens can improve protocols include:

1. Improving services with staking

2. Overcoming the cold-start problem with rewards

3. Incentivizing long-term participation and loyalty

It is important to consider that, in some cases, introducing a token closely tied to the protocol can harm prospects of success. There are recurring pitfalls that founders of crypto protocols should be aware of and avoid wherever possible.

First of all, using a native token as the only admissible means of payment generally only makes sense in the case of L1s or DePins (“Protocols that need a token” above). In most other cases, requiring tokens for payment causes significant friction, especially if the target audience is not crypto-native or even includes enterprise customers. Payment utility also does not help sustain long term token value (see the “velocity problem”). These in fact create neither incentivization & distribution advantages nor do they foster capital formation (the velocity of tokens has been discussed repeatedly since the advent of utility tokens)

Another pitfall is using the token exclusively for user rewards, without providing reasons for users to hold on to or even lock up the token (e.g. through staking). The introduction of financial incentives may “crowd-out” the intrinsic motivation of users, and if the only thing they can do with the token is sell it for cash, the token will have a hard time sustaining its value. Elevated token emissions to incentivize user activity can also lead to negative feedback loops when token price starts declining, as the case of Axie Infinity and other “x-to-earn” tokens have illustrated. Here, lacking capital formation ultimately destroys incentivization.

Finally, if the project has raised capital on an equity basis before, care is needed to avoid conflicts of interests and adverse incentives between token holders and equity owners. Conflicts of interest often occur in cases where a part of the protocol revenues goes to an incorporated company and another part goes to token holders (usually indirectly).

To summarize, major pitfalls to avoid when adding tokens to protocols include:

1. Adding friction for users when requiring payments in tokens

2. Creating vulnerability to negative feedback loops through excessive rewards

3. Generating conflicts of interest between token holders and equity owners

If the protocol does not fall into the categories described above, the answer to the question “Does the protocol need a token?” is likely a clear “No”. However, there may still be good reasons to launch a token nevertheless.

Most notably, if the project wants to decentralize control and distribute ownership widely, whether for legal or ideological reasons, a (governance) token may still make sense. As long as the pitfalls described above can be avoided and the relevant jurisdictions allow it, a governance token can be used effectively to incentivise team members and raise funds for the project. Airdrops and other distribution mechanisms can be used to distribute the token to early users and contributors. This line of reasoning becomes more relevant if the project has contributors distributed all over the world or is hoping to raise a crowdsale from many small contributors. As regulatory clarity increases, other capital-like mechanisms like distributing protocol cash flows to token holders are also likely to become more prevalent.

However, it is also important to note that projects in that situation should carefully consider the decision and not feel pressured to launch their own token just because they are building a blockchain-related protocol. If there is no protocol-level justification for a token, introducing a governance token may conflict with certain regulations. In addition, there are other ways of incentivizing users and collaborators that may be more adequate, for example revenue sharing or reputation systems.

The flowchart above summarizes the decision tree for considering the addition of a token to a protocol. We hope that it provides initial guidance to founders on the decision on whether or not to launch their own token.

The decision to launch a token remains one of the most consequential choices crypto founders face today. True protocol-token fit exists when tokens either enable core functionality (as with L1s and DePin) or meaningfully enhance protocol operations through staking, bootstrapping, or loyalty mechanisms.

However, the pressure to "tokenize everything" should be resisted – a lesson hard-learned through multiple market cycles. The most successful token implementations will be those that arise from genuine protocol requirements rather than market pressures, avoid common pitfalls like excessive rewards or payment friction, and align with the project's long-term vision for decentralization and community ownership. As the blockchain ecosystem matures, a thoughtful approach to token design will distinguish sustainable protocols from short-lived experiments.

There is still confusion around the nature and use of tokens because of their complex history, the different emphases of different stakeholders, and overlapping definitions. Tokens are being criticized for all kinds of different reasons: not being useful, not being valuable, being issued too much or too little.

This debate continues to evolve with market cycles. During bear markets, founders face skepticism with questions like "Does your protocol really need a token?". While in bull markets, the conversation shifts to an eager "Wen token?". Regardless of market conditions, founders must carefully consider whether and how a token can genuinely benefit their protocol's ecosystem. This article provides a guide to help determine whether launching a token makes sense for a given protocol, elaborating on the trade-offs between incentivization & distribution and capital formation.

The relationship between protocols and tokens can be structured in two different ways.

1. First of all, there are indeed cases where a token is needed to make the protocol work in the first place.

2. Much more common are cases where the protocol can benefit from a token, but doesn’t strictly need a token to function.

We will now go through both of these cases and illustrate with examples of existing projects in each category. There are also potential pitfalls of tokens that founders need to be aware of for making an informed decision, which we will address before summarizing our considerations with a decision flow chart.

In reality, there are only a handful of protocols that strictly need a token, meaning that they could not provide their core functionality without it. For these, incentivization and distribution is crucial, especially in early phases.

Most notably, they include Layer 1 blockchains (L1s): In order to secure the blockchain, a native monetary asset is needed for all types of consensus algorithms in order to incentivise stakers/miners and to ensure their incentive alignment. Usually, the token is also required as a means of payment for transaction fees for using the blockchain. This was the original use case for native tokens with blockchains such as Bitcoin and Ethereum, and is still best practice for more recent sovereign chains such as Sui or Monad. Note that with the advent of Eigenlayer and other restaking protocols, it is now also possible to launch a chain without its own native token.

However, Eigenlayer would only work in a much more limited way without its native token EIGEN that is needed for “intersubjective consensus”, adjudicating slashing conditions that are not objective/on-chain. We can generalize that a subset of crypto-economic protocols, most importantly staking/slashing mechanisms, require native tokens to work. In these mechanisms, participants need to put capital in the native token at risk for the right to perform work on behalf of the protocol. If this work is performed correctly (e.g. participating in consensus of a blockchain), participants earn more of the native token, often as an annual percentage return (APR) on the provided capital. A native token is required to issue those rewards to participants.

One could also argue that DePin (Decentralized Physical Infrastructure) networks that provide infrastructure from storage to connectivity in a decentralized manner realistically need their own token to work. While such a network could theoretically run without its own token at maturity, the cold-start problem (see the chapter below) is so significant that they would be unlikely to get there without first launching a token. Examples for DePin include IPFS/Filecoin or Impossible Cloud for storage and Helium for connectivity.

More frequently, certain types of protocols can be improved significantly with the addition of a token, even though they could also be built without. The benefits of adding a token are mostly around incentivization and distribution: either for initial adoption, to improve performance, or to reward loyalty.

Even when it is not strictly required, the addition of a staking/slashing mechanism can increase the quality of services provided by external stakeholders. For example, services such as injecting off-chain data or curation can be improved if there is capital at stake for the providers. Chainlink uses a staking mechanism to improve the quality of its oracles.

Potentially the largest category of protocols that can significantly benefit from tokens are any protocols that rely on a network effect to provide their service and need to overcome a “cold-start” problem in order to be useful. The cold-start problem describes a situation where both supply and demand sides are needed for a protocol to work, and neither wants to join without the other one already being there. By issuing its own native token, a protocol can pay the supply side without the demand being there to pay yet and, therefore, overcome this problem. For example, the Filecoin token successfully bootstrapped the supply side of IPFS. Similarly, “X-to-earn projects” from games like Axie Infinity or health data protocols like Sweatcoin use token incentives to bootstrap an initial user base. Other examples include L2s like Blast and Zircuit, which have successfully scaled their total value locked (TVL) to billions of dollars by using this strategy (starting as points programs).

A third category of protocol improvements through tokens can be broadly summarized as loyalty programs. Whether by locking tokens upfront (as originally proposed by Curve and still practiced by many DeFi protocols) to receive benefits or by accruing boosts over time (for example, as with Kamino Finance), tokens can incentivize long-term participation. Loyalty mechanisms can often be effectively combined with staking mechanisms.

There are other ways that tokens can improve protocols, and innovation in this area will continue. The most common ways that tokens can improve protocols include:

1. Improving services with staking

2. Overcoming the cold-start problem with rewards

3. Incentivizing long-term participation and loyalty

It is important to consider that, in some cases, introducing a token closely tied to the protocol can harm prospects of success. There are recurring pitfalls that founders of crypto protocols should be aware of and avoid wherever possible.

First of all, using a native token as the only admissible means of payment generally only makes sense in the case of L1s or DePins (“Protocols that need a token” above). In most other cases, requiring tokens for payment causes significant friction, especially if the target audience is not crypto-native or even includes enterprise customers. Payment utility also does not help sustain long term token value (see the “velocity problem”). These in fact create neither incentivization & distribution advantages nor do they foster capital formation (the velocity of tokens has been discussed repeatedly since the advent of utility tokens)

Another pitfall is using the token exclusively for user rewards, without providing reasons for users to hold on to or even lock up the token (e.g. through staking). The introduction of financial incentives may “crowd-out” the intrinsic motivation of users, and if the only thing they can do with the token is sell it for cash, the token will have a hard time sustaining its value. Elevated token emissions to incentivize user activity can also lead to negative feedback loops when token price starts declining, as the case of Axie Infinity and other “x-to-earn” tokens have illustrated. Here, lacking capital formation ultimately destroys incentivization.

Finally, if the project has raised capital on an equity basis before, care is needed to avoid conflicts of interests and adverse incentives between token holders and equity owners. Conflicts of interest often occur in cases where a part of the protocol revenues goes to an incorporated company and another part goes to token holders (usually indirectly).

To summarize, major pitfalls to avoid when adding tokens to protocols include:

1. Adding friction for users when requiring payments in tokens

2. Creating vulnerability to negative feedback loops through excessive rewards

3. Generating conflicts of interest between token holders and equity owners

If the protocol does not fall into the categories described above, the answer to the question “Does the protocol need a token?” is likely a clear “No”. However, there may still be good reasons to launch a token nevertheless.

Most notably, if the project wants to decentralize control and distribute ownership widely, whether for legal or ideological reasons, a (governance) token may still make sense. As long as the pitfalls described above can be avoided and the relevant jurisdictions allow it, a governance token can be used effectively to incentivise team members and raise funds for the project. Airdrops and other distribution mechanisms can be used to distribute the token to early users and contributors. This line of reasoning becomes more relevant if the project has contributors distributed all over the world or is hoping to raise a crowdsale from many small contributors. As regulatory clarity increases, other capital-like mechanisms like distributing protocol cash flows to token holders are also likely to become more prevalent.

However, it is also important to note that projects in that situation should carefully consider the decision and not feel pressured to launch their own token just because they are building a blockchain-related protocol. If there is no protocol-level justification for a token, introducing a governance token may conflict with certain regulations. In addition, there are other ways of incentivizing users and collaborators that may be more adequate, for example revenue sharing or reputation systems.

The flowchart above summarizes the decision tree for considering the addition of a token to a protocol. We hope that it provides initial guidance to founders on the decision on whether or not to launch their own token.

The decision to launch a token remains one of the most consequential choices crypto founders face today. True protocol-token fit exists when tokens either enable core functionality (as with L1s and DePin) or meaningfully enhance protocol operations through staking, bootstrapping, or loyalty mechanisms.

However, the pressure to "tokenize everything" should be resisted – a lesson hard-learned through multiple market cycles. The most successful token implementations will be those that arise from genuine protocol requirements rather than market pressures, avoid common pitfalls like excessive rewards or payment friction, and align with the project's long-term vision for decentralization and community ownership. As the blockchain ecosystem matures, a thoughtful approach to token design will distinguish sustainable protocols from short-lived experiments.

<100 subscribers

<100 subscribers