# Time-Weighted Delegation Power

**URL:** <https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182>\
**Category:** Temperature Check\
**Created:** [August 21, 2023, 1:32am UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182 "2023-08-21T01:32:16Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Serotonin](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Serotonin](https://forum.sundaeswap.finance/u/Serotonin)\
**Post date:** [August 21, 2023, 1:32am UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/1 "2023-08-21T01:32:16Z")

</div>

# Context

See the [reference discussion](https://forum.sundaeswap.finance/t/smoothing-delegation-volatility/3175) for additional context.

Since the DAO voted to [restructure the yield farming delegation dynamics](https://governance.sundaeswap.finance/#/proposal#346ed07d68025757fadc420fcca56c20a5cb8a8bc44e21bb3156372172f43923), 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](https://forum.sundaeswap.finance/t/update-rewards-calculation-to-consider-the-duration-of-locked-lp-tokens-during-the-day/3162/1) 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

_Poll ([view on site](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/1))_

---

<div class="post-metadata">

**Author:** ![Quantumplation](https://avatars.discourse-cdn.com/v4/letter/q/b5e925/32.png) [@Quantumplation](https://forum.sundaeswap.finance/u/Quantumplation)\
**Post date:** [August 21, 2023, 1:45am UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/2 "2023-08-21T01:45:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Serotonin](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Serotonin](https://forum.sundaeswap.finance/u/Serotonin)\
**Post date:** [August 21, 2023, 2:28am UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/3 "2023-08-21T02:28:03Z")

</div>

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](https://forum.sundaeswap.finance/t/update-rewards-calculation-to-consider-the-duration-of-locked-lp-tokens-during-the-day/3162) proposed by isaias.

---

<div class="post-metadata">

**Author:** ![Quantumplation](https://avatars.discourse-cdn.com/v4/letter/q/b5e925/32.png) [@Quantumplation](https://forum.sundaeswap.finance/u/Quantumplation)\
**Post date:** [August 21, 2023, 2:51am UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/4 "2023-08-21T02:51:31Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Serotonin](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Serotonin](https://forum.sundaeswap.finance/u/Serotonin)\
**Post date:** [August 21, 2023, 4:17pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/5 "2023-08-21T16:17:49Z")

</div>

> 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?

---

<div class="post-metadata">

**Author:** ![Quantumplation](https://avatars.discourse-cdn.com/v4/letter/q/b5e925/32.png) [@Quantumplation](https://forum.sundaeswap.finance/u/Quantumplation)\
**Post date:** [August 21, 2023, 4:59pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/6 "2023-08-21T16:59:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Serotonin](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Serotonin](https://forum.sundaeswap.finance/u/Serotonin)\
**Post date:** [August 21, 2023, 9:10pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/7 "2023-08-21T21:10:37Z")

</div>

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)](https://forum.sundaeswap.finance/t/smoothing-delegation-volatility/3175/2), 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)

---

<div class="post-metadata">

**Author:** ![Quantumplation](https://avatars.discourse-cdn.com/v4/letter/q/b5e925/32.png) [@Quantumplation](https://forum.sundaeswap.finance/u/Quantumplation)\
**Post date:** [August 21, 2023, 9:26pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/8 "2023-08-21T21:26:03Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Serotonin](https://avatars.discourse-cdn.com/v4/letter/s/c37758/32.png) [@Serotonin](https://forum.sundaeswap.finance/u/Serotonin)\
**Post date:** [August 21, 2023, 9:39pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/9 "2023-08-21T21:39:48Z")

</div>

Sounds good, please close this temperature check.

---

<div class="post-metadata">

**Author:** ![Quantumplation](https://avatars.discourse-cdn.com/v4/letter/q/b5e925/32.png) [@Quantumplation](https://forum.sundaeswap.finance/u/Quantumplation)\
**Post date:** [August 21, 2023, 9:54pm UTC](https://forum.sundaeswap.finance/t/time-weighted-delegation-power/3182/10 "2023-08-21T21:54:31Z")

</div>

Closed on August 21, 2023, 9:54pm UTC


