Lido Proposal: #0xb6559f0cdb1164ae5d63769827c4a275805bd944392a17b60cf51ddc54429dc6

Ensuring Compatibility with Ethereum’s Pectra Upgrade

Status:
Closed
Support the proposed changes100%

Support the proposed changes: 100%

63,302,145 LDO

Do not support the changes: 0%

16 LDO

Voting Period

  -  

Proposer

0xDbBC6A93ae517D3ea568C04219cbBBd025f01CB6

Description

This proposal outlines an upgrade to the Lido protocol to ensure continuous operation with Ethereum’s upcoming Pectra hardfork. The focus is exclusively on compatibility, rather than integrating any new features introduced by Pectra.

Pectra-related new functionalities, such as Triggerable Withdrawals via EIP-7002, and increasing the MAX_EFFECTIVE_BALANCE and validator consolidations via EIP-7251, will be addressed separately.

Motivation

The Pectra upgrade (EIP-7600) introduces changes to the Ethereum protocol specifications that directly impact components of the Lido protocol. Specifically, these changes affect the algorithms of the Accounting, Validator Exit Bus, and CSM oracles, the limits in the Oracle Report Sanity Checker contract, the slashing penalty, and the gIndexes in the CS Verifier contract. To ensure the Lido protocol continues to operate accurately and reliably, the affected oracle algorithms, Oracle Report Sanity Checker limits, and the CS Verifier must be reviewed and updated in accordance with the new Ethereum protocol specifications.

Technical Implementation Plan

The proposal’s technical scope consists of three parts:

  1. Deployment of a new version of the CS Verifier Contract.
  2. Items for the further on-chain vote before the hardfork.
    • Increment the consensus version for Accounting, Validator Exit Bus, and CSM oracles.
    • Revoke the verifier role on the Community Staking Module contract from the old CS Verifier contract and grant it to the new CS Verifier contract.
  3. Items for the further on-chain vote after the hardfork.
    • Update Oracle Report Sanity Checker parameters.

The on-chain vote before the hardfork includes only the minimal changes necessary to keep the Lido protocol functioning correctly after the Pectra upgrade. The on-chain vote after the hardfork includes optimizations that have no strict timeline and can be implemented without a set deadline post-upgrade.

A research forum post with more details can be found here.

The code specification details can be found in the LIP-27: Ensuring Compatibility with Ethereum’s Pectra Upgrade.

Next Steps

The MixBytes and Ackee teams are conducting smart contract audits and deployment verification for the upgrade. Additionally, MixBytes and Composable Security are auditing the off-chain Oracle code. Once completed, the audit reports will be published on the Research forum.

If any issues are identified during internal screening or by external auditors, they will be addressed, and the fixes will be outlined in a forum post with detailed descriptions.

If this Snapshot vote is supported, two on-chain votes on implementing will follow: one before (items #1 and #2 in the above Technical Implementation Plan) and one after the Pectra hardfork (item #3 in the above Technical Implementation Plan), once all audits and security checks have been successfully completed. All proposed changes will then be applied to the protocol.

Fallback Plan

If any risks related to the on-chain voting before the Pectra upgrade are identified or if the DAO does not approve the proposed update, the fallback plan will be executed.

Under this plan, one day before the Pectra upgrade, deposits will be paused. The unpause of deposits will be put to an on-chain vote for the DAO to decide after Pectra.

This measure is necessary to ensure the stable operation of the Lido protocol and to prevent incorrect transient balance accounting. Essentially, pausing deposits helps avoid mismatches in tracking newly deposited ETH during the brief window (approximately 24 hours) when old and new deposit mechanisms overlap. More details can be found in LIP-27: Ensuring Compatibility with Ethereum’s Pectra Upgrade.

A detailed fallback action plan will be outlined separately on the Research forum in case any risks related to the on-chain voting before the Pectra upgrade are identified or if the DAO does not approve the proposed update.

Voting Outcomes

A vote "Support the proposed changes" indicates agreement with this proposal. If this option wins, two on-chain votes on the proposed changes will follow and the proposed changes will be implemented after all audits and security checks are successfully completed.

A vote "Do not support the changes" indicates disagreement with this proposal. If this option wins and the DAO rejects the upgrade, the protocol will not be ready for the Pectra fork. The fallback plan will be activated, and further actions will be discussed on the Research forum.