The next step is to take your research from Defining your Product Value and convert it into a token/economic model for your protocol. On a high level, the value of the token will be derived from the supply & demand for it, where supply is generally created through inflation and fees to cover dividend payouts & protocol costs (e.g., cost of security, usage incentives, etc.).
Demand generally comes from token utility, the potential revenue users seek to obtain, any potential governance or community rights the token might carry, and any other benefits a token holder might obtain.
Introduction
Only tokens that are strategically designed to capture sufficient demand will be able to offset the cost and create value for the token.
The questions that need to be answered are:
- What is the relation between your product and the token?
- Is the token used for paying for your product/service?
- Is the token needed to access your product in the first place?
- Does the token capture value from protocol revenues?
- How does the token add value to your product? Is a token needed?
- Would your product work without a token?
- There have been plenty of cases where dApps have launched a token for the sake of creating liquidity for the project or to raise funds for the development of the project. Sometimes a more traditional business model like capturing fees and directing them to your company is more than sufficient to provide the services that you do.
- In some cases teams decide to go the token route because they want the platform to be decentralized and their token holders to receive protocol revenue, but this carries the risk of the token becoming a security. Teams need to carefully weigh the consequences and obtain legal advice on this matter.
- What is your protocol used for, and will there be any revenue streams?
- What is the flow of the potential revenue?
- When protocol revenue is captured (e.g. via protocol fees, product fees), there are different places where the revenue could flow. They can be distributed on-chain (e.g. via re-distribution, see point below), or moved off-chain (generally directly to the team/foundation).
- Will it be re-distributed to the users, a reserve pool, and/or the community?
- Depending on the revenue flow, it can have an impact on the token price (in the case of re-distributing to users/stakers) but also an impact on how many funds are available for future development (in the case of re-distributing to a reserve pool). Due to this, a lot of projects have decided to allocate revenue to different buckets instead of just one.
- How do you create value for your network participants?
- Network Users
- Network Contributors
- Token Holders
- Anyone else who participates in your network
Ideally the token value should be a function of the usage/demand for your product. This way, incentives are aligned and the common goal for all token holders is protocol adoption.
Here are two examples of how protocol usage and token value accrual are aligned or are not aligned:
Example 1: Protocol Usage & token value are aligned (GMX & $GMX)
Example 2: Protocol Usage & token value are not aligned (Uniswap & $UNI)
2.1 Understanding Token Velocity
While Supply & Demand mechanics are critical to any successful token model, it is important to understand token velocity. Token velocity is a measure of how frequently the token “changes hands''. If the only incentive to buy a token is short term utility (e.g. paying for a fee/service), more likely than not, whoever receives the token (as a payment) will have more reasons to sell the token right away which leads to selling pressure rather than demand for the token. Most businesses are being conducted in fiat and holding a volatile token is not in the interest of most for-profit actors, especially if they have another fiat-based cost attached to running their service.
Token velocity can be calculated as the Total Transaction Volume divided by the Average Network Value. From this formula it can be derived that the network value only goes up if the total transaction value is outpacing token velocity. In simple terms, it means that in order to increase the network’s value users should be incentivized to hold the network token instead of wanting to sell it right away after obtaining it.
In order to optimize for reduced token velocity and to increase the demand side, there need to be incentives for users to not only acquire the token, but also hold it, which can be in different shapes or forms. Such examples are:
- Expected price appreciation (e.g. via profit sharing or speculation)
- Locking it away (e.g. staking APY, providing liquidity, voting rights)
- Burning mechanisms
- Becoming a store of value (i.e. an asset or currency that can be saved, retrieved, and exchanged in the future without deteriorating in value)
2.2 Driving Demand & Usage
To help define the demand drivers, the main question that needs to be answered is:
What are the upsides for someone to hold your token and what can they do with it?
The most common use cases in Cosmos (and beyond) are:
Staking (most L1s)
Governance (most L1s + some dApps)
Network/gas fees (most L1s)
These are the “standard” use cases for almost any Cosmos Chain but they are not outstandingly groundbreaking on their own. The original example for this model is the Cosmos Hub’s native coin $ATOM which solely had these three use cases before implementing Interchain Security.
So ideally you create more upsides as to why people want to have your token to create a demand for it.
Some examples and how to do this are:
Capturing protocol revenue
To pay for a product/services
Demand from Burning/Supply reduction
These use cases are evolving over time and should be tied closely to the product market fit of the network. Ideally all participants can draw some sort of value from a functioning economic model.
2.3 Managing the Supply Side
The other side of the equation is the supply side. As a general rule of thumb: the less supply the better. However, supply has to be managed strategically in order to attract enough users to bootstrap the network in the first place.
While supply & incentives are generally outpacing the demand side in early network stages, there are several mechanisms to incentivize available supply not to hit the market and avoid it being sold. This includes:
1. Locking Liquidity
Staking & Bonding to secure the network
Staking to receive voting rights in the network’s governance
Staking tokens to receive the protocol’s revenue
Bonding tokens to provide Liquidity
It is worth noting that achieving these behaviors generally has to be incentivized with tokens from the token emission (see chapter: usage incentives) as networks in early stages do not yet collect enough fees to cover these incentives and pay for the cost with the protocol’s revenue.
It is also important to note that high incentives for locking liquidity can also disincentivize users from using the token in another way (e.g. use the network, pay for services), as not locking the liquidity comes with an opportunity cost (i.e. missed rewards).
2. Vesting
By implementing vesting schedules for team members, VCs and other early investors, a decent chunk of the supply can be prevented from hitting the market until the project is more mature and potentially some price stability is established. Vesting duration and a cliff period can be of varying durations, usually anywhere from 1 to 6 years. For more info, read: Team Token Allocation and Vesting
3. Managing the inflation rate
After planning and setting the initial inflation rate, these parameters can usually still be changed at a later stage by adjusting a parameter through a governance proposal while giving a good reasoning to reduce the token emission. While this should be treated with care, it may be beneficial to the protocol to adapt the emission schedule over time. For example, if the protocol becomes profitable sooner than expected or a portion of the emission is not required anymore to bootstrap users or to incentivise a certain behavior.
4. Managing the reserve & community pool
The protocol’s strategic reserve / treasury is usually managed by the founding team, while a community pool may be managed by the token holders of the chain. Both are often seeded with a significant amount of tokens which can have a major impact on the supply side.
Properly managing these pools through vesting periods and establishing proper rules to sustainably spend tokens is very important to prevent too many tokens hitting the market at once. A common issue with newly launched chains is the lack of liquidity for the treasury to sell into. By overspending, you run the risk of impacting price and making the treasury and the community pool less valuable in terms of USD, effectively decreasing protocol funding in the long run.
5. Fixed Supply / Max Cap
Fixing the total token supply by implementing a maximum token cap is generally a good idea. This was pioneered by no other than Bitcoin itself (21M max. supply), but adopted by many other proof of stake chains as well.
While there is an argument for an unlimited inflation (i.e. no max cap) to make sure protocol security is incentivized ad infinitum, it’s generally negatively perceived as it adds to continuous selling pressure. If planned properly by making sure incentives last until the protocol becomes profitable, it is recommended to implement a maximum cap on the token supply.
Most recent token launches we’ve seen in Cosmos tend to have a fixed supply by cutting emissions down in regular intervals, similar to Bitcoin’s “halvening”.
6. Burning Tokens
There are different challenges and factors to consider for implementing successful burning mechanisms for your token. There is no widely accepted approach, and the long-term price impact is unclear due to the lack of data and examples.
Successful burns are systematically integrated and executed automatically without burdening users. Combining multiple burn mechanisms, such as transactional, event, and auction burns, can create a deflationary effect on the network’s token. Sustainable impact and narrative can be achieved through native integrations rather than one-time burns.
You can find more information and plenty of examples in the chapter Burning Mechanisms.