Draft: Liquidity Mining Program

Governance
1

Here is a draft proposal to start Jet’s first liquidity mining program, feedback is welcome. The proposal also includes a small retroactive reward for governance participants.

Summary

This proposal seeks to deploy a part of the JET token treasury (137,700,946 JET) as rewards to users in the community, primarily for liquidity providers in Jet’s fixed-term lending markets, over a 4-year period starting with the release of the markets on Solana mainnet.

Motivation

In order for the fixed-term lending markets to function well there needs to be liquidity in the market. Liquidity mining programs have been successfully implemented by various DeFi projects to incentivize users to provide liquidity through the distribution of their governance tokens as rewards.

This will also help to increase the total circulating supply of JET tokens.

Specification

The reward breakdown is:

  • 134,100,946 JET to be distributed to users providing maker liquidity in fixed-term markets.
  • 3,600,000 JET to be distributed retroactively to previous participants in DAO votes on asset listings

All rewards are distributed to users as airdrops, through Jet’s governance system.

Liquidity Provider Rewards

Token rewards will be distributed to liquidity providers based on a formula intended to reward healthy participation in the fixed-term lending markets. The JET tokens will be distributed on a 30-day epoch over 4 years. 2,736,754 JET will be distributed per epoch.

The distribution per epoch is allocated to two different provider types:

  • 1,368,377 JET to providers acting as lenders
  • 1,368,377 JET to providers acting as borrowers

Liquidity providers are assigned a score based on the following formula:

// Score for each open order
let open_order_score = order_size * ln(order_interest_rate / (abs(mid_market_rate - order_interest_rate) / mid_market_rate))

// Sum all the open order scores for the minute sample
let q_sample = sum(open_order_scores)

// Scale the sampled score for open orders based on the market tenor, biased towards longer tenors
let q_scaled = q_sample * (1 + sqrt(market_tenor_days) / 30)

// Get the final score for a user in the 30-day epoch by summing all the sampled scores during that period
let q_score = sum(q_scaled)

Only orders within 200 basis points of the mid market rate will be considered for scoring.

Liquidity providers earn rewards based on their relative share of the total user score within the epoch, any user with a score exceeding 1% of the total will receive their reward share.

Once issued at the end of each epoch, rewards must be claimed within 90 days, otherwise unclaimed tokens are returned to the treasury.

Voter Retroactive Rewards

For early participants who voted on asset listings, they will receive a retroactive reward from the total reward pool of 3,600,000 JET. The formula for determining a user’s share in the reward is described as:

// Get the user score by summing the recorded vote weights and adjusting by the amount of proposals
// the user participated in relative to the total number of proposals voted on.
let user_score = sum(casted_vote_weight ^ (1 / 3)) * user_vote_count / total_proposal_count

Users below a vote threshold of 1000 will be excluded.

The airdrop is made available starting 2023-06-01, and can be claimed for 90 days. After 90 days any unclaimed tokens are returned to the treasury.

8 Likes
2

@suscd thanks for putting this together and sharing - one question I’m pondering is whether there should be added weight to one side of the book’s rewards vs another. Like, should lenders get a high reward vs borrowers or vice versa?

2 Likes
3

I think to start it makes sense they have equal weight, because it’s hard to predict how weak the borrow demand might be compared to the lending demand. It’s not as if you actually need to take a loan, only be willing to take one at your own desired interest rate. It’s something that would probably have to be reviewed after a few months of the program in action to determine if there need to be weight adjustments.

3 Likes
4

Thank you for this draft! I think the JetDAO community will be interested to see a proposal regarding incentivizing liquidity and addressing governance participation.

I think one thing that would be helpful to have in the proposal eventually is what percentage of the DAO treasury this would comprise.

I also think it would be helpful to understand the perspective this proposal is informed by. What is your interest in proposing this program?

Looking forward to refining this proposal!

2 Likes
5

I’m one of the protocol engineers working on Jet, my interest in this proposal is primarily in increasing the use of the protocol.

As for details about the DAO treasury, it’s my understanding that the total amount available to the DAO is still pending some legal changes, so it would be up to the governance committee to report on that once finalized.

6 Likes
6

How can I interpret the calculated score? What does this number mean?

3 Likes
7

Here’s how I interpret it @arian

From the proposal:

Liquidity providers earn rewards based on their relative share of the total user score within the epoch, any user with a score exceeding 1% of the total will receive their reward share.

They key part to understanding how it works is that LPs receive their relative share of epoch rewards – as long as the score of an LP is greater than 1%, they will receive their portion of the distributed tokens from that epoch, relative to the scores of the other LPs with scores greater than 1%.

For a simple example, let’s imagine there were just two liquidity providers during an entire epoch. LP 1 receives a final q_score of 0.75, and LP 2 receives a 0.25 (the q scores for every LP during the epoch will sum to 100%).

So with the proposed 2,736,754 JET distributed per epoch:

LP 1 would earn 0.75 * 2,736,754 = 2,052,565.5 JET
and LP 2 would earn 0.25 * 2,736,754 = 684,188.5 JET

Hope this examples helps!

2 Likes
8

Ok thank you very much, for Liquidity Providing Rewards I got it. How does it work for Voter Retroactive Rewards?
Ex.: wallet: XYZ
casted_vote_weight: 1,500,000
user_vote_count: 17
total_proposal_count: 17
(So he voted in all proposals)
Formula:
user_score = sum(1500000 ^ (1 / 3)) * 17 / 17
user_score = 114.4714

What does this 114 score mean?
How much JET will this user get from the 3,600,000 ?

3 Likes
9

And the specification says retroactively.
The proposal isn’t fixed yet, that means current participation still counts?

"Users below a vote threshold of 1000 will be excluded. "
→ Is this threshold per vote or the casted_vote_weight ?

3 Likes
10

Imagine a world where there are only 5 voters and 17 proposals:

A with a vote weight of 100,000, who voted on all 17 proposals
B with a vote weight of 1,000,000 who voted on all 17 proposals
C with a vote weight of 750,000 who voted on only 10 proposals
D with a vote weight of 10,000 who voted on all 17 proposals
E with a vote weight of 3,000,000 who voted on only 9 proposals

Assuming they retained the same vote weight for all their votes, the score for each would be (approx)
A: 789
B: 1700
C: 534
D: 366
E: 687

The total score would be 4076, so the share of total rewards would be as (assuming 3.6M JET):
A: 19.36% (~696,859 JET)
B: 41.70% (~1,501,472 JET)
C: 13.10% (~471,638 JET)
D: 8.98% (~323,258 JET)
E: 16.85% (~606,771 JET)

If you assume that there are another 35 voters on who participated in all proposals, and averaged a score of 500, then the total score would be 21,576 and the shares for our hypothetical voters would then be:

A: 3.656% (~131,646 JET)
B: 7.879% (~283,648 JET)
C: 2.475% (~89,098 JET)
D: 1.696% (~61,067 JET)
E: 3.184% (~114,627 JET)

I don’t see why not

This threshold is for the casted_vote_weight

5 Likes