⏳Loyalty Rewards
Summary
Loyalty rewards mechanism incentivizes the time spent on the liquidity provision. Mangata increases rewards for capital that have 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 turbulences they leave behind in pools they are leaving. This creates a lot of unpredictability and uncertainty for traders. Time Incentivization fixes this.
Do you want to learn more about how you can participate in liquidity mining and how much you can earn? Head over to Liquidity Mining
Asymptotic Reward Curve
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 senior users relative to newcomers
It gives new users a chance to catch up significantly in the first few weeks.
Mangata X 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.
Calculation
Basic Calculation
The reward a liquidity provider can claim is made up of two factors: The reward base and their 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 much rewards the user is getting because of their loyalty to the pool.
Sessions & Work
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: Sessions and 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 Mangata 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.
Reward Base
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 MGA promised as rewards. This means that each LP token worked to gain 10 MGA in rewards.
The rewards for each unit of liquidity that is mining per session are calculated:
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 MGA and in session 4, each LP token would have gained 10 MGA. In total, each LP token provided over that time frame would have earned 18 MGA 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.
Efficiency
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.
Cumulative Work & Missed 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.
Conclusion
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.
Scenarios
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 Mangata approach plays out further.
Later user joins
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.
Adding liquidity
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.
Further Reading
Read out the blog post: Time Incentivized Liquidity Mining
Watch the Video: Time Incentivized Liquidity Mining
Last updated
