Author: Charles Shen @ inWeb3.com
In the first two articles, we have discussed the five "Ws" of the W5H framework: "Why, When, What, Where, Who". Among them, "Why" explores the rationale for tokens and the sustainable value creation of the crypto economy behind them; "When" discusses the best time to issue tokens; "What" studies the types of tokens suitable for specific purposes; "Where" focuses on which blockchain network the token should be created on; "Who" examines which participants in the ecosystem are suitable to own tokens.
In this article, we will continue to explore "How to design tokens". Admittedly, the discussion on "How to design tokens" can be very broad. This article will discuss several key issues, including how many different tokens are needed, how to generate and allocate token supply, how to distribute tokens, and how to build token liquidity.
The "dual token model" is a widely used model in which governance functions and non-governance functions are carried by two different tokens. A typical example is the Axie Infinity game, where the AXS token plays a governance role and the SLP token is used as the in-game currency. However, the dual token model is not a one-size-fits-all solution, as tokens have utility far beyond governance and currency.
Here is a general approach to this problem:
List all the goals we want the token to achieve (e.g. specific product features or incentive goals). This information should be obtained from the "Why do we need a token" step in the first part of this series.
Assume that each goal is assigned a separate token.
Explore whether some tokens can be combined based on the alignment of interests of potential holders.
Iterate technical solutions to ensure that the required business logic is implemented while making token integration possible.
Also consider other properties of each candidate token, such as fungibility, application and infrastructure, etc.
When making this decision, there are a few important things to keep in mind:
The final outcome of the decision is highly dependent on the actual solution implementation, and even for similar products, the results can vary widely.
The level of stakeholder alignment is key to determining whether multiple goals can be combined into the same token.
Combining goals at different levels of the network stack introduces additional risks that require special attention.
The decision about choosing different tokens is only part of the design, and it does not guarantee that the project's foundational structure is sound.
In the appendix to this article, we use case studies of several decentralized stablecoin projects to show how the above steps can be applied and reflect on the manifestation of these considerations in the actual process.
Once we have determined the tokens we want to create, the next step is to consider how to generate and supply them.
Maximum Supply:When developing a token generation schedule, we first need to decide whether the total supply of the token will be finite or infinite. This decision alone does not determine the health of the token design, as what really matters is the ongoing balance between supply and demand.For example, among the major cryptocurrencies, Bitcoin (BTC) has a fixed maximum supply of 21 million, while Ethereum (ETH) has an unlimited supply. Some projects set a maximum supply based on the estimated number of holders to avoid fractional quantities of tokens, such as Ankr, which has a maximum supply of 10 billion.
Minting Schedule:While all tokens can be minted at once, it is more common to gradually increase the maximum supply over time, as this is more conducive to regulating supply.There are two main ways to achieve this: minting on demand or emission on a schedule. For example, MakerDAO's stablecoin DAI can be minted at any time by providing corresponding collateral, and there is no fixed minting schedule or supply cap. The Bitcoin blockchain generates a block approximately every 10 minutes, creating new Bitcoins in each new block, and this process will continue until the maximum number of Bitcoins is reached.
Allocation table:Projects usually develop an allocation table to clarify how the token supply will be allocated to different major stakeholders. It is worth noting that we do not want token holdings to be too concentrated, because excessive concentration may make the token price vulnerable to manipulation by a few large holders.For example, a report by Coopahtroopa and Lstephanian summarized data from 60 projects and proposed some allocation examples, such as 17.5% for the team, 17.5% for investors, 5% for early communities (airdrops), 10% for ecological incentives, and 50% for finance. A subsequent report by liquifi, although using a different classification definition, also came to similar conclusions. There is also the so-called "fair launch" exception, where the tokens are provided to all participants in a fair and transparent manner, so there is no allocation to the team, investors, or any specific stakeholders in the initial stage. Yearn Finance has adopted this fair launch approach, with no pre-allocation of YFI tokens, and anyone can obtain its initial token supply by participating in its initial liquidity pool.
A portion of the token supply is often distributed directly to specific stakeholders through pre-sales or rewards, for a variety of purposes, including raising funds or for community incentives.
For tokens that are not pre-allocated for initial distribution, such as those in ecosystem incentive pools and treasuries, they can be distributed to relevant stakeholders on an ongoing basis according to the project's governance process.
Distributing large amounts of tokens at little or no cost, especially in the context of a token issuance schedule with inflationary expectations, can create adverse selling pressure and disrupt the supply and demand relationship of tokens. To combat this problem, strategies derived from game theory and economic mechanism design theory have been adopted, which we will explore further in Part 4 of this series.
Distributing tokens to private investors is usually done through discounted sales in exchange for their high-risk initial investment in the project. Distributing tokens to public investors is more challenging due to legal ambiguity.Initial Coin Offerings (ICOs) were once a widely adopted method of crypto crowdfunding, but this method has been restricted due to strict regulatory scrutiny. In 2022, people often refer to initial token issuance as a token generation event (TGE). TGEs usually make tokens available to the public and can take a variety of forms, such as initial DEX offerings (IDOs) and initial exchange offerings (IEOs). Some teams come up with some very creative names to attract public participation in raising initial funds. For example, the JPEG'd project allows those who own valuable NFTs, such as Cryptopunk holders, to use their NFTs as collateral to obtain loans. Before the project's launch in late April 2022, the team held an event called a "token donation event" in February. They invite the public to donate Ethereum (ETH) to the project, and in return, these donors will share 30% of the project's native token JPEG in proportion.
Many crypto projects will distribute tokens to relevant community members and core teams for free in the early stages, with the aim of launching the community or rewarding the core team.
Airdrops are a common way to distribute tokens for free.Before a successful airdrop, the project needs to first determine the eligible recipient addresses. While it is relatively simple to obtain the core team's address, it may be more difficult to determine the eligible community member addresses. This decision is usually made by the project's governance body, whether it is a centralized team or a decentralized governance body.
In the early stages of a project, many projects use the time when community members begin to interact with the product as the main basis for identifying loyal users. For example, Uniswap airdropped tokens to wallets that interacted at least once before the token launch date.
A drawback of simple time-based eligibility is that it can attract people to qualify for airdrops by creating multiple wallets and performing simple bot trades, which are not actually real users, but more like people performing Sybil attacks. Therefore, subsequent airdrops have raised the barrier to participation, requiring more meaningful interactions with the protocol, such as repetition and more real usage patterns, resulting in an overall improvement.
Ethereum Name Service (ENS) airdrops are allocated to people who registered a ".ETH" domain before a certain date. Since domain registration is a unique process involving multiple steps and costs, this reduces the possibility of manipulation of the eligibility process.
Rarible, an NFT trading platform, initially allocated weekly airdrops based on the trading activity of buyers and sellers. This seemingly reasonable approach was quickly exploited by large-scale order-scaling to increase their trading volume and obtain more rewards. This behavior ultimately led to a vote by the protocol governance to end this reward allocation mechanism.
Optimism's latest airdrop further refined the eligibility mechanism, covering multiple rounds of airdrops and placing greater emphasis on the behavioral merits of the target users. Its first airdrop covered active early adopters of the Optimism system. Since Optimism is a second-layer protocol for Ethereum, its airdrop also targets active Ethereum participants who are highly aligned with the project's goals, such as DAO voters, multi-signers, Gitcoin donors, and users who are still actively using Ethereum.
Accurately defining the target stakeholder group is one way to identify the intended airdrop population; another way is to filter out unwanted members from the existing group, which are often fake accounts created by Sybil attackers. For example, HopDAO provides rewards to the user community for reporting Sybil attackers, and allows Sybil attackers to self-report their misconduct, so that these attackers can still receive allocated rewards. If they do not report themselves but are reported by others, they will receive nothing.
Token distribution criteria can also take into account the actual performance of users in providing services to the network. The Covalent Protocol is a distributed blockchain data access network that pays nodes that provide network services with tokens. In addition, the best performing nodes in terms of latency and reliability may receive additional reward multiples.
The effectiveness of airdrops has been questioned. In addition to airdrops, another way to achieve token distribution is through lockdrops. Unlike airdrops, lockdrops require recipients to lock up some of their crypto assets for a period of time to receive token rewards, which creates an opportunity cost for the token recipients. This approach is generally beneficial to the project. For example, the lockdrop of Astroport, a decentralized exchange, required community members to lock up LP tokens to receive ASTRO token rewards. This process helped the protocol accumulate liquidity and achieve initial token distribution at the same time. Recipients of lockdrops are actually "earning" tokens, which is a variation of the "stake and participate" value distribution model we will discuss in part 5 of this series. The difference is that the locked assets are usually not the reward tokens themselves (if the reward tokens have not yet been distributed), and there is no penalty involved if there are no other activity requirements.
Liquidity is a key factor in determining how easy it is for users to buy and sell a particular token. Liquidity for Web3 projects can be likened to bandwidth for Web2 projects. If the token economy is like a real-world city, then available liquidity is like the highway connecting the city to the outside world. It is basically the gateway to the world of token economy. Insufficient liquidity may cause a "liquidity premium", which causes the token to trade at a discount to its intrinsic value. Methods to increase liquidity include leveraging professional market makers on centralized exchanges and building deep liquidity pools on decentralized exchanges. But for newly launched tokens, launching initial liquidity is a major challenge.
Before listing a token, we need to decide which existing token the new token should be paired with. A common practice is to choose the infrastructure token of that blockchain as the pairing object. For example, if the project is on Ethereum, ETH is usually chosen as the pairing. The reason for this choice is that infrastructure tokens are usually the most widely used in the blockchain ecosystem, and pairing with them can maximize the effect of initial liquidity. Another popular choice is to pair with stablecoins, such as USDC, which is more convenient for holders who want to reduce volatility. While creating multiple liquidity pairings can make new tokens more accessible, it will also disperse the overall liquidity of the new token into different pools. If the project has limited start-up funds, it would be wiser to focus on a few major pairings.
A token can be listed on multiple exchanges. Binance, FTX, and Coinbase are among the largest centralized exchanges. Each blockchain ecosystem also has its major decentralized exchanges, for example, Uniswap is the largest on Ethereum, and PancakeSwap is the largest on Binance Smart Chain. Centralized exchanges often have stricter standards for listing tokens than decentralized exchanges. Many projects also hire professional market makers to reduce trading slippage and provide deeper order books to further improve liquidity.
When a token is sold publicly on an exchange, we need to set an initial price. A liquidity bootstrapping pool (LBP) is one way to determine the initial price. The way an LBP works is that it starts at a higher price, and if there are no buyers, the price will drop to a level that people find suitable to buy. In addition to providing a permissionless price discovery mechanism, this method also helps to raise funds in the process, similar to a public pre-sale. The funds obtained through the LBP process can be used to supplement the liquidity required for the subsequent listing of the token on the exchange. Balancer provides a popular LBP service, while Copper provides a user-friendly interface to participate in Balancer's LBP. Delphi Labs also designed Lockdrop + Liquidity Bootstrap and applied it to projects such as Astroport and Mars.
In the absence of a suitable public price discovery mechanism, projects need to directly estimate the value of the token, while balancing multiple factors such as the number of tokens initially issued, initial liquidity funds, and preset inflation rates.
When a token is released, the team often wants to build liquidity beyond its own financial resources. Therefore, many projects encourage external liquidity providers to supply the required liquidity trading pairs and pay them with newly issued tokens of the project. These new tokens given to liquidity providers play a role similar to rent, usually derived from the ecological incentive part of the token allocation table. A major flaw of this model is that these rented liquidity are similar to mercenary capital. Providers usually have no loyalty to the project itself and may quickly sell their tokens in search of other higher-yield opportunities. This practice is known as yield farming. According to 2021 data from Nansen, 42% of yield farmers exited the day a project launched, about 16% left within 48 hours, and by the third day, 70% of users had withdrawn. This cycle of farming and dumping caused token prices to plummet, further reducing farmers' returns and accelerating their exit from the liquidity pool. As a result, this liquidity strategy is only effective in the short term, usually just after the token is issued.
A more continuous long-term liquidity solution is for projects to hold sufficient token liquidity themselves, which is called protocol-owned liquidity. Instead of using tokens to rent liquidity, it is better to sell tokens at a discount and use these tokens to buy liquidity from third parties. OlympusDAO popularized this concept and helps other protocols implement this process through its Olympus Pro service. Protocol-owned liquidity is a core theme of DeFi 2.0.
This article continues our discussion of the “why, when, what, where, who” of tokens in Part I and Part II. We delved into several key aspects of “how to design a token”, including determining the number of different tokens needed, generating and configuring the token supply, distributing tokens to key stakeholders, and building token liquidity. In the upcoming Part IV, we will focus on the dynamics of supply and demand, completing the W5H framework. The dynamic balance of supply and demand is a key factor in ensuring the continued sustainability of token projects.
Case Study: How to Determine How Many Different Tokens a Project Needs
We apply the steps mentioned in the previous sections to evaluate several decentralized stablecoin design projects and demonstrate the process.
The core goal of a stablecoin is to have its value pegged to a fiat currency such as the US dollar. We can identify several specific goals (O1 to O4) that can be achieved by using tokens in a decentralized stablecoin system:
O1: Provide stablecoins as a means of payment
O2: Regulate the price volatility of stablecoins and maintain their peg to the US dollar
O3: Governance protocol, decide on system changes, such as adjusting regulation mechanisms and parameters
O4: Ensure the security of the blockchain infrastructure on which stablecoins are deployed
Following these steps, we start designing a separate token for each goal. Specifically, we call them T1 tokens for O1, T2 tokens for O2, T3 tokens for O3, and T4 tokens for O4. How can we combine them?
Method A: Let's say we want to build on Ethereum and make stablecoins interoperable directly with the Ethereum ecosystem. This means that the T4 token is ETH. So what about T1 to T3 tokens? At least one token is needed to represent the stablecoin product, so the T1 token is needed. In addition, notice the connection between the T2 and T3 token stakeholders. Users who participate in the peg adjustment process may also care about the adjustment and optimization of the adjustment mechanism. This shows that the interests of the T2 and T3 token stakeholders are highly aligned. Therefore, it may be possible to merge them into one. Is there a solution? MakerDAO has the answer. MakerDAO has two independent tokens, one is the stablecoin DAI (T1), and the other is the MKR token (T2 and T3) used to regulate the DAI peg and governance.
Method B: Look at our list of goals again. Obviously, the T1 token is necessary because it directly represents the product itself. If we choose to build on Ethereum, then T4 will be held by ETH. In Method A, we have merged T2 and T3 into one token. However, the interests of the stakeholders of T1 and T2 are also aligned, because keeping the stablecoin stable is exactly what the stakeholders of T2 are pursuing. So, is it possible to have one token that fulfills the functions of both T1 and T2? The AMPL protocol provides an example. In this protocol, the AMPL token is both a stablecoin (T1) and is directly used to regulate its peg (T2). In addition, it uses a separate governance token, FORTH (T3).
Method C: What if, instead of deploying a stablecoin on an existing blockchain, the team wants to create their own blockchain? The T1 token is still necessary. The T2 stakeholders responsible for regulation and the T3 stakeholders responsible for governance are both committed to maintaining the stablecoin's peg. At the same time, the T4 stakeholders responsible for ensuring the security of the blockchain also want the stablecoin application to succeed. So, is it possible to consider merging T2, T3, and T4 into a single token? This is exactly the approach taken by the TerraUSD (UST) project. UST is a stablecoin (T1), and its underlying blockchain Terra is a PoS chain supported by the infrastructure token LUNA (T4). At the same time, LUNA is also used for UST's USD peg regulation (T2) and governance (T3).
Through these examples, we can see that there are many different ways to combine tokens to achieve the same set of goals.
How does the “principle of alignment of interests of important stakeholders” manifest itself in the above designs? In none of the three cases does the design combine the stablecoin itself (T1) with its governance (T3). This may be because stablecoins are often circulated frequently as trading tools. The number of tokens people hold reflects their demand for trading volume more than their willingness to participate in governance. This means that the interests of stablecoin users (T1 stakeholders) and stablecoin governors (T3 stakeholders) are not completely aligned (although they both suffer if the stablecoin fails, so they do have some common bottom line interests). In contrast, there is a clearer alignment of interests between stablecoin regulators (T2 stakeholders) and governors (T3 stakeholders).
We can also see the consequences of merging tokens at different levels of the network hierarchy, such as the distinction between infrastructure tokens and application tokens. For example, when an application token also acts as an infrastructure token that protects the blockchain, if there is a problem with the application token, it may cause damage to the entire infrastructure. This is exactly what happened in the Terra UST/LUNA debacle. The LUNA token was used to secure the Terra blockchain (as an infrastructure token) and maintain the USD peg of the UST stablecoin (as a utility token). When the UST depeg caused the LUNA value to drop to almost zero, the network’s incentivized validation system could not continue to function. The team had to pause the network multiple times and take steps to prevent adversaries from taking over the network. If the blockchain validation tokens were separate from the utility tokens, or the applications were deployed on an existing, battle-tested blockchain, the protocol could have at least one less attack vector during this turmoil.
Finally, decisions about the number of tokens a project has are no guarantee of the fundamental soundness of the token or project. The success of a token depends on the effective integration of all components of the system. Using the UST/LUNA example again, even if the LUNA token was solely a utility token, the project could not be saved due to flaws in the fundamental design.
Wormhole's new multi-chain governance allows W token holders to vote on proposals across various chains. Users can stake and delegate their governance power flexibly. Despite past challenges, W token sees a surge in price and trading volume.
EdmundIn previous parts of the Token Economics Basics series, we discussed the “Why, When, What, Where, Who, and How” of token design.
JinseFinanceWormhole unveils roadmap for W token launch, embracing Solana and EVM chains. Features include native token transfers, locking, delegation, and DAO governance. Aiming for decentralized future in blockchain governance.
EdmundExciting news from Binance: Wormhole (W) joins trading lineup on 03.04.2024, with no listing fee and multiple trading pairs. Get ready to trade!
Huang BoFor tokens with a specific utility, a rule of thumb is - a token should be issued when its utility is essential to the crypto project.
JinseFinanceBinance plans to reduce LUNC trading fees from 100% to 50%. LUNC reacted negatively, shredding 12% on the day.
cryptopotatoAn easy-to-understand informative piece about wETH (Wrapped Ether).
NellThe firm, whose data centers are located in the United States, generated $40 million in sales last year.
CointelegraphH2O Securities, an infrastructural firm based in South Africa, generated $150 million to introduce crypto water tokens. The company landed ...
BitcoinistSports-related NFTs need to provide some tangible benefits or else sports fans will just view them as another ploy to exploit their fan loyalty.
Cointelegraph