Prevent large token rebases in a general determenistic way

[TheDZhon]

We've evaluated that too large stETH rebase could provoke oracle reports' sandwiching.

After the Merge we expect four sources of rebase:

• CL rewards
• EL rewards (MEV)
• EL rewards (tx fee)
• Coverage application (decreasing total shares amount)

Facing good weather conditions, everything is ok because threatening rebase changes starts from 7.5 basis points (BP) of TVL while we expect that CL rewards are about ~1.4 BP, EL rewards are about ~0.5-1.5 BP and coverage application rate-limited to 4 BP.

Nevertheless, MEV rewards could have spikes and outliers so we should care about stakeholders and prevent unfair arbitrage possibilities caused by the proto implementation peculiarities.

Two ways to carry out a possible solution could be proposed:

• Make oracle reports happen more often (~12h, ~6h periods)
• Induce global rate limits among all possible rebasing sources.

Context:

• https://research.lido.fi/t/rewards-distribution-after-the-merge-architecture-decision-record/1535
• https://github.com/TheDZhon/sandwich/blob/main/tests/test_mev_tx_fee_sandwich.py

[TheDZhon]

Resolved in #482

[sambacha]

Resolved in #482

The solution is in #482 though it is not yet deployed. Should this issue really be closed until said deployment on mainnet?

[TheDZhon]

I see your concerns, thank you!

• Mainnet version also prevents large token rebases yet uses multiple limiters instead of just one
• Even though it's not deployed on mainnet yet, the code is live on Görli and the fix is incorporated in the latest release candidate: https://github.com/lidofinance/lido-dao/releases/tag/v2.0.0-rc.1

Re-opening the issue to avoid confusion and misgivings in the future 👍

[sambacha]

I see your concerns, thank you!

• Mainnet version also prevents large token rebases yet uses multiple limiters instead of just one
• Even though it's not deployed on mainnet yet, the code is live on Görli and the fix is incorporated in the latest release candidate: v2.0.0-rc.1 (release)

Re-opening the issue to avoid confusion and misgivings in the future 👍

Thanks, also, should this rebase limit be tied to a specific oracle update window, I did not see any explicit mention of update frequency and rebase limit. It seems that should be the case potentially, as different oracle update frequency would necessarily change the scale of the rebase value.

This may just be a concern though for downstream users of this data point, and not necessarily affect Lidos direct usage of the max rebase value as a circuit breaker of sorts.

[TheDZhon]

The limit applies as a part of each Oracle report (reports provided daily), yeah.

The limit isn't tied to a particular duration because it should prevent a step-wise positive token rebase (e.g., if the previous oracle report is missed, the limit doesn't take into account this fact).

[TheDZhon]

Resolved in https://github.com/lidofinance/lido-dao/releases/tag/v2.0.0