Tokenomics Fundamentals Part III: How token

This article is part III of the following six-part series:

In Part I and Part II of the series we have covered the 5 "Ws", namely "Why, When, What, Where, and Who" of the W5H framework for token design. "Why" examines the rationale for the token and sustainable value creation of the token's underlying crypto-economy; "When" checks the best timing for launching a token; "What" investigates the type of tokens that is suitable for the use case; "Where" focus on the blockchain network stack where the token should be created; "Who" looks into the appropriate parties in the ecosystem that should own the token.

In this article, we continue to discuss the "How token" question. There are obviously numerous fronts we can explore about "How token". We will discuss several of them, including determining the number of distinct tokens needed, token supply generation and allocation, distribution, and token liquidity.

W5H framework for token design (How) by Charles Shen @ inWeb3.com

How token?

Determine the number of distinct tokens needed

As we go through the "why token" process, we often find different roles that tokens could play in the project to help achieve the system's goal. Put another way, there could be different types of utilities for a token, and there could also be governance rights for the token. The natural question is, how many different tokens do we need for the project? Or do we put everything into one token?

Before answering this question, we should define what we mean by "distinct tokens" for a project. As usual, when we talk about project tokens, we mean native tokens, i.e., tokens specifically created for the project. But there are still differences in the types of project native tokens. For example, the DeFi exchange project Sushi has its SUSHI native token. It also has an xSUSHI token that people receive when they stake their SUSHI tokens. The xSUSHI token accrues trading fees from the Sushi exchange and earns yield for its owner. The user can later return the xSUSHI to withdraw the original staked SUSHI plus the accrued SUSHI rewards. Therefore, xSUSHI is merely a yield-bearing version of the underlying SUSHI token. It is a simply wrapped or derivative of the underlying token. We do not count these tokens as truly "distinct tokens" for the project.

The decision of how to map the number of distinct tokens to the identified token objectives is not a straightforward one. The advantage of using an individual token for each purpose is that the design is much cleaner, making the token system's analysis much more straightforward. The disadvantage of using many distinct tokens in a single project is that the values are spread across different tokens, the liquidity of each token becomes thinner, and they could eventually hurt the project's overall growth. In addition, completely separate tokens are unable to leverage possible synergy that could result from strategically combined ones.

There is a "dual-token" model that is widely used. In this pattern, governance utility and non-governance utilities are separated by two tokens. A prominent example is the Axie Infinity game, which has its AXS token that plays the governance role and SLP token serving as the in-game currency. But the dual-token model is far from a generic answer to the problem because there could be many more token utilities than pure governance and currency.

One general approach to this problem is as follows:

List all the objectives we want tokens to achieve (e.g., specific product functions or incentive goals). This information should be available from the prior "Why token" step in Part I of the series.
Start by assuming a separate token for each objective
See whether/how we can group any of the individual tokens together based on the degree of interest alignment for potential holders of those tokens
Iterate the technical solution that both realizes the required business logic and makes the token grouping possible.
Also consider other properties for each token candidate (e.g., fungibility, application vs. infrastructure) during this process.

It is important to keep the following in mind:

The resulting decision depends heavily on the actual solution implementation and could differ significantly even for the same type of products.
The level of stakeholder interest alignment is key for deciding whether multiple objectives can be grouped into the same token.
Combining objectives that sit at different levels of the network stack (e.g., infrastructure vs. application level) introduces extra risks that require attention.
The decision made about choosing the distinct tokens is merely one component in the design, it does NOT guarantee whether the fundamental of the project is sound or not.

In the appendix of this article, we provide a case study using several decentralized stablecoin projects to illustrate how the above steps can be applied and how these considerations are reflected in the process.

Generate and allocate token supply

Once we know the token we want to create, we need to consider how to generate and supply it.

Maximum supply: When planning token generation, we first determine whether the token has a limited or unlimited total supply. This decision alone does not speak to the healthiness of the token design because it is the ongoing supply-demand equilibrium that really matters. In fact, among the top cryptocurrencies, BTC has a fixed maximum supply of 21M, while ETH's supply is unlimited. Some projects pick a maximum number based on its estimated number of holders and make sure they don't have to deal with a fractional number of tokens, e.g., that is how Ankr sets its maximum supply to 10B.

Minting schedule: While all tokens can be minted at once, it is more common to see the maximum supply of tokens gradually minted over time because it could be more friendly to supply regulation. There are two main ways to achieve that: on-demand minting or scheduled emission. The stablecoin DAI from MakerDAO can be minted at any time by providing the required collateral. There is no set minting schedule or supply limit. On the other hand, the Bitcoin blockchain produces roughly one block every 10 minutes, and with each new block, new BTCs are created. This release schedule continues until the maximum number of BTCs are generated.

Allocation table: Projects usually create an allocation table and specify how the main stakeholder categories share the token supply. One thing to note from the allocation table is that we do not want the token holding to be too concentrated. Over-concentration makes the token price prone to manipulation by the few whale holders. A report by Coopahtroopa and Lstephanian aggregated data from 60 projects and proposed some example allocation around "team 17.5%, investors 17.5%, early community (airdrop) 5%, ecosystem incentives (10%), treasury (50%)". A follow-up report by liquifi used different category definitions but reached similar conclusions on the significant stakeholder allocations of existing projects. There are also exceptions; in the so-called token "fair launch," the token is made available to every participant equitably and transparently. Therefore, there is no initial allocation to the team, investors, or any particular stakeholders. Yearn Finance used the fair launch approach. None of its YFI tokens were pre-allocated; anyone can obtain its initial token supply similarly by participating in its initial liquidity pool.

Distribute tokens to target stakeholders

A portion of the token supply is usually distributed to target stakeholders directly through pre-sales or rewards, and for various reasons, such as fundraising or community incentives.

Tokens not pre-allocated for initial distribution, such as those in the ecosystem incentives pool and the treasury, can be distributed to relevant parties on an ongoing basis, subject to the project's governance procedures.

Distributing a large amount of token supply at zero or low cost, possibly coupled with an inflationary token release schedule, could create unhealthy selling pressure and affect the token's supply-demand balance. People have used tactics rooted in game theory and economic mechanism design theory to cope with this problem, which we will discuss more in Part IV of this series.

Distributing tokens to investors

Token distribution to private investors is typically via discounted sales in exchange for their funding and taking high risks of being early in the project. The distribution of tokens to public investors faces more challenges due to the lack of legal clarity. Initial coin offering(ICO) used to be a widespread crypto crowdsourcing method until it received heavy regulatory scrutiny. In 2022, people commonly refer to the initial token launch as Token Generation Event (TGE). TGE usually makes the token available to the public and can take many different forms, such as Initial DEX Offering (IDO) and Initial Exchange Offering (IEO). Some teams come up with creative names to engage the public in raising initial funds. One example is JPEG'd. The project enables valuable NFTs owners, such as Cryptopunk holders, to use their NFTs as collateral to take out loans. Before its launch in late April 2022, the team conducted a so-called Token Donation Event in February. They let the public donate ETH to the project, and in return, these donors share a total of 30% of the project's native JPEG token proportionally.

Distributing tokens to the community and teams

Many crypto projects conduct initial free token distribution to relevant community members and core teams and use it to bootstrap the community or reward the core team.

A common way to distribute tokens for free is airdrop. To conduct a successful airdrop, a project needs to first identify the eligible recipient addresses. The addresses of the core team are straightforward to obtain, but getting the addresses of eligible community members can be much harder. The decision is usually made by the project governance, whether it is a centralized team or a decentralized governance body.

In the early days, many projects used the time when community members started interacting with their product as the primary threshold to identify loyal users. In many cases, these people backed the project even before it launched its token. Uniswap did it this way and airdropped its tokens to any wallets that had performed one or more interactions with it before its token launch date.
The drawback with the simple time-based eligibility mechanism is that it attracts people to game the system by creating multiple wallets, all conducting simple robot transactions to qualify for airdrops. Those people are not real users but are more akin to Sybil attackers. Later airdrops raised the reward qualification bar to require more meaningful interaction with the protocol, e.g., repeated and more realistic usage patterns, and have seen mixed but overall improved outcomes.
The Ethereum Name Service (ENS) airdrops are allocated to people who have been registrants of a ".ETH" domain account before a specific date. Since domain registration is a unique process that involves several steps and costs, it makes gaming the eligibility procedure less feasible.
Rarible is an NFT trading platform. It awarded weekly airdrops to its users when it started, dividing them among buyers and sellers based on their respective usage activities. This method seems reasonable but is soon exploited by people who conduct a lot of wash trading to bump up their activities for more rewards. These behaviors eventually led the protocol's governance vote to end the reward distribution mechanism.
In a more recent Optimism airdrop, the qualification mechanism is further elaborated. It consists of multiple rounds of airdrops and emphasizes the target's behavioral merits more than other aspects. Its first airdrop covers active early adopters of the Optimism system. Since Optimism is an L2 protocol for Ethereum, its airdrop also targeted active Ethereum participants who are most aligned with the project's goals, such as DAO voters, multi-sig signers, Gitcoin donors, and users bridged out of Ethereum but still use Ethereum regularly.
Narrowing down the exact target stakeholder profile is one route to identifying the desired airdrop population; the other way is to filter out the undesired members from an existing group. These members usually represent fake accounts created by Sybil attackers. HopDAO, for example, offers the user community rewards for reporting Sybil attackers. More interestingly, it allows Sybil attackers to self-report their bad behavior. As a result, these attackers can still receive the assigned rewards. If they do not cooperate in turning themselves in and are instead reported by others, they will receive nothing.
The token distribution criteria can also consider the performance of the user's actual service for the network. Covalent Protocol, a distributed network for blockchain data access, pays the nodes with its token for providing services in the network. Furthermore, the top performers in terms of latency and reliability may be given a multiplier for their rewards.

The effectiveness of airdrops has been questioned. Besides airdrop, another way to achieve token distribution without raising funds is lockdrop. Unlike airdrop, lockdrop requires the recipient to lock up some of their crypto assets for some time to receive the token rewards, so it introduces an opportunity cost for the token receiver. This method is usually beneficial for the project. For example, the lockdrop of Astroport, a decentralized exchange, requires community members to lock liquidity provider tokens to receive ASTRO token rewards. This process helped the protocol accumulate liquidity and, at the same time, achieve initial token distribution. Since the lockdrop recipients are essentially doing something to "earn" the tokens, it is a variant of the "staking and participation" value distribution model we will discuss in Part V of this series. The difference is that the locked assets are typically not the reward token itself (if the reward token is yet to be distributed) and that it may not involve slashing if no additional activities other than locking the token are required.

Deal with initial token liquidity

Liquidity determines how easy or difficult it is for users to buy or sell a specific token. Some people compare liquidity for Web3 projects to bandwidth for Web2 projects. If we think of a token economy as a city in the physical world, the amount of available liquidity may be analogous to the number of highway lanes connecting the city with the rest of the world. It is essentially the access portal to the token economy. A lack of liquidity would produce a "liquidity premium" and make the token trade at a discount to its intrinsic value. Improving liquidity may be done by leveraging professional market makers on centralized exchanges and providing deep liquidity pools on decentralized exchanges. But for newly launched tokens, a big challenge is to bootstrap the initial liquidity.

Determine liquidity pair

Before listing the token, we have to decide which existing token to pair with the new token. A typical choice is to use the infrastructure token of the blockchain where we launch the new token. For example, it will be ETH if the project is on Ethereum. This choice is because the infrastructure token is likely the most widely used in that blockchain ecosystem, and pairing with it maximizes the impact of initial liquidity. Another popular option is to pair the new token with stablecoins such as USDC, which makes it easier for people holding more stablecoins to limit their volatility exposure. Creating multiple liquidity pairs makes the new token more accessible but also spreads the overall liquidity of the new token among different pools. If the project has limited funding to seed the initial liquidity, it is wiser to concentrate on fewer main pairs.

Exchanges to list the liquidity

The token can be listed on various exchanges. Binance, FTX, and Coinbase are among the largest centralized exchanges. Each blockchain ecosystem also has its main decentralized exchanges. Uniswap is the largest on Ethereum, and PancakeSwap is the largest on Binance Smart Chain. Centralized exchanges generally impose a higher bar for token listing than decentralized exchanges. Many projects also hire professional market makers to lower slippage and provide deeper order book depth that further improves liquidity.

Initial price discovery

We need to have an initial price when listing the token in an exchange for public sale. A price discovery mechanism such as a Liquidity Bootstrapping Pool (LBP) is a way to determine this initial price. The way LBP works is to initiate the price at a high level. If no people buy, the price will come down until it reaches a level people deem appropriate to buy into. In addition to providing a permissionless price discovery, this method also helps raise funds during the process. It is similar to a pre-sale offered to the public. The funds received by the project from this LBP process can be used to supplement the required liquidity position when the token is later listed on an exchange. Balancer offers a popular LBP service and Copper has a user-friendly interface for participation in Balancer LBPs. Delphi Labs also designed a related Lockdrop + Liquidity Bootstrap Auction mechanism and used it for projects such as Astroport and Mars.

Without a proper public price discovery process, a project will need to directly come up with some token value estimations while balancing many factors, such as the initial amount of tokens to be released, available funds for initial liquidity, designed inflation rate, etc.

Renting more initial liquidity

When a token is launched, the team often wants to create more liquidity than they can afford by themselves. Therefore, many projects encourage external liquidity providers to supply the desired liquidity pair and pay them the project's new tokens. The new tokens paid out to these liquidity providers function similarly to rents and often come from the ecosystem incentives portion in the token allocation table.

A significant drawback of this model is that these rented liquidities are like mercenary capital. The parties providing them usually have no loyalty to the project itself. They can quickly dump the received project tokens and pull out anytime to seek higher yield opportunities elsewhere. This process is a form of yield farming. A 2021 statistic from Nansen shows that "A whopping 42% of yield farmers that enter a farm on the day it launches exit within 24 hours. Around 16% leave within 48 hours, and by the third day, 70% of these users would have withdrawn from the contract." As the farm and dump cycle causes the farmed token's price to tank, the farmers' yield further decreases, which leads to more dumping and accelerates the speed of farmers leaving the liquidity pools. Therefore, this liquidity approach is more useful only for a limited period, often after the immediate token launch.

Owning liquidity in the long-term

A more sustainable long-term liquidity solution is for projects to own a sufficient amount of their token liquidity. This concept is known as protocol-owned liquidity. Instead of giving out its tokens to rent liquidities, the project offers them at a discounted price and uses them to buy liquidity from third parties. OlympusDAO popularized this concept and provided its Olympus Pro service to help other protocols handle the process. Protocol-owned liquidity is considered a core theme of DeFi 2.0.

Conclusion

This article follows our prior discussion in Part I, and part II that covered "Why, When, What, Where, Who" of tokens. We discussed several important aspects of "How token", including determining the number of distinct tokens needed, token supply generation and allocation, token distribution to target stakeholders, and building token liquidity.

In the subsequent Part IV, we will close the W5H loop by focusing on the supply-demand dynamics, which is critical for the token project's ongoing sustainability.

Appendix:

A case study on determining the number of distinct tokens

We apply the steps mentioned in the earlier section to evaluate several decentralized stablecoin design projects and illustrate the process.

The main goal of a stablecoin is to peg its value with fiat currency such as the US dollar. We can identify the following specific list of objectives (O₁ through O₄) that may be facilitated by a token in a decentralized stablecoin system:

O₁: provide the stablecoin currency as the payment method
O₂: regulate the stablecoin price fluctuation and keep its peg with the US dollar
O₃: govern the protocol to determine system changes such as adjusting the regulating mechanism and its parameters
O₄: secure the blockchain infrastructure that deploys the stablecoin

According to the steps, we start by using a separate token for each objective. Specifically, we call them tokens T₁ for O₁, T₂ for O₂, T₃ for O₃, and T₄ for O₄. What might be some ways we can combine them?

Method A: assume we want to build on Ethereum so that the stablecoin will have immediate interoperability with the Ethereum ecosystem. This decision means token T₄ is ETH. What about tokens T₁ through T₃? There should be at least one token representing the stablecoin product, so token T₁ is needed. Next, notice the connection between holders of tokens T₂ and T₃. Users who participate in the peg regulation process likely also care about adjusting and optimizing the regulating mechanism. That means T₂ and T₃ token holders are closely aligned. Therefore, it may be possible to combine them into one. Is there a solution to that? That is the answer provided by MakerDAO. MakerDAO has two separate tokens. One is the stablecoin DAI (T₁). The other is MKR, the token for regulating the DAI peg (T₂) and governance (T₃).

Method B: Now, let us look at the list of objectives again. We know token T₁ must exist because it represents the product itself. T₄ is served by ETH if we decide to build on Ethereum. In method A, T₂ and T₃ are combined into one token. But the stakeholder of T₁ and T₂ are also aligned because keeping the stablecoin "stable" is exactly what people regulating the peg wants. Can one token be used for both T₁ and T₂? The answer maps to the AMPL protocol. It has the AMPL token as the stablecoin (T₁), and it adjusts the peg directly with AMPL (T₂). It also uses a separate governance token called FORTH (T₃).

Method C: Now, what if, instead of deploying the stablecoin on an existing blockchain, the team wants to create its own blockchain? Token T₁ is still a must-have. The regulating stakeholders of T₂ and the governance stakeholders of T₃ are both aligned in keeping the stablecoin peg. Furthermore, the stakeholders of T₄ who secure the blockchain also want the stablecoin application to succeed. So how about combining T₂, T₃, and T₄ into one token? That is what the (now collapsed) TerraUSD (UST) project did. UST is the stablecoin token (T₁). Its underlying blockchain, Terra, is a PoS chain secured by an infrastructure token, LUNA (T₄). Meanwhile, LUNA is also used to adjust the US dollar peg of UST (T₂) and for governance (T₃).

We can see from the above examples that many different combinations can be used to implement the same set of objectives.

So how is the most "substantial stakeholder interest alignment principle" reflected in the above designs? We notice that none of the three cases combine the stablecoin itself (T₁) and its governance (T₃). This decision is presumably because the stablecoin as a spending token is likely to have high velocity (frequency of circulation). The number of tokens people hold at a particular time reflects more of their needs for transaction size rather than their interest in governance engagement. In other words, the stablecoin users (stakeholder for T₁) and the stablecoin governors (stakeholder for T₃) do not necessarily share a close enough interest alignment (even though if the stablecoin collapses, they both suffer, so they do have a bottom line shared interest). In contrast, the stablecoin regulators (stakeholder for T₂) and the stablecoin governors (stakeholder for T₃) have a more obvious alignment.

We can also see the consequences of combining tokens at different levels of the network stack, such as infrastructure tokens and application tokens. Specifically, when an application token is also used as an infrastructure token that secures the blockchain, failure of the application token could damage the entire underlying infrastructure. This situation is literally what played out during the collapse of Terra UST/LUNA. The LUNA token is used to secure the Terra blockchain (as an infrastructure token) and keep the UST stablecoin in peg (as an application token). When the UST de-pegging sends LUNA value to nearly zero, the network's incentivized validation system can no longer sustain. The team had to halt the network several times to deploy remedies to prevent adversaries from taking over the network. Had it separated the blockchain validation token and the application token, or had the application been deployed on an existing battle-tested blockchain, the protocol would have had at least one fewer attack factor during the turmoil.

Last but not least, the decision on the number of tokens for the project does NOT guarantee the fundamentals of the token or the project. The token's success relies on a sound integration of all system components. Again in the UST/LUNA example, even if its LUNA token served purely as its application token, it would not have saved the project because of its flawed fundamentals.

This article is part of the six-part W5H framework for token design series, as listed below: