Rethinking Emissions Schedules
What are Emissions and Emission Schedules
Anyone who has messed around with DeFi has come learned that much of the ‘yield’ you earn from lending, borrowing, providing liquidity, etc. comes from token emissions. Token emissions are the extra incentive that protocols add to different strategies in order to get people to use their protocol. They usually provide their own token (governance token or utility token, or farming token…) as this extra incentive. Many people call this ‘bootstrapping TVL’, which you can think of as ‘renting’. What I mean by ‘renting’ is that a protocol has to pay, out of their own treasury usually with their own token, people to use their protocol. This isn’t a bad thing! Companies in general go through different customer acquisition strategies depending on what industry they are in. We have learned in DeFi that token emissions do work to bootstrap TVL, but we also know that once those emissions are lowered, people may leave that protocol. Some people will use the term ‘mercenary capital’ as a way to describe these users who farm token emissions, dump the token, and then move on.
Many protocols create an ‘Emissions Schedule’. This is a stated amount of tokens that will be given to users of the protocol, whether it be people who deposit into lending pools, borrow, provide liquidity to a DEX, etc. The schedule states that this week or month, ‘x’ amount of tokens will be given, then next week or month, ‘y’ amount of tokens will be given, etc. Here is an example of Curve’s emissions schedule, here is Raydium’s, and here is Trader Joe’s. Its pretty standard for a protocol to put out a schedule that states up front, for many months, if not years, the fixed emissions to be distributed. But, are fixed emission schedules really the optimal way to bootstrap TVL, rent liquidity, and reward your users?
Dynamic Emissions Programs
I believe it makes more sense to have an emissions schedule that is dynamic. Dynamic means that the emissions in the next period could go up or down; they are not fixed and tied to a stated schedule.
The goal is to not overpay for whatever purpose you are using emissions (raising TVL, acquiring users, incentivizing trading, etc.) Different protocols have different needs. But most protocols can be thought of as a business. Protocols should be trying to raise their revenue, and consider token emissions a cost. Any emissions schedule, static or dynamic, if implemented incorrectly, could ruin a protocol, even if the protocol logic is amazing (Solidly…) So maybe we need to consider different measures of the utility of emissions. We could think about metrics like monthly Emissions / monthly Revenue or monthly Emissions / average TVL over the month. We would want to target a certain realistic Revenue or TVL, then try and minimize the emissions needed to achieve that goal.
DEX Example
Let’s consider a DEX, and we will call them Dextr, with a token DEXTR, and uses the 50–50 CPMM model. Dextr charges 0.3% per swap and keeps 0.05% for their Treasury, and that is their main source of revenue (they may do other things like be a launchpad, etc., but for simplicity lets focus on the swap fee as the sole revenue source). Dextr knows that they need to incentivize users to provide liquidity to their Liquidity Pools, so that there is minimal slippage for a certain pair of tokens. People won’t swap through Dextr if there is high slippage, which means Dextr won’t earn their fees. So Dextr really needs deep liquidity = low slippage = more people swapping = more fees = more Revenue.
Dextr knows this, so they want to create an emissions program that is dynamic to their evolving DeFi Ecosystem. Let’s say there are a max supply of 1B DEXTR, and the team has allocated 50%, so 500M, to Yield Farming/Liquidity Mining. The Dextr team could go forward and create a static Emissions Schedule, like the example below. However, this type of static emissions schedule does not react to the evolving market conditions of the ecosystem and the protocol.
What if Dextr decided to implement a dynamic emissions program. Below is a simple, formulaic example of a dynamic emissions program. This program is based on month over month Average TVL change. If the month over month average TVL change is negative, increase emissions by (MoM change / 4). If the month over month average TVL change is positive, decrease emissions by (MoM change / 2). For this example, I randomized the TVL starting at 100M, then used a uniform distribution to be between previous month TVL +/- 5M.
Not that this dynamic emissions program (in the stylized example) lasts much longer than 48 months, it takes 86 months until the 500M DEXTR cap is reached.
We can compare the Static Emissions Schedule (blue lines below) to the Dynamic Emissions Program (orange lines below). The first chart below shows the Emissions/TVL for both (measured in DEXTR). You can think of this measure as the cost per unit of TVL. We want this measure to be lower , meaning we pay less DEXTR per 1 TVL (measured in DEXTR).
From Month 10 to month 48, the Dynamic Emissions Program has a lower Emissions/TVL. And it lasts an additional 38 months longer! Also note that part of the reason you want to be reactive/dynamic is to hopefully increase your odds of capturing more TVL. This exercise conservatively assumes that the TVL is the same regardless of if Dextr implemented a static schedule or a dynamic program.
We can also see the APR from farming (liquidity mining) of the Static Emissions Schedule versus the Dynamic Emissions Program, using the same randomized TVL numbers for both. The dynamic program has higher APR from months 2–10, then lower from months 11–48, then (mostly) higher from months 49–86. That last period has a couple months where emissions are 0. But if there are still emissions left to be distributed, the dynamic program can reinstate emissions in months where average TVL falls month over month, until the 500M DEXTR cap is reached.
Ideas are Inputs to a Dynamic Emissions Program
Below are some ideas/examples of metrics and scenarios that could factor into a Dynamic Emissions Program.
- If the DeFi ecosystem is growing in general, maybe the team wants to capture a certain percentage of total DEX TVL market share? Market share could be an interesting metric to follow.
- If TVL seems relatively static, it might be worth experimenting and lowering the amount emissions in order to have the length of the emissions last longer. Maybe the team is paying 0.3 DEXTR for every 1 TVL (denominated in DEXTR). If the TVL is 100M, that means DEXTR emissions is 30M; what if TVL won’t change if they distribute 15M DEXTR (so 0.15 Emissions/TVL); what about 10M?
- At the same time, maybe the team realizes that there is no change in swap volume if the DEX TVL is 80M or 120M. Is it really necessary to incentivize higher TVL with more DEXTR emissions if revenue is the same? Emissions/Revenue could be a great metric to look at as well!
- Maybe in the 4th month there is a strong competitor that has stopped or drastically lowered their emissions, the Dextr team may want to increase their emissions for a month or two to try and capture more market share. Dynamic emissions based on market scenarios.
Conclusion
I hope this help frames what emissions schedules are, the current standard around static emissions schedules, and how dynamic emissions programs may be a better solution to token emissions distribution. I am not aware of any protocol that is doing a dynamic emissions program. So if a protocol decides to go down this route, it may be risky. They may lose TVL, lose revenue, and need to adjust on the fly. There is a necessity to experiment here. Be dynamic, and accept that fact that no rewards come without risks. We know the cost of a static emissions program up front, but dynamic may or may not be more cost effective in the long run (though I expect it will be if set up correctly). Crypto is constantly changing and moving quickly. Teams should be willing to move as quickly as the market. Barriers to entry are low, but network effects are massive. A well balanced dynamic emissions program will help weigh the benefits of emissions in general to their cost.
PS
I have spent this article describing the opportunity cost of token emissions relative to the revenue of a protocol. This really makes sense for the owners of the protocol. However, as time goes on, I expect to see more protocols move to an open ownership (DAO) framework. Depending on who is part of the DAO, it may not just be owners. Users of the protocol and other ecosystem partners may take part as well. So the protocol may want to consider many additional metrics when it thinks about token emissions.
About Marco
For full disclosure I mostly use Solana, Aurora, Cardano, Polkadot for DeFi, because I don’t have enough assets to justify Ethereum gas fees.
I am in the Kitty Farmer Committee for Minswap Labs. I am also an active community member of Optim Labs. I am actively involved in multiple Friktion volts and a contributor in their Discord, and am OG Dappio Wonderland.
I am invested in SOL, ADA, ETH, DOT, ACA, NEAR, Aurora, ALGO, MIOTA along with plenty of other tokens.
This is not Financial Advice!
I would love to hear your feedback/questions/comments. Reach out to me on Twitter… Marco_112358, or Discord… marco_112358 in Wonderland#2400
