N-Day Delegation Power

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 considering the last N days worth of delegation power when determining the top 80th percentile pools rather than the current single day snapshot. The method for determining a pools eligibility for rewards will remain the same with one exception: Instead of using the pools delegation power at the snapshot at 12:00am UTC relative to all other pool’s delegation during that snapshot, the pools cumulative delegation power from the the previous N snapshots (including the current day) will be compared to the cumulative delegation power of all pools during those same N snapshots.

HRA estimates use the same code/calculations as with the delegation snapshots and so changes in the snapshot code will also be reflected in the HRA estimates. At any given moment, snapshots for the previous N-1 days have already been taken and these delegation amounts will be fixed, while the current delegation provides an estimate for the last day’s snapshot.

Pros

Using the cumulative delegation power over N days (where N > 1) smooths out the delegation variation and makes it more clear who is likely to receive emissions on a given day. Additionally, the hourly HRA estimates will be more accurate in proportion to the size of N. The larger N is the lower the effect of the last day’s snapshot will be, and therefore the closer the current estimate is to the end result.

Cons

While increasing N allows for more reliable HRA estimates and improves clarity as to which pools will receive emissions on any given day, it comes at the cost of making the rewards more inert to the delegates wishes. Currently, delegates can change their mind at any moment and this becomes immediately reflected once the delegation is changed. As N increases, the previous N-1 days votes become “locked in” and so delegates must be satisfied with having a large proportion of their delegation power stuck supporting the pools they previously voted for.

Conclusion

Taking the cumulative delegation power over N snapshots provides more certainty as to which pools will receive emission and makes HRA estimates more accurate, but also creates a lag before a change in delegation power is fully realized. The larger N is, the greater the certainty, but also the greater the lag. Heuristically speaking, relative certainty (ranging from 0 to 1) increases proportional to 1-1/N while the lag (number of days before some majority of your delegation power reaches a given threshold) is proportional to N.

Proposed Voting Options

Unfortunately, the current polls do not allow for approval voting (individuals vote for as many options as they like), so standard voting rules (plurality voting) will apply. The voting options are:

  1. No Change (N should be 1 day)
  2. N should be 3 days
  3. N should be 5 days
  4. N should be 10 days
  • This proposal should proceed to an on-chain vote.
0 voters
2 Likes

Nice! Very well explained proposal; Since the hourly estimates just run the same code as the normal calculation, there won’t need to be any change there.

1 Like

Thanks, I edited the proposal to make this more clear.