Ethereum Developers Delay Pectra Fork to Mid-May for Stability

Ethereum core developers have made a strategic decision to prioritize stability over speed in the development of the Ethereum network. During a recent All-Core Developers call, the developers debated several options to address issues with the Holesky testnet, which was hindered by a validator exit queue of over a million, potentially taking more than a year to clear. The options considered included launching a new testnet (Hoodi), using DevNet 6 as a temporary testnet, spinning up a short-term shadow fork of Holesky, and implementing a hard fork to clear Holesky’s exit queue.

Protocols like Lido and EigenLayer, which manage significant amounts of staked ETH, preferred the hard fork option as it would allow them to avoid redeploying infrastructure and focus solely on Pectra-specific testing. However, Ethereum client teams opposed this option due to the risks associated with making one-off modifications to the execution queue, which could potentially affect mainnet stability. Additionally, any delays from debugging a Holesky fix could impact the development timeline for Fusaka, the next major upgrade for Ethereum.

As a result, the Pectra mainnet fork has been officially delayed to mid-May. Hoodi is set to go live on March 17, with Pectra activating there on March 26. This decision allows client teams to refine their code and lay the groundwork for Fusaka, while liquid staking teams like Lido and EigenLayer face an extended migration timeline. The deadline for submitting EIPs (Ethereum Improvement Proposals) for Fusaka is now March 24, with core teams expected to share their feedback by March 31, leading to a final scope decision in early April.

To streamline future All-Core Developers calls, Ethereum Foundation coordinator suggested moving more EIP proposal presentations to an asynchronous process, with only those requiring deeper technical discussions being reviewed live. A new EIP status, "declined for inclusion," has also been introduced, reserved for EIPs that teams feel should be deferred to a future fork but not rejected outright. This approach aims to balance the need for thorough testing and stability with the urgency of implementing new features and improvements.