Introduction: Tying it back to the token
In this section, we’ll design how value is shared and distributed amongst network participants. The goal of the design and “value flows” is to catalyze a series of positive feedback loops to promote further growth and decentralization of your project.
A token is intrinsically linked to multiple aspects of your project, such as how it handles value being created, ties (or does not) into the business model, and how it is integrated into the system, determining its use case (or token utility).
Similarly, a token is intrinsically linked to the multiple user types interacting with your project. It's imperative to understand these users' motivations and what they will do to create effective incentive mechanisms that will lead to user-project alignment and sustainability.
What makes a good token design?
There are examples of good token design; it can be helpful to contrast and compare to your design. If properly implemented and in the correct scenario, a token will embody the characteristics below:
- The token is core to the product and does not add friction to the user experience.
- The token enables a network to grow bigger and faster than its centralized counterparts.
- The token model works (or can evolve to work) in both bootstrapping and equilibrium modes.
- The token aligns incentives tightly across all of its stakeholders.
- The token promotes 3rd party developers building on top of the protocol instead of forking away
- The token does not extract unnecessary rent but rather just the right amount.
- The token is not too complex for the average person to understand.
Compensation
One of the critical tenets of tokens is their ability to act as a reward. We have talked about how incentives are a form of reward, in the space of web3 these incentives take the form of tokens, thus incentives are a form of compensation. Compensation for what? Value.
Sinks & Faucets
A technical way to describe supply and demand is with faucets and sinks.
A faucet is an increase in the circulating supply of tokens – more tokens hit the market and are available for usage or purchase.
A sink is a decrease in the circulating supply of tokens – the removal of tokens from the circulating supply, or the requirement to hold tokens to conduct some activity or access some service.
Faucets and sinks will be used extensively to predict token price performance following your project’s token generation event (“TGE”). The influence that supply and demand have on token price is covered extensively in the Go-to-Market Strategy phase.
Steps to designing a token
We will take you through the following steps to complete the central part of your token design.
- Who receives tokens: Token Distribution Schedule.
- Over what timeframe are tokens released: Token Emission Schedule.
- Who buys tokens: Token Demand Drivers.
- At what price will the token be sold, or offered to the public: Token Valuation.
Primer on token price
We will dive a lot deeper into price and its discovery later in this guide, but here is a brief intro.
Tokens in Web3 can be traded permissionless between users via protocols such as Uniswap, Curve, THORSwap, Pancakeswap, and Jupiter. Centralized exchanges such as Binance, Coinbase, and OKX can also facilitate the trading of tokens between prospective buyers and sellers.
If something is tradeable, it means that it must have a price (i.e., an agreed-upon US Dollar value between the two parties involved in the trade), thus tokens are subject to the laws of supply and demand. These laws stipulate that price is the intercept of supply and demand on a graph.
The most important thing to remember at this stage is that determining the price of your token is an iterative step. Token price will determine the value of your project, so it is a critically important exercise; however, you don’t have to nail this on the first try. You'll start with something that sounds right in the Determining your Valuation section and work through some additional steps before circling back and making adjustments once we model things out.
All tasks related to Tokenomics, including the supply side and demand assumptions are also iterative. As you read on, you'll learn more and grasp more of the nuanced concepts. These learnings will help you make more informed and productive design choices as you go back and make adjustments.
Resources and further reading
Token Distribution Schedule
The first part of a project’s “Faucets” is its “Token Distribution Schedule” i.e. who receives tokens. A token’s Distribution Schedule dictates the issuance of tokens to various individuals and stakeholders within a protocol. For example, 15% of a project’s “Total Token Supply” may be allocated to Employees, 25% to liquidity mining rewards, 20% to airdrops for testnet participants, 20% to Seed & Private investors, 15% to marketing, and the remaining 5% to market making.
Most will be familiar with the pie-chart display of a tokens supply allocation. This is the most common representation of a Token Distribution Schedule.
Whereas the capitalization table of a traditional company can evolve over time based on the creation of new shares and dilution of existing shareholders, a Token Distribution Schedule will dictate upfront how all tokens will be allocated. At a high level, allocations of tokens within a Distribution Schedule fall into two categories:
- Internal allocations
- External allocations
The difference between an internal allocation and an external allocation is, as the names indicate, who the allocation is being distributed to and for what reason.
Internal allocation essentially means any “insider” receiving tokens: Some examples of internal allocation include the below:
- Team allocation
- Private investor allocation (ex: Seed or Private investors such as Venture Capital, Angel Investors, etc.)
- Advisors allocation
- Treasury allocation
External allocation essentially means any “outsider” receiving tokens. Some examples of external allocation include the following:
- Liquidity mining rewards
- Staking rewards
- Community incentives
- Airdrops
The reason we make this distinction is that the way you reward insiders vs outsiders normally differs, and for good reason. It helps to think of tokens here as compensation. In other words, people are performing a task that they wish to get compensated for. However, depending on who the person is and their alignment with the project, a certain type of distribution model has to be put in place to make sure that they are aligned with the best interest of the project.
For example, Private Investors such as Venture Capital funds often view their “internal allocation” as a potential return on investment source. The potential to sell tokens for profit is their “compensation” in exchange for their early capital contribution to the project and the risks borne. In contrast, Staking rewards are a form of “compensation” distributed to individuals actively holding and delegating tokens to secure the integrity of the underlying network.
Helpful Prompts
- What is the total number of tokens that will be allocated to both insiders and outsiders? (this is known as the Maximum Token Supply)
- What insiders will you be allocating supply to? How many tokens will you allocate per internal allocation?
- What outsiders will you be allocating supply to? How many tokens will you allocate per external allocation?
Resources and further reading
Commentary on Constructing Your Token Distribution Schedule
Creating an initial draft of your Token Distribution Schedule can feel daunting. You'll be taking an initial pass in the task for this section. When completing this task, leverage our "recommended" groups and associated % allocations (pre-populated based on best practice) as a baseline while you read on.
Like token pricing, you don’t have to nail this on the first try. Start with a list of suitable groups, and work through the remainder of this guide. Once you learn more and grasp more of the concepts, you can (and should) return, add/remove groups, and adjust the token allocation aligned to each.
Some common groups featured across internal & external allocations in projects' Token Distribution Schedules are featured below:
Team
- Core Contributors (i.e., full time employees of "labs" or "foundation")
- Advisors Investors
- Seed Investors
- Private Investors DAO Treasury
Ecosystem Incentives
- Staking rewards
- Liquidity Mining rewards
- Airdrops
- Incentivized TestNet ("ITN") Rewards
Marketing & KOL support
- Centralized exchange listing, co-marketing
- KOLs and influencers
Liquidity Provision (ex: Market Maker loans or trading deposits, assets allocated to seed liquidity pools)
Launch Distribution
- Public Sale (ex: IEO, IDO, ICO, LBP)
Some best practices and guardrails to consider:
Communities tend to look favorably upon projects that allocate a large percentage of their maximum token supply to incentives. This is perceived as a way to promote decentralization and "give back" to project supporters that perform the key tasks and activities required to scale the network.
It's worth stating the obvious that the "pie" only has 100% that can be allocated. Ecosystem incentives are essential, but allocating too many tokens to groups such as staking rewards and airdrops will draw down from allocations earmarked for other groups.
Communities will not look favorably upon projects that allocate a large percentage of their maximum token supply to insiders, especially "team". Projects generally categorize team allocations as "Core Contributors" to position the token distributions as a means to incentivize protocol development (from both full-time employees and open-source developers).
TL;DR: Early employees need to have "skin in the game" as a way to align their upside with the future success of the protocol. Token allocations are essential for this and will also help alleviate operational (cash) burn used for base compensation and benefits. The allocation to early employees should not be so large that it negatively impacts a protocol's ability to incentivize network participation and therefore diverges from Web3's core ethos of decentralization.
In 2022, investors received roughly 17.5% of a project’s token supply on average. If you can secure a high Fully Diluted Valuation ("FDV") and don’t need much capital, this percentage allocation can be kept low, which will then free up tokens to be used elsewhere. Methods of fundraising will be discussed later in the guide.
If you intend to raise capital, earmark some portion of your maximum token supply for these efforts. It's best to anchor higher than might be necessary and then have excess tokens to reallocate to other groups vs. the alternative which would require you to cannibalize / rehypothecate tokens from other groups to facilitate the fundraise.
Liquidity provision refers to various activities to support Secondary market liquidity for your token once it is listed on CEXs and DEXs. Activities may include extending loans to professional Market Makers and seeding decentralized AMM liquidity pools. Nuances related to Liquidity Provision will be discussed later in the guide.
Tokens allocated to marketing and community engagement aim to expand a project's user base in a "B2B2C" capacity. For example, a project may partner with a notable institution such as a centralized exchange, or a Twitter influencer in order to access this partner's established community. The type of activities might include trading competitions on CEXs, "Learn & Earn" promotions, Twitter giveaways, sponsored reviews from research desks, and other similar activities.
While tokens allocated to this group can technically be considered "Ecosystem Incentives" its important to create a distinct group for these activities - even if the token allocation is small. The reason for this is that the Token Emissions Schedule for this group tends to differ from most Ecosystem Incentives. Emissions, unlocks, and vesting schedules will be discussed in the next section.
Tasks
Create a list of all "groups" of token recipients in your Token Distribution Schedule. Assign a % of the Maximum Token Supply to each group.
You can enter up to 20 different "groups" to receive tokens as part of your project's Distribution Schedule. Don't feel compelled to use this many groups. You definitely won't need more than this, so if you find yourself wanting to add more rows, you're probably getting too granular when thinking through your Distribution Schedule. Indicate "N/A" for any rows that are not utilized.
Next, assign each group a percentage of the Maximum Token Supply. Make sure the total percentage allocated across all groups equals 100%. Indicate 0% for any rows in any groups labeled as "N/A". Don't worry about the quantity of tokens each group is set to receive; instead, think of your Maximum Token Supply as a "pie" and this current exercise being our way to determine how we will slice this pie amongst your guests.
NOTE: When completing this task, leverage our "recommended" groups and associated % allocations (pre-populated) as a baseline while you read on. You can return and adjust these figures as you give the Distribution Schedule more thought.
Token Emissions Schedule
The second part of a project’s “Faucets” is its “Token Emissions Schedule.” A token’s Emissions Schedule determines the manner and rate at which tokens enter circulation. As tokens enter circulation, the supply of tokens available to the public increases; more available tokens mean more buyers are required to keep the price at a stable level.
Most will be familiar with the stacked area time series chart used to visualize tokens “unlocking” or “vesting” over time. This is the most common representation of a Token Emissions Schedule, sometimes referred to as an "Emissions Curve."
Generally, there are two ways to time a distribution, each with its own set of parameters:
Linear emissions schedules release tokens at some pre-determined frequency over a set period of time. For example, tokens may be released on a daily, weekly, or monthly schedule for a period of 2 years following an initial unlock. The same quantity of tokens is unlocked or "vested" at each interval.
The exception to this is an "initial unlock" which may result in a "chunky" portion of a group's token allocation being unlocked during an initial vesting period.
Additional Terminology:
- Percentage unlock at TGE refers to the amount of this allocation that will be unlocked at the token generation event.
- Lock period refers to how long the tokens are going to be locked or non-tradable. These tokens are not in the hands of any users at this point.
- Unlocking period, also known as a vest, refers to the period by which tokens will be released linearly (e.g., release 100 tokens per month for 10 months).
NOTE: Linear schedules should be easy to understand if you have experience with equity grants or options at a startup. This type of equity allocation usually carries a 4 year vesting period with a 1 year "cliff", and a monthly linear vesting thereafter. Converted to crypto terms, this would mean that the tokens have a 1 year lock period, with 25% unlocked at TGE + 1 year and the remaining 75% unlocked on a linear basis, every month, for the next 36 months.
Log based emissions schedules release tokens at some pre-determined milestone over a set period amount of milestones. These milestones are referred to as "epochs" and generally represent some type of on-chain activity. The amount of tokens unlocked or "vested" at each epoch varies based on the methodology used by a project but will generally decrease over time. For example, Bitcoin's block rewards follow a log based emissions schedule with the quantity of BTC distributed to miners halving every 4 years. This will log based emissions schedule will continue until the year 2140 when all 21,000,000 BTC are mined.
Additional Terminology:
- Epoch duration in seconds refers to the time that each epoch lasts for.
- Initial emission per second refers to the number of tokens that are to be released per second in the epoch.
- Emission reduction per epoch refers to the percentage reduction in the emissions per second to be changed per epoch.
Internal allocations normally follow a lock & vest emissions schedule. The reason for this structure is that you want to prevent insiders from abandoning a project.
Unlike traditional equities markets, the core team associated with a blockchain project has no (legal) fiduciary responsibilities to other “shareholders.” Given that a token generation event (“TGE”) essentially serves as the cryptocurrency equivalent of an initial public offering (“IPO), (unlocked) tokens allocated to core team members can potentially be sold on the open market as compensation for the core team’s “sweat equity”.
Accordingly, lock & vest emissions schedules serve to align the long-term interests of insiders, minimizing the potential for such predatory behavior. For example, the core team associated with a blockchain project may be allocated 10% of the project’s total token supply with a 2-year lock cliff and a 48-month linear vest. *_Leaving early would be counterproductive to their interests since it puts the project's future – and by extension, the value of their tokens – in jeopardy._* This is all a fancy way of suggesting that lock & vest emission schedules minimize the likelihood of a core team “rugging” their community.
External allocations normally follow an emissions schedule that is directly tied to the operation of the underlying protocol. It is recommended to be coupled with some form of mechanism that acts as a requirement for the user to receive the reward. For example, a fixed quantity of tokens may be distributed pro-rata to all token holders delegating their tokens to a Proof-of-Stake consensus mechanism.
Alternatively, participants in a project’s “testnet” may be eligible to receive an “airdrop” of tokens if they complete a set of tasks. These tasks may be helpful for the core team to perform quality assurance (“QA”) testing and debug the protocol before launching their mainnet. Airdrops are usually conducted as a “lump sum” emission of tokens to various participants; therefore, the allocation of tokens is facilitated all at once, rather than gradually over a fixed period.
The reason for various emissions schedules for each group of recipients in a Token Distribution Schedule is due to the nature of tokens representing tradable value. For example, if tokens are distributed to an individual, and that individual sells the tokens, their selling pressure will affect the token's price and thus the value of the project itself.
Internal and external allocations have emissions schedule to protect the project’s long-term value. External allocations are emitted over time as users provide value to the protocol. Internal allocations have a lock & vest structure to ensure long-term alignment. In both cases, unique Token Emissions Schedules influence how token supply hits the market and limit downside token price action caused by selling.
Helpful Prompts
For each group of internals & externals set to receive tokens via the Token Distribution Schedule, you'll need to think through:
- Will they receive a percentage of their allocation unlocked at TGE? If so, how much?
- Note that some tokens must be circulating at TGE for the project to transition from the Primary market to the Secondary market and become freely traded. This is discussed in the Go-to-Market Strategy phase of this guide;
- Note that the circulating token supply at TGE will be used to determine your project’s Market Capitalization. Market Capitalization is calculated by multiplying “Token Price” by “Circulating Token Supply” and is generally denominated in US Dollar terms. Market Capitalization is sometimes used as a proxy for a project’s valuation alongside its Fully Diluted Valuation (“FDV”). Each concept is discussed in the Valuation section.
- If no tokens are unlocked at TGE, how long will their tokens be locked for?
- Once tokens begin to unlock, how long of a period will they vest/unlock for?
Resources and further reading
Commentary on Constructing Your Token Emissions Schedule
Creating an initial draft of your Token Emissions Schedule can feel daunting. You'll be taking an initial pass in the task for this section. To simplify things at this point, we highly recommend using only linear emissions schedules (i.e., lock & vest) as they are much easier to conceptualize. We'll share some recommendations on linear emissions schedules to help you with your initial draft.
Like token pricing and your Token Distribution Schedule, you don’t have to nail this on the first try. Start with schedules that feel right, and work through the remainder of this guide. Once you learn more and grasp more of the concepts, you can (and should) come back and adjust the emissions schedule assigned to each group.
Some best practices and guardrails to consider:
Token price is a function of supply & demand. When you think about the rate at which your token's supply will increase over time, try to consider the feasibility of demand increasing at an equal or greater rate. Instead of thinking about a Token Emissions Schedule as a "check the box exercise", think of it as a sanity check on your revenue estimations.
For example, if your token supply doubles in the first year following your TGE, then doubles again in the second year, and continues this trend for the next three years, then demand for the token would also need to consistently double each year to keep pace. This represents a 16x multiple or a 1,500% increase in demand over five years. While this rate of growth is certainly not unattainable, it's a very high bar to set for an upstart company trying to achieve product-market fit in a hyper-competitive industry.
If you fail to balance token supply and demand it may have damning implications on your token price performance. You cannot simply dole out tokens as incentives or provide aggressive unlock schedules to investors, advisors, and team members without having sufficient demand to absorb them. If supply outpaces demand, token price will fall and therefore hurt the monetary incentive power of the tokens. Creating demand for a token is the key to balancing the supply/demand dynamic and will be discussed in the upcoming sections of this guide.
NOTE: Supply & demand, and token price performance will be discussed at much great length later in the guide, but these concepts are definitely worth considering as you take an initial pass at drafting your Token Emissions Schedule.
This will prevent against the potentially damning phenomena of "low float; high FDV" (discussed later in the guide). Tokens unlocked at TGE should come from a variety of "groups" - some Internal Allocations and some External Allocations.
As a general rule of thumb, External Allocations such as "airdrops", and "Public Sale" tokens will be actively traded and heavily circulated immediately following TGE. In contrast, Internal Allocations such as "DAO Treasury" will likely remain locked; therefore, while they are technically considered as part of the token's Circulating Supply, the tokens will be inaccessible to most market participants.
Your vesting and lock duration for Internal Allocations will be heavily scrutinized by the community. Longer lockups and vesting periods will satisfy community FUD and provide them with confidence that Core Contributors are not conducting a rug pull; however, the tradeoff is that these elongated emissions schedule will not be as attractive for top-talent seeking compensation for their sweat equity.
The emissions duration for Ecosystem Incentives such as staking, validator rewards, and other essential "rewards" to encourage network participation should be long enough to ensure the sustainability and integrity of the protocol.
If network participants stop receiving incentives, there is a chance that some of them "drop off" and cease desirable tasks needed to scale the protocol. If the drop off rate is too extreme, you'll negatively impact your project's growth before it can stand on its own. 7 - 10 years should provide you with an adequate buffer to find Product Market Fit and iterate on your business model so that incentives do not need to be offered in perpetuity.
If you choose to raise capital via a token sale (i.e., SAFT), then early investors will be granted the opportunity to purchase tokens at a favorable valuation. The emissions schedule assigned to the tokens purchased by early investors will be a critical point of negotiation. In general, the more favorable the valuation, the less favorable the emissions schedule. This means that Seed Investors will need to wait a long time for tokens to unlock, and once their lock period is over, they'll need to wait an even longer time for them to fully vest.
In contrast, later stage investors will receive less favorable valuations. To compensate for this, the investors will likely negotiate for a more favorable (i.e., shorter) emissions schedule.
For early investors, aim for a 1 year lock up with a 2 - 3 year vest. For later stage investors, use your discretion and prioritize for locking in a favorable valuation or securing the desired amount of Growth Capital over the emissions schedule. Aim for 6 - 9 months lock up with a 1 - 2 year vest.
Tasks
Determine a Token Emissions Schedule for each "group" of token recipients in your Token Distribution Schedule.
All groups of token recipients from the previous task have been imported here. For each group, values to indicate the following:
- Lock up duration: How many days will the tokens allocated to this group be locked for before they begin to vest? For example, if you want some tokens to be unlocked at TGE, input a value of "0" in column I. Similarly, to indicate tokens will be locked for a period of 1 year, input a value of "365" in column F.
- Vesting Duration (No. of Months): Once tokens begin to unlock, how long of a period will they vest/unlock for? For example, if you want tokens to vest for a period of two years, input a value of "24" in column G.
- Vesting Frequency: At what frequency should tokens unlock / vest throughout the duration of the vesting period? Column I features dropdown selections for daily, weekly, or monthly frequencies which will allow you adjust the cadence at which tokens will be released to each particular group.
Token Value Capture
Value capture relates to how a project captures the value it creates. Value capture is made up of two types of value accrual: (1) value accrual to the protocol via a percentage of revenue /assets/value being directed to the treasury (and thus being owned by the project) and (2) value accrual to the token via supply/demand dynamic (demand due to utility, demand mechanisms, etc.)
Helpful Prompts
What value is captured by the project (if any), and what value is captured by the token (if any)
Resources and further reading
Tasks
Explain how value is captured by both your protocol and token.
Think back to the responses provided in the Value Creation section of Finding Product Market Fit. Your responses here will have identified the positive implications of each users' actions within your ecosystem. This "raw value" is essentially up for grabs thanks to the solution that your project offers to its target audience.
Start by responding to how value is captured by the protocol before moving on to the token. Completing this task will require you to think critically about how that "raw value" is harassed and pulled back to the project and token.
NOTE: If you cannot think of a response to "Value Capture by Token", don't be alarmed. Some tokens lack a clear mechanism by which the value generated by users and captured by the protocol will accrue back to the token. For example, pure Governance Tokens often lack a clear "Value Capture by Token."
Demand Drivers
A project’s Token Distribution & Emissions schedules are the two inputs that comprise its “faucets” (i.e., aspects of Tokenomics that increase the circulating supply of tokens). Faucets and supply-side aspects of Tokenomics represent one side of the equation influencing token price.
The other side of the equation is represented by “sinks.” Sinks encompass the demand side of the equation (i.e., aspects that reduce the circulating supply). In the absence of sinks integrated within your Tokenomics design, the price of a token will depreciate as supply floods the market and eventually collapse due to a lack of market demand.
The consequences of poor token price performance can be damning for a project – for example, incentives offered via external allocations in the Token Distribution Schedule become less attractive in US dollar terms; therefore, it becomes more difficult to catalyze desirable behavior from target customers and bootstrap widespread adoption. Accordingly, developing the demand side of your project’s Tokenomics is critically important.
When assessing the demand side of a project’s Tokenomics, start by asking a simple series of questions:
What motivates individuals or institutions to purchase your project’s token?
Do people buy the token based on its inherent utility or for speculative purposes?
Do they believe in some function of the token, or do they think the price will increase and they will be able to sell for a profit at some later date?
In sum, demand for a token comes from three main sources, referred to as demand drivers. Demand drivers stimulate and promote the appetite and willingness of individuals to purchase and hold your token.
Types of Demand Drivers
| Demand Driver | Description of Demand Driver |
|---|---|
| Utility | The utility of a token is directly related to its usefulness and is often associated with spending, consuming, or holding tokens to accomplish some core activity within the blockchain project. Simply put, if a blockchain project provides a meaningful service and its native token is essential for users to operate within that project, that token likely has value and demand.Individuals are driven to buy tokens with high utility because they need them to access the products or services offered by the project. Recall that a token's necessity or “essentiality” can be seen as a spectrum with two ends.At one end, the token is "necessary" for the project to function, while at the other end, it is not. For example, tokens on the not-necessary side may offer governance rights or revenue shares, which are not crucial to the product's core functionality. On the necessary end of the spectrum are tokens like Ethereum, Bitcoin, Solana, and other Layer 1’s. These tokens are essential to the product's functionality. |
| Demand Mechanisms | A demand mechanism is a method, process, or requirement that encourages users to buy a token, thus creating demand. For example, suppose a blockchain project offers a revenue share mechanism to token holders. In that case, the users may be incentivized to buy and “stake” the token to receive a portion of the total revenue generated by the protocol.:brDemand Mechanisms are closely linked to Utility but do not always mirror it. For example, a revenue share mechanism may stimulate demand for a token for users wanting to generate yield on their tokens – especially if the protocol generates significant revenue and, therefore, offers attractive yield (i.e., high APR%)., despite holding tokens offering the potential to receive attractive returns, holding tokens is not necessarily ESSENTIAL to access the protocol. In short, it's a “nice to have” but not a “need to have.” If the yield and revenue potential are high enough, holding tokens may seem like a no-brainer, but it is still not required to access the protocol. |
| Speculation | Individuals are driven to buy the token because they believe it will appreciate.:br |
The three demand drivers in the table above are ordered for how much control the project has over each type of demand, from most control to least control. For example:
- Utility: Projects have the most control over the utility of their native token.
- Demand mechanisms: Next, while projects indeed have control over incentives offered to users, they have no control over whether or not end users want to purchase tokens due to the presence of these incentives.
- Speculation: Finally, projects have minimal control over speculative demand since this encompasses many aspects such as behavioral economics and psychology – each of which is out of the direct control of a project (as it relates to Tokenomics design – clever marketing can influence speculative demand, but this is outside the scope of Tokenomics).
An important consideration is that some projects have an incentive mechanism that introduces supply to the market that also has a demand driver aspect.
Take the following example: A project may introduce a staking program to incentivize its users to hold a token for a long period. The staking program rewards users with some yield (i.e., APR%) denominated in tokens in exchange for staking. The staking program is the project's way of encouraging holdability of the token. Thus, this incentive mechanism is acting as a form of supply (since it's emitting tokens in exchange for a certain task) but also as a form of demand since users will be attracted to these incentives and thus have to buy and stake the token to receive them, thus creating demand.
The two tables below will provide you with a comprehensive (but not exhaustive) list of demand drivers from Utility and Mechanisms.
Utility as a Demand Driver
| Name of Demand Driver | Description | Key Considerations |
|---|---|---|
| Gas Fees | Native token must be spent to transfer assets or transact on the protocol | Is there a high demand to transfer assets or transact on the underlying protocol? |
| Fee Discounts | Holding the token grants users access to discounted fees when trading or transacting on the protocol. | What is the price sensitivity of the user base currently transacting on the protocol? How much of an impact (financial and psychological) might fee discounts have on the end user? |
| Restricted Access | Holding the token is required to access the protocol’s products and offerings. | Is the protocol valuable enough to justify gating access to anyone who does not hold the token? Will this barrier to entry deter potential users and inhibit ecosystem growth/adoption? |
| Governance | Users are attracted to acquire the token due to the governance rights that it entails. | There is no easy way to discern token demand for governance. Still, we can look at similar projects to analyze their holder base and see what percentage of circulating supply they hold. Generally speaking, we can assume that the more tokens one holds, the more invested said user is in seeing the project succeed; thus, we can assume that these larger holders bought due to governance. |
| Collateralization | Users can provide their tokens as collateral in return for some form of yield. | Users are attracted to stake the native token (which can be used as collateral by the project) due to the staking yield they can earn. This will result in a certain percentage of the circulating supply being staked. Therefore, based on the monthly yield you wish to target, we can look at similar projects to analyze the percentage staked of circulating supply at that moment. This is what we will take to be token demand due to collateralization. |
| Network Security | Node operators must acquire and stake certain tokens to secure the network. This will result in a certain percentage of the circulating supply being taken out of circulation. | Based on the expected validator set growth and token requirement per validator, we can look at similar projects to analyze what that percentage of circulating supply is. This is what we will take as token demand due to network securing. |
Mechanisms as a Demand Driver
| Name of Demand Driver | Description | Key Considerations |
|---|---|---|
| Locking | Users lock tokens to earn a yield. | This will result in a certain percentage of the circulating supply being locked. Therefore, based on the monthly yield you wish to target, we can look at similar projects to analyze the percentage locked of circulating supply at that moment. This is what we will take to be token demand due to locking. |
| Staking | Users stake tokens to earn yield. | This will result in a certain percentage of the circulating supply being staked. Therefore, based on the monthly yield you wish to target, we can look at similar projects to analyze the percentage staked on circulating supply. This is what we will take to be token demand due to staking. |
| Liquidity Provisioning | Users provide liquidity to earn yield. | This will result in a certain percentage of the circulating supply being put into a liquidity provider position. Therefore, based on the yield you wish to target per month, we can look to similar projects to analyze the percentage of circulating supply provided to a liquidity position. This is what we will take to be token demand due to liquidity provision. |
| Bond | Users are attracted to bond assets due to the discount on $XYZ token over the market price. | This will result in a certain percentage of the circulating supply being bonded. Therefore, based on the discount and vest period we can look to similar projects to analyze the percentage bonded of circulating supply at that moment. This is what we will take to be token demand due to bonding. |
| Taxing | Users have to pay tax on transactions denominated in the project token. | This will result in a certain percentage of the circulating supply being taken out of circulation. Therefore, based on volume and tax rate (tax fee) we can look to similar projects to analyze what that percentage of circulating supply is. This is what we will take to be token demand due to taxation. |
Helpful Prompts
- What utility will your token have? What is your token used for within your product? This could include gated access, fee reduction for token holders, etc.
- What demand mechanisms will your project have? What makes the token a more desirable purchase? This could include Buybacks, burn mechanisms, etc.
Resources and further reading
Tasks
Create a list of "demand drivers" for your token based on its utility and mechanisms.
This task will help you think through how demand to purchase (and hold) your token will actually be created once your TGE occurs. You can enter up to 20 demand drivers on this tab, and we recommend starting with at least three. For each demand driver, write a brief description, and identify the "type" of demand driver as either "Utility" or "Mechanism". Indicate "N/A" in column C for any rows that are not utilized.
Estimating Demand also includes examples of demand drivers from popular projects such as Uniswap, dYdX, GMX, Thorchain, Lido Finance, Helium, and others. Feel free to leverage these examples as you draft your own.
Don't try to identify demand drivers related to "speculation" at this point. If you find yourself struggling to identify clear demand drivers outside of speculation, this is a great catalyst for revisiting the Token Evaluation section of "Designing the Core Business". Recall that a token can have a variety of use cases and benefits such as:
- Secure a network, such as via staking (e.g.Proof-of-Stake)
- Bootstrap supply sides of networks
- Create a tangible incentive for coordination among dispersed parties (e.g. what we see with many DAOs)
- Decentralize/distribute governance
- Fund public goods
- Incentivize positive externalities within an ecosystem
- Reward participants for contributions to a network
- Coordinate & create insurance pools
- Form digitally-native units of account (aka internet money)
- Track & build an on-chain reputation (eg via SBTs)
- Create new digital identities (via NFTs)
- Give users a share of ownership in the network
- Membership gateway
- Proxy for underlying value
- Rebates
NOTE: Don't try to quantify demand at this point. We'll cover that in the next task.
Estimating Token Demand
There is no way to predict demand with absolute certainty. No crystal ball will tell you how many people will want to buy your token; however, we can approximate market-wide demand by analyzing individual demand drivers and breaking them down into their sub components.
For example, demand for a token related to "Gas Fees" can be determined by estimating monthly transaction volume (i.e., on chain token transfers) and multiplying this value by the percentage fee charged on each transaction. As transaction volume increases, fees derived from gas will increase in a linear capacity. Thus, the more on-chain activity your project generates, the greater the demand for the token.
Some demand drivers are easier to estimate than others. To determine the demand generated from Gas Fees, we can assume the monthly transaction volume of a token by estimating the "turnover" of its circulating supply. Given that the circulating supply is determined by the Token Emissions Schedule; we have all the available tools to make an informed guess on this demand driver at this point.
In contrast, quantifying other demand drivers will require us to take more creative liberties. For example, Governance demand drivers are a function of a token's "holderbase" and the growth of that holderbase. The appetite of any community member to purchase a governance token and hold it will depend entirely on how important they deem governance to be, and what sort of upside they anticipate from participating in said governance. Aside from that, it will be hard to clearly attribute demand to just governance, as many holders might see governance just as a bonus.
The table below will provide you with a comprehensive (but not exhaustive) list of demand drivers from Utility and Mechanisms. For each demand driver, calculation metrics and a calculation template are provided. The task for this section will be to quantify each of the demand drivers you've listed for your project. You can review the table briefly before moving on. The task will have you reference the calculation templates for any relevant demand driver.
| Name of Demand Driver | Type | Calculation Metrics |
|---|---|---|
| Gas Fees | Utility | Monthly transaction volume, percentage fee on each transaction |
| Fee Discounts | Utility | Monthly transaction volume, discount height, discount floor price |
| Restricted Access | Utility | Membership size, Membership growth, tiers, users per tiers, token requirements per tier |
| Governance | Utility | Holderbase & growth |
| Collateralization | Utility | Percentage staked of circulating supply |
| Network Security | Utility | |
| Locking | Mechanism | Lock period, percentage of supply locked |
| Staking | Mechanism | Percentage of supply staked |
| Liquidity Provisioning | Mechanism | Transaction volume, transaction value, transaction fee, and percentage of supply |
| Bond | Mechanism | Discount rate, vesting period, percentage of supply bonded |
| Taxing | Mechanism | Transaction volume, tax fee |
Helpful Prompts
- What protocols can you analyze in a similar niche that have similar token utility?
- What protocols can you analyze in a similar niche that have similar demand mechanisms?
Resources and further reading
Tasks
Quantify the demand from each of the "demand drivers" you listed in the previous task
Each of the demand drivers you indicated from the previous task have been ported here. The goal for this task is to quantify the demand for each aspect of Utility and Mechanisms you've identified.
You can quantify demand for each demand driver using either an "Advanced Calculation" or a "Basic Calculation".
Advanced Calculations leverage templates created by Forgd to help approximate demand from Governance, Token Buy Backs, and, Staking. For example, Token Buy Backs will utilize a monthly revenue prediction and a percentage of the revenue you want to dedicate to buy backs.
Other advanced calculation templates, such as demand from Governance are more complex and will use the percentage of circulating supply participating in governance of a comparable project to approximate potential demand for your project.
For example, the recent 5 GMX governance proposal have resulted in 5-7% of circulating token supply participating in governance. We can use the percentage to simulate the demand for our project, assuming similar popularity.
Basic Calculations can be utilized if you already have assumptions on market sizing and potential market penetration for your project. When utilizing a Basic Calculation, first indicate if demand should be denominated in "US Dollars" or " Quantity of Tokens", next input an estimation on demand that will exist for the first month post-TGE, and finally input an estimate on month over month ("M-o-M") growth rate as a percentage.
NOTE: Estimating demand will be an iterative exercise, and we'll definitely be revisiting this task later in the guide. Remember, is no way to predict demand with absolute certainty and crystal ball will tell you how many people will want to buy your token based on the demand drivers you create. This exercise will lay the foundation for us to think through your project's supply & demand dynamics once a TGE occurs.