# Proposal - Reduce Rewards Period to 7 Days

**URL:** <https://dao.rocketpool.net/t/proposal-reduce-rewards-period-to-7-days/1616>\
**Category:** Governance\
**Created:** [16 March 2023 22:45 UTC](https://dao.rocketpool.net/t/proposal-reduce-rewards-period-to-7-days/1616 "2023-03-16T22:45:07Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![NonFungibleYokem](https://dao.rocketpool.net/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@NonFungibleYokem](https://dao.rocketpool.net/u/NonFungibleYokem)\
**Post date:** [17 March 2023 16:58 UTC](https://dao.rocketpool.net/t/proposal-reduce-rewards-period-to-7-days/1616/4 "2023-03-17T16:58:47Z")

</div>

You can read about the rewards v5 specification here -

> [@\[ODAO\] Rewards Tree Spec v5](https://dao.rocketpool.net/t/odao-rewards-tree-spec-v5/1578):
>
> [ODAO] Rewards Tree Spec v5 Hello everyone, Today I’m happy to bring forward a proposal for v5 of the Rewards Tree spec. This is a small adjustment to the [the v4 rules](https://github.com/rocket-pool/rocketpool-research/blob/master/Merkle%20Rewards%20System/rewards-calculation-spec.md) that the Oracle DAO must follow when constructing the Merkle Tree that assigns RPL and Smoothing Pool rewards to each Rocket Pool node operator. v5 is an important update to v4 because it adds support for 8-ETH-bonded minipools (LEB8s) in the upcoming Atlas protocol upgrade. Support for them is mandatory to ensure that node oper…

And the actual specification here -

> <https://github.com/rocket-pool/rocketpool-research/blob/v5/Merkle%20Rewards%20System/rewards-calculation-spec.md>

The key performance hangup is that for smoothing pool rewards, the tree generation process has to figure up the attestation performance for every minipool particpating. That means looking at all 7500+ attestations, for every epoch, over the 6300 epochs in a 28 day period. As the number of minipools participating in the smoothing pool increase (which we all hope will happen), the processing time to determine that attestation performance will increase at a linear rate at best. Right now, unless you put the whole beacon chain into ram the way the lighthouse folks do it, this is a 2+ hour process. With double the minipools, this timeframe also roughly doubles. Given community angst around how long this takes now under the best circumstatnces, it might be worth looking at managing the processing time by chopping the time interval up. If folks are comfortable and expectations are well managed about this taking longer and longer as we grow, then this proposal really isn’t needed.

The only other obvious optimisation would require statefully caching the minipool attestation performance over the whole period. This works to great effect (I beleive Rocketscan does this for its’ rewards previews), but can add some trust assumptions that the data hasn’t been tampered with after it’s been logged.

---

_[View the full topic](https://dao.rocketpool.net/t/proposal-reduce-rewards-period-to-7-days/1616)._
