Time-Based LP Incentives
Last updated
Last updated
Gasp’s loyalty reward mechanism incentivizes the time spent on liquidity provision, increasing rewards for capital that has spent a longer period of time working in a pool.
Many DEXes attract liquidity with mining incentives, but the liquidity just keeps traveling from pool to pool. Pools are dominated by liquidity providers that select the highest APR without much respect for the turbulence they leave behind in pools they are leaving. This creates a lot of unpredictability and uncertainty for traders. Gasp's time incentivization model solves this.
We are introducing an asymptotic reward curve for time-incentivized liquidity mining.
This curve has a few advantages for liquidity mining:
There are almost no rewards in the first few days, disincentivizing liquidity providers that only care about short-term value extraction,
It quickly ramps up and continually increases the rewards of long-term users relative to newcomers,
It gives new users a chance to catch up significantly in the first few weeks.
Gasp’s asymptotic reward curve is configured to reach >90% efficiency within 2 weeks, allowing users to onboard quickly. While disincentivizing the short-term provision, the curve rewards loyalty since it infinitely increases.
The reward a liquidity provider can claim is made up of two factors: 1) the reward base; and 2) the liquidity provider’s efficiency.
reward = reward_base * efficiency
The reward_base is the amount of rewards that can be claimed per liquidity token in the period of time a user has been liquidity mining.
The efficiency is a factor from 0-1 that expresses how many rewards the user is getting owing to their loyalty to the pool.
Following an asymptotic curve is mathematically simple, but not trivial to achieve in a constrained environment like a blockchain runtime. Iterating over large lists of users and previous actions has to be avoided as it incurs a lot of execution costs, which would make it gas-expensive. Instead, we use two concepts that help us express the same curve in a memory-efficient manner: 1) Sessions; and 2) Work.
Sessions allow us to discretize the continuous curve into specific steps at which our calculations happen. Each session measures the total amount of liquidity that has been working in the pool for that amount of time. A session at Gasp is 4 hours long. The beginning of a new session is marked by a Checkpoint.
Work: To realize time incentivization, we use the notion of work. The idea is that a user’s capital is working in a liquidity pool. The longer it works, the more efficient it gets at mining rewards.
To arrive at the reward base, we want to calculate how many rewards each LP token is getting per session.
Example: Let’s say 10,000 LP tokens were working in the pool for a session and there was a total reward of 100,000 GASP promised as rewards. This means that each LP token worked to gain 10 GASP in rewards.
The rewards for each unit of liquidity that is mining per session are calculated:
rewards_per_liquidity = rewards / activated_liquidity
Where activated_liquidity is the sum of all activated LP tokens over all users for this liquidity pool and rewards are the rewards that go into this pool in this session
To facilitate the reward calculation later, we note down the cumulative rewards per session.
Session | Rewards | Liquidity | Rewards/Liquidity | Cumulative Rewards/Liquidity |
0 |
| 10,000 |
|
|
1 | 100,000 | 10,000 | 10 | 10 |
2 | 100,000 | 20,000 | 5 | 15 |
3 | 100,000 | 12,500 | 8 | 23 |
4 | 100,000 | 10,000 | 10 | 33 |
This allows us to calculate the reward base for each user by comparing two sessions.
Example: Let’s say a user joins in session 2 and provides 10 LP tokens for sessions 3 and 4. This means that in session 3, each LP token would have gained 8 GASP and in session 4, each LP token would have gained 10 GASP. In total, each LP token provided over that time frame would have earned 18 GASP in rewards.
To calculate a user's reward base between two checkpoints, we can subtract the cumulative rewards/liquidity of the entry time from the exit time to get the amount of rewards the user has accumulated in that time period.
reward_base = cumulative_rewards_per_liquidity_second_checkpoint - cumulative_rewards_per_liquidity_first_checkpoint
The previous section has focused on the pool level: how to compare the work over the whole pool. This chapter focuses on the work that the liquidity of a single user performs and how we can calculate the efficiency from it.
In the previous chapter, we calculated the reward base for each LP token between 2 sessions.
Now we need to multiply it with the value called “efficiency”. We need to know how much work the capital has formed in comparison to the theoretical maximum. This amount is expressed as a value between 0 and 1.
efficiency = cumulative_work / max_possible_cumulative_work
Cumulative Work is the work performed in all the sessions where the user is mining rewards. By convention, we define that in session #0 the capital is maximally inefficient. It performs 0% work and misses 100%. In each subsequent session, the capital gets more efficient and misses less work by a factor of 1.03.
Example: Alice provides 10,000 LP tokens to the pool.
In session 0, she misses 10,000 work and performs 0 work,
In session 1, she misses 9,708 (10,000 / 1.03) work and performs 292 work,
In session 2, she misses 9,425 (10,000 / 1.03^2) work and performs 575 work.
The relationship between the work done in each session and the missing work is show in this graph:
As you can see, the work grows slower and slower and the missed work shrinks slower and slower, which will later lead to the asymptotic curve we desire. This now allows us to put all the values we just mentioned into one table and calculate the efficiency from it.
Session | Missed Work | Work | Cumulative Work | Max Possible Cumulative Work | Efficiency |
0 | 10,000 | 0 | 0 | 0 | 0 |
1 | 9,708 | 292 | 292 | 10,000 | 2.91% |
2 | 9,425 | 575 | 867 | 20,000 | 4.32% |
3 | 9,151 | 849 | 1_716 | 30,000 | 5.71% |
4 | 8,884 | 1_116 | 2_832 | 40,000 | 7.07% |
The efficiency can be calculated between any two points we wish, by taking the work performed in that session and dividing it by the max possible cumulative work from that time period.
The shown method allows the user to add and remove liquidity at any time, as well as to claim any rewards, and we are still able to calculate a proper checkpoint for the user that summarizes any previous activity and allows us to express the proper relations to calculate future rewards.
Let's put these in practical examples to provide a better understanding of what these mean for the liquidity providers and explain the effects of how the Gasp approach plays out further.
This chart compares two users. The first user joins the pool on day zero and the second one joins after a month. Let's assume they are providing the same amount of liquidity, hence they have the same curve. But since the second user joins the pool later, the second user will always be behind the first user. But the difference shrinks over time.
In this example, the user adds the same amount of liquidity on top of its initially provided liquidity after a month. Since adding liquidity after some time will create a different maximum on the curve, this design prevents a user to ramp up its percentage with a small amount of capital and farm the increased incentives by adding great sums of liquidity afterward.
