Minimum guaranteed time window with known RPL ratio for reward snapshot known

[Valdorff]

Draft RPIP: https://github.com/Valdorff/RPIPs/blob/lock_ratio_for_rewards/RPIPs/RPIP-draft.md

Excerpts:

---

An alternative thought
At least one community member has expressed a preference to instead have an ~18 hour window. This would allow a much simpler implementation long-term – the epoch-based system would simply allow having the last RPL price always come in 18 hours before the rewards snapshot.

I believe 2 days time window is an importantly better user experience. Would definitely like more people to opine on this though.

[knoshua]

@Valdorff

An alternative thought
At least one community member has expressed a preference to instead have an ~18 hour window. This would allow a much simpler implementation long-term – the epoch-based system would simply allow having the last RPL price always come in 18 hours before the rewards snapshot.

I like the simpler implementation and we could then generally make the update interval longer, potentially 2 days. I don’t see why we need to update every 20 hours.

[epineph]

So I think order of preferences for me for UX:

1. Regular interval between price lock and reward snapshot
2. make this interval a real world number (like 24 hours) so easier to explain
3. give at least 2 days to allow people who aren’t constantly on discord time to rebalance

Didn’t get my morning coffee.

To me effectively no risk at increasing update for RPL price to 2 days.

[knoshua]

@epineph

I think there is likely minimal risk of prolonging price update to 2 days (may give bonus of ~0.011% more rETH on minting, or a tiny bit more after large proposals; in big slashing event would give more time to cash in [but if arbitrage possible contract would probably already be drained in 19 hours]). Are there other downsides here?

You are mentioning downsides to a longer rETH balances update frequency. The proposal is about the RPL price update frequency.

[yorickdowne]

I see the value of easy implementation. From a UX perspective though 2 days is far better than 18 hours.

[Uisce]

This seems like an unnecessary complication, you are replacing the potential of a short period between update and snapshot with confusion/frustration about a two day old ratio being used.

The latter doesn’t strike me as better end user UX.

[knoshua]

So we are currently using a 12 hour time weighted average price and that price is taken anywhere between 20 and 0 hours before reward snapshot. So currently, the relevant prices are something between 0-12 hours before snapshot and 20-32 hours before snapshot.
The proposal is to always use 48-60 hours. That’s certainly less recent, but I don’t think it hurts UX. We already use old prices and there is potential for a difference between price used and actual price at the time. People already have to check the protocol price to figure out if they qualify for rewards or need to top up, there is nothing intuitive about the range of price windows used.