Why everybody disagrees about tokens
Since tokens started becoming prevalent in the ICO era of 2017, we have cycled through multiple narratives and use-cases, from using tokens as a means of fundraising, through empowering community-led decisions all the way to a new way of launching products. Along the way, categories such as “Payment tokens”, “Utility tokens”, “Governance tokens”, etc., have emerged. There are two major reasons why there is still a lot of confusion and disagreement around tokens:
First of all, the different categories (and token in general) mean different things to different people, say from the point of view of a user or an investor, or from a legal perspective.
Second, depending on what projects any given person has been exposed to and what time they entered Web3 (during which a certain narrative was more prevalent), their general understanding of tokens will be significantly different.
More recently, the relationship between tokens and products has been at the centre of heated discussions. “Does your product need a token?” is a question that is frequently asked to founders active in Web3. This article aims to answer that question, as well as clarifying how tokens can be leveraged by a Web3 project.
The relationship between products and tokens
Products and tokens can relate to one another in different ways. First of all, there are indeed cases where a token is needed to make the product work in the first place. Much more common are cases where the product can benefit from a token, but doesn’t strictly need a token to function. Finally, in most cases, a token is not needed for a given product, but there may still be good reasons for a project to decide to launch a token regardless. We will now go through each of these cases and illustrate with examples of existing projects in each category.
Products that need a token
In reality, there are only a handful of use cases and product categories that NEED a token, meaning that they could not provide their core functionality without it.
Most notably, they include Layer 1 blockchains: In order to secure the blockchain, a native monetary asset is needed for all types of consensus algorithm in order to incentivise validators/miners and to ensure their incentive alignment (e.g. through the possibility of slashing). Usually, the token is also required as a means of payment for transaction fees for using the blockchain. Arguably, 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 Unique Network.
<Read about why we invested in Unique Network, Polkadot’s first custom parachain>
Another category of use cases are digital resource networks that provide these resources in a decentralized manner and need to balance supply and demand, from storage to compute and even data connectivity. Examples include Filecoin for storage or more recently, Uplink, a mesh network for decentralized connectivity.
Products that can be significantly improved with a token
More frequently, certain types of products can arguably be improved significantly with the addition of a token, even though they could also be built without. For example, tokens can improve products relying on users to provide a given service such as content creation or curation. Notable examples include SuperRare and Ocean Protocol.
Financial applications (and any product with user funds at risk) can leverage tokens to provide an additional layer of security by creating native insurance with a security module. This mechanism was pioneered by Aave and is used by many more recent financial applications, such as Rand Network. Nexus Mutual generalised the use case to create decentralized insurance as a service.
Potentially the largest category of products that can significantly benefit from tokens are any products that rely on a network effect to provide their service and need to overcome a “cold-start” problem in order to be useful. This includes any marketplace such as Hundo (recruiting) and Lemonade (events). Recently, LooksRare has made waves by leveraging tokens to take away market share from the incumbent OpenSea.
Another use case where both decentralized content creation and the cold start problem are relevant are data unions, for example Pool Data or Ozone. There are other ways that tokens can improve products, and innovation in this area will continue.Hence this is not a complete list but merely provides some examples.
Potential pitfalls of introducing tokens to a product
It is important to consider that in some cases, introducing a token closely tied to the product can harm prospects of success. There are recurring pitfalls that Web3 founders 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 Layer 1 blockchains or decentralized resource networks (“Products that need a token” above). In most other cases, a payment token causes significant friction (especially if the target audience is more general or even includes enterprise customers), while only providing a weak utility for the token, in addition to not sustaining long term value (the “velocity problem”).
Another pitfall is if the token is exclusively used as a reward mechanism, 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.
Finally, if the project has raised capital on an equity basis before, care is needed not to introduce conflicts and adverse incentives between token holders and equity holders. This often occurs in cases where a part of the product revenues goes to an incorporated company and another part goes to token holders (usually indirectly).
To token or not to token?
If the product does not fall into the categories described above, the answer to the question “Does the product 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 decentralise 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 jurisdiction allows it, a governance token can be used effectively to incentivise team members and raise funds for the project. This line of reasoning becomes more relevant if the project has contributors distributed all over the world and is hoping to raise a crowdsale from many small contributors.
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 Web3-related product. Especially in an overall market downturn and if there is no product justification for a token, introducing a governance token may get pushback from investors. In addition, there are other ways of incentivising users and collaborators that may be more adequate, for example revenue shares or reputation systems.
The flowchart above summarises the considerations described in this article.
We hope that it provides guidance to Web3 founders on the decision on whether or not to launch their own token, and helps answer questions on whether that token is needed and what it is for. There are many other relevant considerations once a project decides to launch a token, for example, when, how and to whom to distribute the token.
In this piece, you learned about the different web3 products which do and do not need a token. Here are our top tips:
- The narrative surrounding tokens and their use case has changed over time and people who have entered the Web3 ecosystem at different times in the cycle may have differing understandings of what tokens can be used for
- There are three types of product: those that need a token, those that would be improved by having a token and those that do not need a token. Understand which category your product falls into
- Products that need a token include Layer 1 networks and digital resource networks.
- Examples of cases where a product can be significantly improved with a token are content creation or curation; financial products creating decentralized insurance with a security module; products relying on a network effect
- If you decide your product needs a token, be aware of pitfalls such as introducing friction if your token is the only payment mechanism, or creating a token that is used for rewards but is likely to be sold for cash. You should also beware of alienating existing equity holders
- Governance tokens can make sense in specific cases, but also consider other incentivisation mechanisms, such as reputation systems or revenue share
Jan Baeriswyl joined Outlier Ventures as one of the first token designers after going through Basecamp #2 as a founder and is now in a leadership role as a token design manager. He has worked with over 50 teams on their token designs throughout his time at OV and is an active advisor and investor in many web3 companies. Before joining OV, Jan founded Superlinked with a senior engineer he met while working at Google. Jan studied economics at HSG St Gallen, where he wrote his thesis on tokens in 2016.
