Tokenomics Fundamentals Series: W5H framework for token design, Part II - When, What, Where, and Who token?
Following the prior "Why token" discussion, we continue on to the "When, What, Where, Who" questions under the W5H framework for token design, and provide various examples.
This article is part II of the following six-part series:
Charles Shen, PhD, EMBA
This article continues our discussion of the W5H framework for token design. In Part I of this series, we discussed "Why token" through the crypto-product-market fit of a crypto project, looking at the roles crypto plays in the business and whether sustainable economic value is created. That helps us identify whether the project needs a token of its own.
In this article let us examine the "When, What, Where, and Who" tokens, as below:
When token?
If the need for the token is justified, we want to ask - when is the right time to launch the token? For a token with a specific utility, a rule of thumb is that the token should be launched when its utility becomes indispensable for the crypto project.
If a crypto project is producing direct tokenization of assets (Type B products as discussed in Part I), then those tokens are needed to enable the product launch itself. Examples could be a stablecoin that tokenizes one fiat dollar value, a token that represents a carbon credit, an NFT of certain artwork, or an NFT that serves as a social club membership credential.
When a token is used as an incentive for decentralized coordination at scale (Type C products as in Part I), we need to dig into the specific objectives that the token is incentivizing. If that objective is essential to enable the product at the current stage, then the token should be launched along with the product. One example is a token that maintains the security of the product. A Proof-of-Stake blockchain that uses its token as the validator stake token to secure the chain has to launch the token together with the product. Similarly, tokens that maintain critical security status at the application level (such as fulfilling the safety module in AAVE) could also justify the token launch with the product. Note that these cases assume a project uses its own token to achieve security. There might be other options that projects could consider, e.g., EigenLayer allows new crypto projects to enlist existing ETH stakers of the Ethereum blockchain to reuse those staked ETH in helping secure new projects.
If the token's purpose is not an integral part of the core business logic at least for the moment, then the time to launch the token deserves a careful second thought. One typical example in this category is a governance token that encourages community participation and provides decentralized ownership. This situation could apply to any project, whether it focuses on processing other cryptos, tokenization of assets, or decentralized autonomous coordination at scale (the type A, B, and C products defined in Part I).
On the one hand, a fundamental proposition of the Web3 vision is creating an "ownership economy" that enables the user community to govern and benefit from the platforms providing services. Issuing tokens is a vital way to achieve that. Li found that "on average, web3 companies that launched a token did so 2.7 years after founding; in 2020, VC-backed companies went public approximately 5.3 years after securing their first VC investment. The timeline of IPOs, compared to token launches, eliminates a significant amount of upside potential for retail investors."
On the other hand, while fully decentralized governance is a very appealing property for a Web3 project, it is often not necessarily the best option in many projects' initial phases. Most projects are started by a small number of core members. They build a crypto product and foster an engaging community. The agile team performs rapid iterations in the search for product-market fit. When there is a proven product and a growing community, the demand may start to outgrow the capacities of the core team. At that point, the team may gradually transfer ownership to the active community through tokenization and leverage the community's power to sustain its future growth. This process is known as progressive decentralization in building crypto. There are numerous examples of crypto projects that fall into this category. Uniswap was created in Nov 2018 but did not launch its governance token until September 2020. BAYC started with a hugely successful NFT launch in April 2021 and moved on to issue a governance token one year later in April 2022.
It is also worth noting that not launching a token at the beginning of the project does not need to sacrifice rewarding early community members. Blockchain records retain user activities and can be used to identify wallet addresses that have interacted with the crypto project from its inception. This property is how Uniswap can still distribute 15% of its UNI token total supply to its past users even though they launched the token almost two years after its service. In the case of BAYC's ApeCoin, 15% is also given to existing users who already own BAYC and Mutant Ape Yacht Club (MAYC) NFTs of the project.
What token?
If it is time to launch the token, we need to consider further what type of tokens they should be. There are many ways a token can be classified based on its different properties. We discuss a few main categories here:
Fungibility:: One important feature of the token is its fungibility. Fungible tokens are exchangeable with one another. Non-fungible tokens (NFTs) have unique properties that result in different values. Both types are popular and have significance. The choice between fungible tokens and NFTs depends on their purpose. We can look at some examples:
- Tokens serving currency utility are fungible by their nature. BTC and ETH are both fungible tokens.
- Governance tokens are more commonly fungible; e.g., UNI is the governance token of Uniswap. The BAYC community, which started as an NFT project, launched its fungible ApeCoin token for governance.
- Tokens providing gatekeeping utility are typically non-fungible because they represent a pass or ticket for a specific event or club. BAYC NFTs are the access tokens for Bored Ape Yacht Club. But not all access tokens need to be NFTs. Friend with Benefits is another social club that uses a threshold amount of its fungible FWB tokens for gatekeeping.
- Tokens that enable participation with rewards may be both fungible and non-fungible. Filecoin's work-to-earn model allows operators who stake fungible FIL tokens to provide file storage services. At the same time, the Axie Infinity game requires users to own Axie NFTs to join the play-to-earn model of the game.
- Tokens used as borrowing collaterals can be either fungible or non-fungible as long as the underlying token asset is deemed valuable. ETH and BTC are fungible tokens that can be collateral assets. Bluechip NFTs like Cryptopunk can also be used to borrow assets.
While it seems from the above list both fungible and non-fungible tokens could be used in most cases, there are still a couple of rules of thumb that could be helpful:
- Fungible tokens are preferred when both the token quantity and exchangeability matter.
- Cryptocurrency tokens used for payment naturally fall into this group. Many work-to-earn models that provide commodity services also apply here because putting up a more significant amount of collateral may reasonably lead to higher reward opportunities.
- Governance tokens are a bit more complicated. The quantity of governance tokens provides a way to differentiate the weight of governance rights. However, exchangeability might not always be a desired feature for governance tokens since sometimes we might not want governance rights to be exchanged among random parties.
2. NFTs emphasize the unique properties or utilities without necessarily stressing the relative quantity of tokens, e.g., gatekeeping tokens like BAYC or collectibles such as Cryptopunks. However, note that quantity differentiations can still be realized by using multiple NFTs if needed.
Transferability: In most cases, a token owner can transfer their tokens to other wallets or people whenever they want. These tokens are transferable. However, there are situations where it may be desirable to disable token transferability. Ethereum co-founder Vitalik calls these non-transferable tokens soulbound tokens. The best example that suits this category is POAP, which stands for proof of attendance protocol. POAPs are NFTs that prove the recipient personally attended some event. If POAPs can be easily transferred, people can obtain them without actually participating in the event, thus defeating the token's purpose. Another category that may desire non-transferability is governance. When governance rights need to be limited to a specific group of people, disallowing token transfer prevents unauthorized people from obtaining those tokens.
Security vs. utility: Whether a token is a security or not has important legal implications for a token issuer. While many tokens can be seen as commodities with certain utilities, other tokens may function as securities. For example, they can represent ownership investment in companies similar to traditional financial securities and may be subject to similar security regulations. A well-known method to determine whether a token is a security or not is the Howey Test. It contains four main criteria: "an investment of money, in a common enterprise, with the expectation of profit, to be derived from the efforts of others". The Crypto Ratings Council is an organization that evaluates many of the major crypto tokens and rates their likelihood of being classified as securities.
Where token?
In the "Where token" question, we can explore which layer of the blockchain network stack the token should reside.
Tokens can be grouped into infrastructure vs. application-level tokens. Infrastructure-level tokens are integrated parts of the corresponding blockchain itself. These tokens typically play a key role in securing the blockchain and are often used as the native currency token for transactions on the blockchain. As the industry evolves, the blockchain infrastructure has also differentiated into what people call layer 0 (L0), layer 1 (L1), and layer 2 (L2). Subsequently, people start to refer to blockchain applications on top of the infrastructure as layer 3 (L3).
The most well-known infrastructure tokens are BTC for the Bitcoin blockchain and ETH for the Ethereum blockchain. Other examples include BNB for Binance Smart Chain, AVAX for Avalanche blockchain, SOL for Solana blockchain, and ADA for Cardano blockchain. They are all L1 blockchains.
L2 blockchains are created in response to the scalability trilemma. It states that, with "simple" techniques, one can only get two out of the three properties - scalability, decentralization, and security. L1 blockchains that offer a high degree of security and decentralization may have to suffer the cost of scalability. L2s are developed to improve the scalability of L1s, and they typically inherit the security of their corresponding L1 blockchains. Thus, L2s may not need a token for their own economic security purpose. But they can still launch a token, e.g., for incentives. These L2 tokens could also be considered infrastructure-level tokens as they belong to part of the environment where applications are deployed. Among the well-known L2 solutions for Ethereum L1, Polygon has its MATIC token (originally used by the Polygon Ethereum sidechain), and Optimism issued its OP token. Other L2 players such as Arbitrum, zkSync, and starkNet do not yet have their tokens as of late 2022.
L0 blockchains refer to a group of crypto projects focusing more on providing interoperability among various blockchains. Polkadot and Cosmos are two examples that fall into the layer 0 categories, and the DOT token and ATOM token are their infrastructure tokens.
Where a token should be launched depends on the nature of the crypto project. If it is an infrastructure project, it could build its own L0, L1, or L2 blockchains. Most crypto projects, which are L3 applications, can directly deploy their application-level tokens on existing L1 or L2 blockchains. The underlying blockchain usually provides specific workflows to make issuing these tokens easier. Ethereum, for instance, has standards for creating fungible tokens (ERC20) and non-fungible tokens (ERC721), as well as a more recent standard for both fungible and non-fungible tokens (ERC1155). Tokens based on these standards are immediately interoperable within the entire Ethereum ecosystem.
It is worth mentioning that there are currently considerable discussions on monalithic vs. modular blockchains. It takes a different perspective and divides a blockchain system into several component layers: execution layer that acts on smart contacts and processes transactions; settlement layer where transaction validity is verified and finality occurs; consensus layer that keeps transactions in order; data availability layer that makes sure all transaction data in blocks available for all the nodes in the network. Most of the mainstream blockchains, including Bitcoin and Ethereum, are monolithic blockchains that integrate all these component layers. However, L2s can be considered modular execution layers. Ethereum with L2s is a partially modular structure with improved scalability than the original monolithic chain. Ethereum is also building its danksharding horizontal scaling to support higher data availability throughput. There are also projects such as Celestia, Polygon Avail, and EigenDA that are building separate modular data availability and consensus layer, without the execution component layer. These developments of modular blockchain layers have led to increasing interest in building application-specific blockchains (AppChains).
The AppChain approach gives an application technical sovereignty the ability to customize different layers of its blockchain stack, thus allowing it to improve performance and value capture. There are already several infrastructures available to facilitate building AppChains, such as Cosmos Zones, Polkdot Parachains, Polygon Supernet, and Avalanche Subnet. Appchain tokens can be used for staking and validating their network and for app-specific purposes. However, the AppChain paradigm also has limitations, such as reduced composability and fragmented liquidity that require additional bridging infrastructure and add friction and security concerns. Axie Infinity implemented its Ronin AppChain as an Ethereum sidechain to accommodate the explosive growth of the game's transaction throughput demand. It suffered a bridge hack that cost $622M in March 2022.
Besides bridge risks, the security of the AppChain itself could be vulnerable if it only uses its application token as a stake to secure the chain. One ongoing trend to alleviate this AppChain economic security problem is leveraging shared security from more established infrastructure, Cosmos's interchain security, and Eigenlayer 's ETH re-staking mechanisms are examples.
Overall, the majority of applications will still be more likely to launch on L1s and L2s, while AppChains are more appropriate for certain types of applications that have reached scale and product-market fit, poised to benefit significantly from a dedicated blockchain stack, and with fewer constraints on security and atomicity. There have been plans or discussions on some high-profile projects' AppChains strategies. dYdX, originally running on Ethereum L2, has announced building its dYdX chain on Cosmos. The team expects the move to benefit substantially from the potential dYdX AppChain's "unique combination of decentralization, scalability, and customizability." There have also been suggestions on Uniswap building its AppChain that have triggered some debate.
Who token?
The "Who token" question examines the target stakeholders for the token. Tokens are a vehicle that can align the interests of all the parties interacting with the associated crypto economy. We want the parties creating value and helping grow the economy to own and retain the token. Usually, we should already have a candidate list of ecosystem participants when looking at the crypto-product-market fit problem in the "Why token" question.
Many projects make explicit token allocations to the following three categories of participants:
- Team: team members could include core developers, operations, marketing, advisors, etc. They spend time helping build the product.
- Investors: investors include both private and public investors. Private venture capital investors are a significant source of crypto project funding.
- Community: community is a broad group for the crypto project. We can segment it in different ways to serve the project development needs better.
- Roles-based: community members could play different roles. For example, in a two-sided marketplace business model, there are community members who serve as the suppliers and others as end users. In a decentralized exchange like Curve Finance, the supply side is the liquidity providers, and the end users are people who swap crypto at the exchange. The liquidity providers are crucial to ensure a low-slippage swapping service.
- Time-based: if the project already has an existing community built up before its token launch, it is common to reward those users separately to thank them for backing the project early. As the project grows, it is more important to reward current and future users, so the ongoing user group is another important category. For example, Stepn is a Web 3 lifestyle app that combines social-Fi and Game-Fi elements. It rewards its users for walking, jogging, or running outdoors and allocates 30% of the total supply for users carrying out these activities.
- Merit-based: projects may also identify users who contribute most to the ecosystem; the metrics depend on the specific application. Bankless is a DAO that creates media content and aims to be a steward of the decentralized Web3 vision. They reward participants with the BANK token for their contributions, and these tokens also become their access badge in the community. There are other DAOs, such as Rabbithole and Layer3, that aggregate token bounty opportunities set up by different DAOs for contributing to them. The significance of contributor-based token rewards is expected to grow further.
In addition to the above three categories, most crypto projects reserve a specific token allocation for two additional purposes:
- Treasury: a crypto project often keeps a portion of its token and other crypto assets in its treasury. This treasury is intended to be the reserve capital governed by the community for future initiatives that drive the long-term growth of the project. This practice is especially common when the project is decentralized and governed as a DAO.
- Ecosystem incentives: these tokens could also be part of the treasury, but sometimes they are explicitly allocated. It can be used to incentivize parties who play essential roles in the growth stage of the project. Prominent examples are liquidity providers who make it easier for people to trade the token with other crypto assets at lower slippage, especially at the early stage of token launch.
Conclusion
This article expanded our "Why token" discussion in Part I of the series to the "When, What, Where, Who" of the W5H framework for token design. Since a token cannot be separated from its underlying business and crypto-economy, all these questions should be examined first at the business level and then applied to the token level.
- The initial "why" step covered in Part I is about looking at the business model, whether it is tackling a problem in the real economy or the financial economy. We identify what role crypto plays in this business (crypto-product fit) and how the business can produce sustainable economic values (product-market fit). Depending on the crypto business model and operating strategy, we can decide whether or not a token is needed.
- If the project indeed needs a token, the "when" step checks about the right time for the token release. Tokens that are part of the core product itself have to be launched along with the product release; tokens serving separate roles, such as governance, may be deferred if progressive decentralization is desired.
- The specific token types are examined at the "what" step. There are numerous dimensions we can categorize tokens. We discussed a few important classifications, such as fungible vs. non-fungible tokens, transferable vs. non-transferable tokens, and utility vs. security tokens.
- The "where" step discusses the blockchain network stack that the token should be deployed. Depending on whether the token serves as part of an infrastructure or application, it may be launched as one of the infrastructure layers (L0, L1, L2s) or at the application layer (L3) on top of existing infrastructure layers. We also looked at the implication of modular blockchain development and AppChains on token deployment.
- The desired main categories of stakeholders to own the tokens are examined in the "who" step. They usually include the development team, community, investors, and the project's own treasury.
In the follow-on article, we will dive into the "How token" question.
This article is part of the six-part W5H framework for token design series, as listed below: