Update rewards calculation to consider the duration of locked LP tokens during the day

Temperature Check
1

Summary

As noticed by the community, it has been common practice by some big tokens holders to add liquidity to the current eligible pool for rewards (SUNDAE/ADA 0.3%), lock them into YF V2 within the last hour (or even minutes before) of the midnight UTC snapshot, and moments after the snapshot is taken, they unlock/withdraw the LP tokens again; thus, they gain full rewards for the day without taking any substantial risk of impermanent loss.

Proposal

The goal of this proposal is to at least “force” big players to take some risk if they wish to get nice daily rewards, by updating the rewards calculation to taken into consideration the duration the LP tokens stayed locked from the snapshot of the day before until the snapshot of current day. The vast majority of holders does not do this “not so cool” move every day, will benefit from this update, and the rewards distribution will be more fair. In addition, the rewards HRA % the community is seeing during the day might not change for some minutes around the snapshot midnight UTC, as noticed the other day it dropping from 235% to 220% right before the snapshot and coming back up to 235% moments after the snapshot.

Implementation details

In terms of making this concrete from an implementation perspective, here is how the calculation would change:

  1. Assume we’re calculating the rewards for date X, which is done at 2am UTC on date X+1, using the snapshot at midnight UTC between X and X+1;
  2. Identify the set of all positions that were created before and spent after the slot at midnight UTC between X-1 and X; these are our “initial positions”
  3. Identify all positions that were created before before and spent after the slot at midnight UTC between X and X+1; these are our “updated positions”
  4. for each initial position and updated position
    a. calculate the relevant_start_time as the maximum between the tx slot time, and the start of the day (midnight UTC between X-1 and X)
    b. calculate the relevant_end_time as the maximum between the tx spent slot time, and the end of the day (midnight UTC between X and X+1)
    c. sum up the LP tokens for each pool held by the position
    d. multiply the LP token quantity by (relevant_end_time - relevant_start_time) (in slots)
    e. divide this product by the number of slots in a day, 86400, rounded down.
    f. Add this to the LP weight by owner
  5. Split the received rewards among owners of the pool according to this prorated LP weight instead of the raw LP numbers
    By Pi :slightly_smiling_face:

As discussed in the Sundae Labs Discord, this update in the rewards calculation takes into consideration position updates:

in the implementation proposed, it handles updating the position with new LP tokens gracefully; you’d earn half a days worth at the first rate, and half a days worth at the increased rate; And, if you unlocked your LP tokens, you’d earn rewards for the half that you had them locked.
you treat each UTXO as a unit with some amount of LP tokens, and just prorate that for how long that UTXO “lived”

Conclusion

Please indicate below whether you would like to see an on-chain vote for this proposal. Per the governance procedures, once we receive 20 “Interested” votes, we will create the on-chain proposal for voting.

  • Yes, distribute prorated rewards
  • No, it’s fine the way it is now
0 voters
4 Likes
2

Hey @isaias Thanks for creating this, exciting to see community members participate in governance directly!

We discussed this on discord, but for future reference, make sure to create the poll with just one option, “Interested”; The temperature check is to measure “is there enough interest in seeing this voted on”, as a spam filter; not “is this likely to pass”.

I can’t edit it now, but all responders to the pool should understand that the first option is not a binding commitment, and is instead whether you want to see an on-chain vote for this proposal or not.

1 Like
3

Full support, good proposal

4 Likes
4

Distributing rewards to somebody that is not in the pool is a design flaw imho and whether or not to fix it should not even be up for a vote, but rather how.
I would prefer a snapshot & activation phase like with the Cardano epochs, but shorter with all 3 phases taking a total of 3x 10 hours eg.
Same should be done about the pool delegation. The current meta where whales change delegation right before the snapshot is screwing over normal user in that pool and is no good look from the outside.
They deserve all the power they got and the system is great, but there should be a warning period for everybody else.
In the pool tooltip: Current delegation % active for tomorrow & delegation change after tomorrow

5

come on guys, 3 more votes to go