Withdrawals for Lido on Ethereum: “bunker mode” design and implementation

Proposals
1

The Shanghai/Capella upgrade for Ethereum will enable withdrawal functionality. Recently the Lido on Ethereum protocol team proposed a high-level design of withdrawals where they offered a “bunker mode”, as a mechanism to protect users who are unstaking during rare but potentially highly adverse network conditions (e.g. mass slashing). While agreeing with the main idea, Lido Analytics and Tooling teams elaborated on the concept and redefined “bunker mode” as well as proposed its implementation.

We proposed to enter the “bunker mode” in three conditions when the penalties might be big enough to have a significant impact on the Protocol’s rewards:

  1. Mass slashing (already proposed by the Lido on Ethereum protocol team as a condition for the “bunker mode”)
  2. Penalties exceeding rewards in the current period between two Oracle reports
  3. Lower than expected Lido validators performance in the current period between two Oracle reports and penalties exceeding rewards at the end of it.

The document below outlines the “bunker mode” design for the withdrawals feature for Lido on Ethereum protocol providing the details on the proposed triggering implementation and withdrawal requests finalization. We also provided some thoughts on how the proposed design eliminates “false negative bunker” (not entering the “bunker mode” if it is needed) while minimizing the probability of “false positive bunker” (entering the “bunker mode” if it is not required). Analyzing known risks and possible catastrophic scenarios that are likely to trigger the ”bunker mode”, we concluded that the probability of the “bunker mode” happening varies from low to very low.

18 Likes
2

As someone who participated in this research in an advisory role, I am pleased to see the level of detail and analysis that the Lido Analytics and Tooling teams have put into the proposal. The team’s approach to the bunker mode offers a valuable mechanism to protect users under turbulent network conditions. So I fully support the implementation of this proposal in the oracle daemon code.

3 Likes
3

The document outlines all of the necessary aspects of the previously announced ‘bunker mode’. Thank you for digging deeper and reaching the completeness of the definition. A great follow-up to fill the gaps in the high-level design, indeed.

The intriguing part for me is the upcoming oracle design that incorporates the algorithm and bunker implementation.

3 Likes
4

For normal operation, oracle needs to set a config with the value of predefined variables. In our this research, we set up several pre-defined variables which should be added to the Oracle config. We would like to provide variables values and reasoning:

Metric Value
NORMALIZED_CL_REWARD_PER_EPOCH 64
NORMALIZED_CL_REWARD_MISTAKE_RATE_BP 1000
REBASE_CHECK_NEAREST_EPOCH_DISTANCE 1
REBASE_CHECK_DISTANT_EPOCH_DISTANCE 23
requestTimestampMargin 7680
PREDICTION_DURATION_IN_SLOTS 50400

Description:

NORMALIZED_CL_REWARD_PER_EPOCH = 64

  • equal to BASE_REWARD_FACTOR. Variable determining possible rewards based on overall rewards issuance, that is necessary for detecting ‘lower than expected CL rebase’ (More on this here) for one of the bunker mode conditions: ‘lower than expected CL rebase in the current frame and a negative CL rebase at the end of the frame’(Condition 3).

NORMALIZED_CL_REWARD_MISTAKE_RATE_BP = 1000

  • equal to 10%, representing acceptable variation on CL rebase (with probability at least 1%) for protocol working without major incidents: proposal/sync committee participation, observed variation for inactive validators, and the total number of validators variation. More on this here.

REBASE_CHECK_NEAREST_EPOCH_DISTANCE = 1

  • closest epoch to Oracle report, in which we check if rebase is negative for ‘negative CL rebase at the end of the frame’(Condition 3).

REBASE_CHECK_NEAREST_EPOCH_DISTANCE = 23

  • a minimum sufficient number of epochs leading to lower than expected CL rebase in a frame for ‘negative CL rebase at the end of the frame’(Condition 3) check.

requestTimestampMargin = 7680

  • period-lock of 20 epochs (2 hours) for withdrawal requests that prevent sophisticated users from unstake if problems in Protocol are observed close to the Oracle report epoch. Obtained as the nearest integer amount of epochs lower than REBASE_CHECK_DISTANT_EPOCH_DISTANCE and closest to the integer number of hours. More on this here.

PREDICTION_DURATION_IN_SLOTS = 50400

  • For projected withdrawals calculation Oracle need to predict the amount of rewards in the future. Since the amount of the reward is a relatively random number we suggest using a 7-day moving average (or 54000 slots) for proper future rewards calculation.
6 Likes