Ethereum’s next major upgrade, Fusaka, is still officially aiming for a November 2025 mainnet fork — but a surprise intervention on yesterday’s All Core Devs Consensus (ACDC) call revealed consensus-client teams want four extra weeks before release candidates are cut.
The request surfaced when Lodestar’s Matthew Keil warned the current September 1 deadline to finalize releases is “aggressive.”
“The timeline that we’ve been talking about is basically 4 extra weeks,” he told the group. The proposed change would move the release-cut date from early September to the end of the month. Mainnet would still target November, although its full effect won’t be felt until early 2026.
Prysm’s Manu Nalepa backed the suggestion, stressing that “testing really close to mainnet regarding private [mempools]” is critical.
“Prysm has also >4k lines of code yet to merge into our unstable branch,” Nalepa wrote his peers in the live chat.
The extra time would allow teams to merge large feature branches, resolve conflicts, and run stability testing on the exact code that will go live. This matters because merging late can introduce subtle bugs that earlier devnet runs never encountered, although testing processes have been beefed up over time.
Fusaka is set to deliver a package of improvements aimed at scaling Ethereum’s data availability and streamlining validator duties. Headline features include PeerDAS to improve how blob data is distributed across the network, raises to the maximum blob limit per block from six to nine, reduction of the target blob count to five to help smooth gas prices, and the addition of new opcodes and precompiles aimed at making the Ethereum Virtual Machine more efficient.
Two areas of testing are especially important: non-finality and private mempool behavior. In non-finality tests, validators stop finalizing blocks — for example, because of outages or mass exits — which leaves recent blocks open to reorganization. Engineers then measure liveness (how quickly the chain resumes finalizing) and safety (ensuring no conflicting histories are finalized) once validators return.
Private mempool testing checks how well transactions, including blob data, are handled when they’re intentionally kept out of the public mempool, a common scenario for block builders using private order flow.
The stakes extend beyond Fusaka itself. This fork enables PeerDAS, Ethereum’s next step in scaling blob (data) availability for rollups, and introduces Blob Parameter Updates (BPOs) — a mechanism to raise blob capacity without another hard fork. The first three BPOs, tentatively set for mid-December, January and February, can only happen after Fusaka ships. Any slip to the fork pushes the entire scaling schedule back.
Some frustration bubbled up over the way the delay request landed. Tim Beiko, who leads the full All Core Devs coordination calls, noted:
“It would have been more productive for each team to individually voice this async ahead of the call. We should minimize the element of surprise in these things as much as we can.”
Ethereum Foundation research Ansgar Dietrichs looked for options to speed up the process on the margins but stressed that people should be free to speak their minds.
“There should obviously never be hesitancy to voice concerns on here,” he wrote in the chat.
No one argued for moving Mainnet past November, but the discussion underscored the trade-off between hitting public milestones and, as Keil put it, making sure the code is “well reviewed, battle tested and hardened and ready.”
For now, the plan is to get Holesky — the long-lived testnet slated for deprecation — live in September, and push toward November, with the goal of wrapping up the testnet phases ahead of Ethereum’s major developer conference Devconnect, held this year in Buenos Aires, Argentina from November 17 to 22.
The consensus takeaway: When it comes to shipping Fusaka, confidence in the code will outweigh the calendar.
Get the news in your inbox. Explore Blockworks newsletters:
Source: https://blockworks.co/news/ethereum-fusaka-upgrade-delay