Ethereum developers have finalized the schedule for upcoming network upgrades. Major changes are set to take place on the 24th of February, March 5, and April 8. Key decisions were finalized during the recent All Core Developers Execution (ACDE) Call 205, held on February 13, 2025.
The bi-weekly Zoom meeting discussions were led by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko. Developers confirmed that the Pectra upgrade would be activated on the Holesky testnet on Feb 24. Afterwards the Sepolia testnet will go up on March 5.
If both rollouts proceed smoothly, Ethereum’s mainnet will receive the upgrade around April 8.
Beiko said he would coordinate with teams to find a volunteer for deploying Pectra system contracts on both testnets.
Debates over future Ethereum forks and upgrade speed
In addition, the team of developers discussed the next planned upgrade after Pectra and Fusaka. Beiko proposed freezing the scope of Fusaka by the time Pectra launches on the mainnet.
The timeline allows developers to begin work on Fusaka while also planning for the subsequent hardfork Glamsterdam.
The Geth development team does not want to work with this timeline. They argue that it was premature to cement the scope of Fusaka. The inclusion of the Ethereum Improvement Proposal (EIP) EOF in Fusaka has sparked considerable debate. A faction of developers argue for its exclusion from the upcoming upgrade.
EOF (Ethereum Object Format) is an upgrade aimed at improving the way smart contracts are structured and executed on the Ethereum blockchain.
Geth developer Lightclient opposed the speeding up of the Fusaka scope freeze. The developer argues that Ethereum’s priorities might shift over the next two years. He pointed out that while developers aim for six-month upgrade cycles, real-world delays could stretch them to eight months or longer. This means important improvements might not be implemented for years.
Lightclient raised concerns regarding the incorporation of EOF, highlighting the quick progress of Ethereum’s zero-knowledge rollup technology (zkEVMs). Developers remain in the dark regarding the interplay of these changes with the virtual machine.
During the discussion, Geth developer Marius van der Wijden listed his preferred scope for Fusaka, which included PeerDAS, FOCIL, EOF, and upper bounds for modexp. EF Developer Operations Engineer Parithosh Jayanthi pushed back, stating that FOCIL was not as ready for implementation as PeerDAS and EOF.
Pectra software testnet upgrades and community feedback
The devs moved past their disagreements over Fusaka to express confidence in the ongoing Pectra deployment. EF Development and Operations Engineer Parithosh Jayanthi reported that Pectra Devnet 6 was performing well, with near-perfect validator participation rates.
Additionally, Ethereum’s Ephemery testnet activated the Pectra upgrade a few hours after the ACDE call, allowing developers to conduct further testing.
Beiko asked Pectra EIP authors to move their proposals to the “last call” phase on GitHub. This signals final steps before mainnet implementation. He also looked into the feedback from the Ethereum community. To that end, he noted that the most common request was to accelerate upgrade cycles.
In response, he suggested that Ethereum developers should aim to finalize the scope of each upgrade as soon as the previous one goes live on the mainnet.
Beiko’s proposed timeline for finalizing the Fusaka scope states that, by March 13, developers must propose EIPs for inclusion in the upgrade. Two weeks later, on March 27, client teams will share their preferences on which EIPs should be considered for Fusaka. Finally, by April 10, the scope of the upgrade will be finalized.
However, EF Researcher Ansgar Dietrichs added an exception to the timing. He noted that PeerDAS code improvements, a critical component of the Pectra upgrade, should be uploaded to the Ethereum mainnet as soon as they are complete. No one objected to this requirement.
Concerns over EELS and EIP testing standards
Another point of concern during the ACDE call was a proposal from EF Testing Engineer Mario Vega. This came in regard to the Ethereum execution layer testing framework. Vega suggested making EELS (Ethereum Execution Layer Specifications) and EEST (Ethereum Execution Specification Test cases) mandatory for any EIP included in a hard fork.
He suggested that this would improve the testing workflow and standardize how EIPs are evaluated prior to adoption.
However, several developers were against the proposal. The reason? The requirement could slow down the upgrade process. Van der Wijden argued that EELS maintainers might become the de facto gatekeepers of EIP inclusion. Why? Not all devs are capable of writing Python-based implementations of their proposals.
Wijden suggested an alternative approach. ETH should have EELS implementations that could be submitted as unmerged pull requests. This prevents the EELS team from having final approval power over upgrades.
Justin Florentine with Ethereum client Besu advised the community to consider creating an additional scripting language. This would clarify whether an EIP can be included without EELS or EEST test cases.
