LIP-23: Negative rebase sanity check with a pluggable second opinion

Description

The proposal improves protocol security by protecting against possible malicious negative rebase manipulations. If the DAO approves it, the new sanity checks will be included in the further on-chain vote to be applied to the Lido protocol.

TL;DR

Lido stETH stream contributors propose to improve the safety check for the accounting oracle report in the case of a negative rebase, reducing the possible impact size, but with the requirement for a second opinion for extreme cases.

It is proposed to change the current AccountingOracle sanity check, which currently does not allow reporting more than a 5% decrease in Consensus layer validator balance and withdrawal vault balance daily, to a sanity check that will not allow more than ~3.4% per an 18-day window (1.101 ETH decrease per validator concerning the window).

Motivation

The AccountingOracle contract aggregates all Lido validators’ Beacon Chain balances (clBalance in the report) to the protocol, critical for the daily rebase of the stETH token. To ensure data integrity, it uses a committee of nine Oracle daemons, with a consensus required from at least five.

The protocol could be harmed if this committee is compromised, malfunctions, or colludes. This risk is acknowledged and constrained by a sanity check that restricts the possible discrepancy in balance that Oracle can report. The current approach to sanity checking allows the Oracle committee to bring up to a 5% reduction of TVL in each report. Given that the governance reaction time is 3-4 days, the malicious or compromised Oracles could reduce the TVL by 15-20%, invoking mass liquidations on lending markets and dropping the price of stETH.

The contract specification details can be found in the LIP-23.

Next steps

• ChainSecurity is conducting the smart contract audit. Once finalized, the report will be published on the research forum.
• If this snapshot vote is approved, the on-chain voting will occur after all audits and security checks successfully completed. An improved sanity checker will be applied to the protocol without a second opinion but rather an interface to integrate a preferred provider later on.
• Plugging in a particular second opinion provider is a question of a separate discussion and voting.