Increasing max APR sanity check for Oracle Lido report

On 9 Nov, 2022, due to the extreme market conditions Lido has bumped into previously set conservative 10% APR limit for the stETH rebase after Oracle report. That happened due to the fact that the Oracle limit was set before the Merge hadn’t accounted for potential Execution Layer rewards spikes.

No user funds or rewards are at risk. Under the current set of constraints, the rebases most likely won’t happen daily before the parameters change in Lido Oracle contract. The proposed change is increasing allowed APR for Oracle report from 10% to 17.5% (1750 basis points).

The 10% yearly threshold had been chosen before the Merge and hadn’t accounted for potential spikes in daily rewards accrued by the protocol. In order to prevent potentially economically vulnerable large token rebases, only 2 basis points of the stETH total supply can be accounted for rebase daily (~940 ETH at the time of writing). So, in order to accommodate for those extra 2 daily basis points, the threshold increase should be ~7.5% yearly (2 basis points * 365 days ≈7.5%). According to analysis provided in github issue, that number is considered safe enough as it’s lower than the ≈28% yearly threshold.

Note that given the current set of thresholds & limits, Oracle report on 10th Nov 2022 may happen successfully. The EL rewards are have max limit to be accounted for in single report. As CL rewards are more or less consistent day-to-day, the max ~940 ETH to be accounted for during the rebase would be counted as two-days increase instead of single-day, getting the APR of the rebase under 10% threshold. To summarise, under the current limits while the EL vault holds more than the max amount to be accounted for in the single report, the rebases may happen every other day. To reiterate, in any case all the rewards accrued will be distributed to stakers.



Thanks for the detailed explanation!

1 Like

when is planned to start the voting?

1 Like

I am pro this proposal.

MEV amount has been sloping upward since yesterday compared to all of the days since the Merge, see Lido post Merge protocol APR: Consensus and Execution Layer Rewards.

Looks like we didn’t have a regression test to re-ensure the aforementioned 10% yearly threshold ([1], [2]) at the moment of the Merge-ready protocol upgrade. That’s how it flew under the radar.


Vote would be up as soon as all the testing is done; most likely today (:crossed_fingers:), but don’t have exact timeline yet.


Just adding a short TL;DR: here.

Before the Merge the only source of stETH rebase was increasing balance of validators on Beacon Chain. It was capped to 10% APR. After the Merge re-staked EL rewards were added. Maximum amount of EL rewards to be re-staked in one iteration is limited to 2 basis points (approximately 7.5% APR). Now (after the Merge) initial cap of 10% is applied to the sum of validators balance on Beacon Chain and re-staked EL rewards and there can be a case when this sum will not pass Oracle sanity check and report can not be finalised. To avoid this happening we need to increase cap to 17.5% (10% BC balance increase + 7.5% re-staked EL rewards).


Thx for the explanation. LGTM!

1 Like

Guys, it’s very important to coordinate two different limits in the protocol with each other so that the oracle reports can happen daily, regardless of the number of EL rewards. 1750 looks good to me, it’s 10% on TL and 7.5% on EL (corresponding to just over 2bp for a one-time rebase, which is consistent with limit here).


The on-chain vote to increase max APR security check limit from 1000 to 1750 bp started!
The main phase (when you can vote ‘For’ or ‘Against’) will last 48 hours and end at 10:30 AM UTC Saturday.
Please, check it out and cast your votes!


Unfortunately the vote is only for LDO holders and not stETH holders. I have no LDO but quite a bit of stETH, and seeing the proposal is stETH rewards related, it would have been nice to allow us to vote too. Too bad


Voting #143 is over :checkered_flag: and passed!
For: 58,786,915.192
Against: 0
Thank you for your votes!


Also, the parameter is successfully updated.


yes, we expect the first regular daily report with the changed parameter value will take place today at ~12:30 UTC


Which it did! Yay daily rebases (or :crossed_fingers:, depending on how optimistic you are)


For more details about the incident, read Postmortem: Disrupted rewards distribution due to missed oracle reports.