Ethereum’s weekly All Core Developer calls are a lot to keep up with, so this “Checkpoint” series aims for high-level updates roughly every 4-5 weeks, depending on what’s happening in core development. See the previous update here.
tl;dr:
The Fusaka upgrade is nearly out the door and we’ll get a very good idea of “wen” this week with the first testnet upgrade going live just a few hours from this post. Glamsterdam headliners have been chosen: enshrined Proposer-Builder Separation and Block-level Access Lists, but small features still have about a week to be proposed for inclusion. Testing teams are looking to push the gas limit beyond 60 million with Fusaka.
Fusaka
Fusaka is looking very likely to be live by end of year. The expected testnet upgrade schedule was announced, the first of which will be executed at 08:48 UTC today. Read an in-depth accounting about what this upgrade includes here.
| Network | Time (UTC) |
|---|---|
| Holešky | 2025-10-01 08:48:00 ✅ |
| Sepolia | 2025-10-14 07:36:00 |
| Hoodi | 2025-10-28 18:53:12 |
| Mainnet | tba (minimum 30 days after Hoodi) |
Testnets
Practicing the fork on public testnets is the last stage of the process. It means that all implementations are seemingly done, bugs were worked out on private devnets, and we’re likely ready to go.
The Holešky testnet will be deprecated very soon after this fork – it was the victim of a config mismatch during Pectra testing in February of this year that resulted in a fork and subsequent long period of non-finality. The testnet validators that committed a slashable offense by voting for the wrong fork were so numerous that it created an extremely long exit queue – an untenable situation for a network meant for testing, where validators need to be on- and off-boarded easily.
This round of fork testing has included robust learnings from this error; The original misconfiguration was addressed by changes that verify fork parameters. Non-finality had never been tested to such an extent and it turned out that clients were inexperienced in recovering from such a state. In the past few months, testing has included a number of planned non-finality events to test recovery.
Timeline
We’ll know on ACD(Consensus) this Thursday (10/2) if the first fork went well and on ACD(Testing) the following Thursday (10/9) if the first Blob Parameter Only fork went well.
The audit contest will continue for two more weeks and assuming the testnets go well with no or only minor bugs, the mainnet upgrade will be announced after developers have had a chance to monitor Hoodi’s upgrade for a few days. Expect a mainnet upgrade date 30 days from the ACD immediately following a successful Hoodi fork.
Glamsterdam
The main features (aka “headliners”) for Glamsterdam, the upgrade that will follow Fusaka, were chosen among a variety of proposals. These features are enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BAL). Smaller features are still being proposed for another week or so and will be chosen based on their readiness, necessity, safety, and compatibility with the headliners. These proposals are made by opening a Github pull request for an EIP against the Glamsterdam Meta EIP.
Timeline
While the focus is firmly on getting Fusaka out the door, implementers are well into testing both ePBS and BAL without the smaller features that have yet to be decided on. Those who would like to see a specific small-feature EIP included in Glamsterdam should propose it within the next week. Proposers of an EIP should be prepared to champion that EIP throughout the upgrade process. The estimate for this fork is still some time in 2026.
Gas limit
We’ve seen a concerted push to scale the L1, which includes scaling the gas limit. Since February, the gas limit has increased from 30 million to 45 million and developers are aiming to increase that even further with Fusaka, looking at potentially exceeding 60 million.
This limit is independent of the fork and is decided by validator configuration, but default client settings can help validator operators know what’s been extensively tested and is safe for the network. Forks are a time when we know validators will be updating so it’s a good time to update client defaults without having to do a communication push to validators.
source: https://etherscan.io/chart/gaslimit
Against all odds, it seems that 2025 will be a year with two ethereum upgrades. As of writing this blog post, the Pectra upgrade was just four and a half months ago. With the amount of implementation, testing, and notice necessary for these upgrades to go live across 12 client teams, I’m truly impressed and hope the devs and testing teams are individually getting the rest they need.
It can’t be overstated just how exceptional adaptations in testing due to lessons learned from Pectra have been. I said it then and I’ll say it again: Pectra created a significantly higher caliber of core developer (we should probably work to make sure they’re better compensated!).
It’ll be a bigger task to keep Glamsterdam speedy. It feels like a long time ago now, but Fusaka’s features were a result of the Pectra upgrade splitting into two separate forks due to complexity and scope. Because of this, PeerDAS had a head start in both implementation and decision-making.
Though the process was streamlined for the first time by formally choosing upgrade headliners before the previous fork was even live, there are still 23 small features proposed for inclusion to be decided on, plus the winter holidays and January sluggishness. Whether this upgrade goes out in mid- or late-2026 is still up in the air.
Relevant ACD calls:
[ July 31st – September 29th ]
