Context
See the reference discussion for additional context.
Since the DAO voted to restructure the yield farming delegation dynamics , the new incentive structure has brought in millions of ADA worth of additional TVL, but with it some fierce competition as well. Any given pool may win out in delegation one day and lose the next. Of course, this is somewhat intentional as the power to choose which pools are incentivized is intended to be in the hands of SUNDAE holders. The continuously changing delegation landscape, however, means that the currently displayed historical returns annualized (HRAs) can also be quite inaccurate and even display “Below Minimum Delegation” for pools that end up winning out at the end of the day. It appears that a number of strategies have emerged including:
- waiting until minutes before the snapshot to delegate to the desired pool
- delegating toward a competitors pool to give a false air of confidence in that pool winning before swapping delegation
- delegating to more obscure pools with no delegation to “mask” delegation power before swapping delegation
Proposed Solution
To address volatility, this proposal suggests implementing a time weighting to delegation, where initially when locked only 10% of the users delegation contributes, but this increases linearly to the full 100% over a 48 hour period. The specifics of calculating the time since delegating to calculate the weightings would be the same solution as outlined in the updated rewards calculation proposal by isaias.
Pros
Adding a time weighted factor to the delegation will disincentivize large delegators from changing the pools which they vote for everyday, especially directly before the snapshot. A 48 hour period was chosen as it is short enough to allow for the delegation to “rapidly respond” to new pools being introduced (ex: new token launch), but is also a long enough time period that redelegating everyday to “mask” voting power becomes unviable. Additionally, this proposal has a relatively straightforward implementation that requires minimal effort from the SundaeSwap team.
With this incentive to consistently vote for the pool(s) that the user wishes to support, the HRAs would be expectedly more accurate in the hours or days before the snapshot. Additionally, there would likely be more certainty in which pools would win out day-to-day.
Cons
The biggest con for this proposal is that it means that anytime someone wishes to “top off” their delegation strength by locking additional Sundae or Sundae/ADA LP they will have to undergo a 48 hour wait for their delegation to reach its full effect. This also is the case for newly added pools, which would be unlikely to reach the 80th percentile threshold until at least 48 hours after their creation. However, this proposal could be amended at a later date to account for such cases at the cost of additional effort by the SundaeSwap team.
Finally, it would be less viable for delegators with enough voting weight to swing pools near the 80th percentile boundary (in an attempt to allow multiple pools near the boundary to “share” winnings by having some win some days and others with other days).
Temperature Check Vote
- Yes, this should proceed to an on-chain vote.
- No, this does not merit an on-chain vote.
Hey @Serotonin, thanks for the proposal!
As it stands, this isn’t yet specific enough to warrant a temperature check, I think. It needs to be fully specified from an implementation standpoint. The description you gave gets the basic idea across, but leaves a lot of details underspecified, which means Sundae Labs would be making arbitrary choices when implementing it.
Can you try to be more concrete, starting from the language in the spec decided on by the previous governance votes? If you’re not technically minded, I’ll take a stab at writing up how I interpret what you wrote.
Also, I mentioned this on Discord, but for future reference, temperature checks should have a poll with only one option.
This is because the “no” votes don’t matter for the purposes of the temperature check: 20 “yes” votes, and 1000 “no” votes is still sufficient to bring it to an on-chain poll. It’s measuring “is there some people that are interested in seeing a vote on this”, not “are there more people interested in this than not”. Having the second option invites controversy if many people vote no and it’s still brought to an on-chain vote. If we allowed “no” votes, the temperature check would serve as a filter function, allowing non-SUNDAE token holders to effectively gate-keep governance from others. Think of the poll like cosponsoring a bill, rather than getting yes/no votes.
I apologize for the yes/no option and any ambiguity. What would you like clarified for SundaeLabs? I’m proposing that weights be added to the delegation. These weights start at 10% at the time a change to delegation is made and linearly increase from 10% to 100% over 48 hours. From a implementation standpoint, I imagined that it would be identical to the updated rewards calculation proposed by isaias.
Specifically, how are you defining “at the time a change to the delegation is made”?
Internally, we track a set of UTXOs, and there is no inherent continuity between consecutive UTXOs. So, if someone “spends” that UTXO to update their delegation, this is counted as an entirely new position, which would reset the timer as you say.
Unfortunately, this means that when someone spends the UTXO to add additional assets to their position, it will also reset this timer. Since the permutations we’d have to handle are fairly complicated (someone could, in theory, have 5 different UTXOs each with different timings, that they spend all 5 and the output is 3 new outputs, some with updated delegations, some with preserved but merged delegations, etc.), tracking the “full duration” of a specific delegation setting is not feasible.
Is this drawback acceptable?
Unfortunately, this means that when someone spends the UTXO to add additional assets to their position, it will also reset this timer.
Yes, this implementation would reset the timer when people add assets to their position, hence me noting:
The biggest con for this proposal is that it means that anytime someone wishes to “top off” their delegation strength by locking additional Sundae or Sundae/ADA LP they will have to undergo a 48 hour wait for their delegation to reach its full effect.
Or am I misunderstanding it, and anytime they add to any of their LP positions (even non-Sundae positions), their delegation strength would be reset?
yes; any change to delegation in any program, or any change to the locked tokens (SUNDAE, or any LP tokens, for any program) would reset the timer because it would spend the UTXO.
This also opens up the same attack as you’re trying to avoid; a user wanting to swing the vote at the last second by creating false confidence in a program could just update their delegation, which reduces their voting power by 90%, reducing the delegation appropriated to the pool they were voting to.
Instead, I think a far more elegant solution that avoids all of this is:
- when computing delegation amounts to each pool
- first compute the midnight snapshot as normal
- then, add up the last N days worth of delegation by pool
This would essentially take a rolling N day average of the delegation to each pool, smoothing out the volatility in delegation, making any last-minute delegation switching only have 1/Nth effective, and be super simple to implement.
Ahh, I did not realize that an update to any LP position would result in resetting the timer. Yes, this changes the situation quite a bit.
Instead, I think a far more elegant solution that avoids all of this is:
- when computing delegation amounts to each pool
- first compute the midnight snapshot as normal
- then, add up the last N days worth of delegation by pool
That was my original suggestion (option 1), but I thought that you had mentioned in discord that the time weighted average would somehow actually be easier to implement than an N-day simple moving average.
With this understanding, I’d rather put forward a temperature check with the N-day simple moving average. Having your delegation reset when “topping off” your Sundae delegation might have been a reasonable sacrifice in the short-term to get something quickly deployed if it meant the work would also contribute towards a longer term solution using the time-weighted average. But if it means that redistributing liquidity to any LP pool resets the clock, then that is not a reasonable tradeoff imo (and wouldn’t really address the HRA “inconsistency” as well as leading to “unintentional” masking of delegation power)
From that discussion, in order of decreasing difficulty to implement, it’s 2a, 1, 2b. 2a would be easier to implement, but involves resetting the timer for any change; then, 1 is slightly harder to implement, but still reasonable. Finally, 2b is very difficult to implement.
@Serotonin I’ll go ahead and close this temperature check with your permission, and you can create another one that represents the other proposal, sound good?
Sounds good, please close this temperature check.