Lido’s Roadmap to Pectra: Ensuring Compatibility with Ethereum’s Next Upgrade

TLDR:

The upcoming Pectra Ethereum hardfork requires adjustment to several core components of the Lido Protocol so that it can remain in sync with Ethereum’s evolving consensus rules.

Changes include updates to the oracle infrastructure—addressing Ethereum’s new deposit queues and dynamic validator balances—as well as a redeployment of the CS Verifier contract to incorporate revised proof indexing and to remove the greatly reduced initial slashing penalty.

Oracle reporter sanity checker parameters will also be refined, reducing the daily limits for validator exits and appearances. Two sequential on-chain votes are planned (before and after the hardfork) to implement these changes, with fallback measures such as pausing deposits if needed to ensure operational stability.

Some of the new functionalities of Pectra are expected to be integrated in subsequent upgrades to the protocol, subject to DAO approval.

Pectra: High-Level Overview

Pectra is Ethereum’s upcoming network upgrade, combining enhancements from the Prague and Electra hard forks. This upgrade impacts both the consensus and execution layers, introducing significant changes designed to improve validator operations, network efficiency, and user experience.

On the consensus layer, Electra expands the effective balance range for validators, raising the upper limit to 2048 ETH. It also enables validators to initiate full or partial withdrawals directly from their withdrawal credentials address, streamlining fund management.

Meanwhile, the execution layer benefits from Prague’s innovations, including support for more blobs per Ethereum block, improving scalability for rollups. Additionally, Prague enhances EOA (Externally Owned Account) capabilities by account abstraction.

Some Ethereum Improvement Proposals (EIPs) included in Pectra span both layers, improving the in-protocol coordination and messaging mechanisms for operations like deposits and withdrawals that require synchronization between the consensus and execution layers.

A key transformation for validators in this upgrade is the introduction of a new validator type that supports a higher maximum effective balance (2048 ETH). This change addresses network congestion concerns resulting from the current max effective balance of 32 ETH, which was put in place due to historical constraints based on intents to scale Ethereum via execution shards.

Going forward, node operators running validators will have the option of creating new validators with this higher effective balance (i.e. type 0x02), migrating (or consolidating multiple) existing validators (of either 0x01 or 0x02 type), or creating validators using the previous 0x01 or 0x00 withdrawal credentials types.

As a result, it is estimated that the total number of validators on the network will decrease through consolidations or operators using 0x02 credentials for new validators while exiting previous 0x01 type validators when needed for withdrawals.

By streamlining validator operations and unlocking new execution-layer efficiencies, Pectra sets the stage for Ethereum’s long-term scalability and future advancements.

How Pectra Impacts Lido

For a more technical overview and further discussion of immediate changes proposed to the Lido protocol of Pectra compatibility, refer to Lido Improvement Proposal 27.

Short-Term Considerations

Immediate changes focus on ensuring that the Lido Protocol remains fully operational through and following the Pectra hardfork. This includes:

• Updating the oracle consensus version to manage new deposit queues and dynamic validator balances.
• Redeploying the CS Verifier contract with updated gIndexes, and revising validator churn parameters (such as lowering the daily exit and appearance limits).
• Additionally, interim measures like fallback plans (e.g., pausing deposits if needed) and two sequential on-chain votes are designed to secure the protocol’s stability during the transition.

Long-Term Considerations

Looking beyond the hardfork, the long-term roadmap involves leveraging new Ethereum capabilities and exploring further enhancements.

This includes integrating advanced features such as triggerable withdrawals  (EIP 7002) and higher effective balance validators and making use of consolidations (EIP 7251), adapting to higher effective balance strategies, and refining monitoring, tooling, and the withdrawals API.

Future protocol upgrades will address these opportunities to enable the optimization of the validator footprint of the Lido protocol, ensuring the protocol evolves in step with Ethereum’s ongoing upgrades and broader network improvements.

List of Upgrades 

Removal of Initial Slashing Penalty:

The immediate penalty for a slashed validator, now approximately 0.008 ETH, is less material compared to the previous 1 ETH deduction. Accounting for this penalty only at final withdrawal is proposed.

Accounting, Validator Exit Bus, and CSM Fee Oracles:

These off-chain services track validator status and compute rewards and penalties. The addition of deposit queues and modified validator balances in Electra requires new logic to handle dynamic waiting periods for validator activation.

CS (Community Staking) Verifier Contract

Proof gIndexes:

Because Pectra reorganizes consensus-layer containers, hashing and indexing rules must be adjusted. A redeployment of the CS Verifier contract is planned to incorporate dual sets of gIndexes (pre- and post-Pectra).

Oracle Report Sanity Checker

The restrictions on protocol modifications that the Oracle can implement have been tightened due to the reduced initial slashing penalty, the newly imposed upper limit on exit churn, and changes in the validator entry queue.

• exitedValidatorsPerDayLimit: Lowered from 9000 to 3600.
• appearedValidatorsPerDayLimit: Lowered from 43200 to 1800.
• initialSlashingAmountPWe: Reduced from 1000 to 8 (0.008 ETH).

Voting & Governance

Two consecutive on-chain votes are planned:

1. Before Pectra: Oracles will adopt an updated consensus version, and the old CS Verifier will be replaced.
2. After Pectra: Additional optimizations, including the updated parameters in the Oracle Report Sanity Checker, will be enacted.

Upgrade Timeline & Fallback Measures

Deployment & Audits

Any new contracts—including the redeployed CS Verifier and Off-chain Oracles—will be audited by external specialists and audit reports will be published before DAO voting.

On-Chain Votes

• Pre-Hardfork Vote: Approval signals readiness for Pectra; the new oracle software and verifier contracts ensure uninterrupted service once the upgrade activates.
• Post-Hardfork Vote: Further parameter adjustments will be ratified, such as updated validator churn and slashing amounts.
• Fallback Plan If the initial vote fails or is delayed, deposits may be paused approximately 24 hours before the hardfork to mitigate operational risks. In that scenario, a separate DAO vote would decide the timing for reopening deposits once post-upgrade stability is confirmed.

Looking Ahead

The additional capabilities introduced by Pectra, such as higher validator balance caps and more robust solutions for validator exits, offer exciting paths for future enhancements. However, only minimal changes required for protocol continuity are addressed at this stage. New features such as triggerable exits in EIP-7002 and consolidation logic in EIP-7251 involve complex changes and may be adopted through separate proposals. An analysis of optimal consolidation parameters is currently in development and will be released soon for community review and discussion.

Meanwhile, execution-layer innovations in Prague—ranging from greater blob support to historical block-hash storage—support broader Ethereum performance goals and may eventually influence how staking services are offered. 

Ongoing analysis will continue to determine whether any direct effects on Lido warrant additional protocol changes.

Further Reading

Increase the MAX_EFFECTIVE_BALANCE (EIP-7251)

The effective balance range for new validators now extends from 32 ETH up to 2048 ETH, moving away from the strict 32 ETH limit. 32ETH is still the min_activation_balance.  Validators from before the upgrade are not affected. Users can change to the new validator configuration via a “Consolidation Request”, as opposed to having to exit. EIP 7251 also introduces the new 0x02 compounding withdrawal credential.

Execution layer triggerable withdrawals (EIP-7002)

Withdrawals and validator exits can be initiated via a validator’s execution layer withdrawal credentials (0x01 or 0x02), reducing the operational responsibilities and trust assumptions placed on the validator key and whoever controls it.

Supply validator deposits on chain (EIP-6110)

The beacon chain no longer parses events from the deposit contract. Instead, a new pending_deposits queue and a deposit_requests mechanism manage inflows, changing the timing by which validators appear on-chain.

General-Purpose Execution-Layer Requests (EIP-7685)

This proposal defines a general-purpose framework for storing contract-triggered requests by extending the execution header with a single field to hold request information—which is later exposed to the consensus layer for processing—and is motivated by the growing demand for additional EL-triggered behaviors from smart contract-controlled validators, enabling these systems to delegate administrative operations directly to their governing contracts without updating the execution block structure, thereby enhancing overall safety.

Prague: Execution-Layer Upgrades

Precompile for BLS12-381 curve operations (EIP-2537)

Add functionality to efficiently perform operations over the BLS12-381 curve—including BLS signature verification through curve arithmetic and multi-scalar multiplication for aggregating public keys or individual signers’ signatures—to provide over 120 bits of security compared to the existing BN254 precompile’s 80 bits.

Serve historical block hashes from state (EIP-2935)

Store and provide the most recent 8,192 block hashes as storage slots in a system contract to enable stateless execution.

Increase Calldata Costs (EIP-7623)

The current calldata pricing permits EL payloads of up to 7.15 MB, although the average size is closer to 100 KB. This EIP proposes adjusting calldata costs to reduce both the maximum block size and its variance without adversely affecting regular users, achieved by increasing costs for transactions that primarily post data.

Blob Throughput Increase & API Enhancements (EIP-7691, EIP-7840)

The number of blobs permitted per block is increased to reach a new target of 6 and 9 blobs per block respectively, and new APIs are provided for managing them.

Set EOA account code (EIP-7702)

Externally Owned Accounts (EOAs) can store executable code, enabling more sophisticated functionality such as native multicalls or delegated operations. The EIP will add a new tx type that permanently sets the code for an EOA. 

EIPs Referenced:

• EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)
• EIP-7002 (Execution layer triggerable exits)
• EIP-6110 (Supply validator deposits on chain)
• EIP-7685 (General purpose execution layer requests)
• EIP-2537 (BLS12-381 precompile)
• EIP-2935 (Save historical block hashes)
• EIP-7623 (Increase calldata cost)
• EIP-7691 & EIP-7840 (Blob throughput & schedule)
• EIP-7702 (Set EOA account code)