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-6 weeks, depending on what’s happening in core development. See the previous update here.
If you enjoy reading core development updates, you may also be keen to learn that Forkcast now publishes call summaries, chats and transcripts for each All Core Devs call, usually available within a couple hours of the call.
tl;dr:
The Fusaka upgrade is nearly out the door, Glamsterdam is ramping up, with its major features in implementation and minor features being decided on. Conversations around the Heka / Bogotá upgrade will begin soon.
If you’d like to give your input on which minor features to include in Glamsterdam, now is the time. There’s not yet consensus on whether or not the anti-censorship transaction feature (FOCIL) will definitely be included or delayed to a later upgrade. If you have a large feature you’d like to propose for Ethereum, you should start preparing your headliner proposal for the Heka / Bogotá upgrade discussion, likely to kick off in early 2026.
It’s Devconnect week! Slower-than-usual progress for the next two weeks is possible. On the other hand, in-person discussions could accelerate decisiveness for Glamsterdam decisions.
Fusaka
Testing for this upcoming upgrade is complete, with Fusaka and both BPO forks having successfully gone live on all three major testnets with very few issues. For historical context, the testnet forks went much more smoothly than they generally do with these Ethereum upgrades. While some clients are still seeing small issues, they are not consensus-critical and will therefore not delay the upgrade.
Fusaka will go live on December 3rd at 21:49 UTC & a watch party will stream from the Ethereum Protocol youtube channel. Node operators must update before that time to remain compatible with the network after the upgrade. An overview of its features can be found in the mainnet announcement blog post and on ethereum.org.
Timeline
A note for node operators: the Fusaka-ready client releases contain configurations for all three of the following forks. Only one update is needed to correctly follow the upgrades.
| Event | Time (UTC) | Target blobs | Max blobs |
|---|---|---|---|
| Fusaka mainnet | 2025-12-03 21:49 | 6 (unchanged) | 9 (unchanged) |
| BPO fork 1 | 2025-12-09 14:21 | 10 | 15 |
| BPO fork 2 | 2026-01-07 01:01 | 14 | 21 |
Glamsterdam
With Fusaka wrapping up, focus is shifting toward future upgrades. Directly following Fusaka, Glamsterdam is aiming for ‘some time in 2026’. Its major features (”headliners”), enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs) were chosen in August while the minor (”non-headlining”) features are currently being debated.
When the Pectra fork was scoped in 2024, the upgrade timeline was fairly flexible and the upgrade didn’t have a clear headliner, which resulted in an overburdened fork that had to be split in two. In response to this, the ACDE call facilitator Tim Beiko proposed a clearer, more strict structure to scoping an upgrade in order to optimize the process.
This is the first upgrade that has had a clear timeline and deadlines from the start, resulting in a much larger number of features being proposed than in the past. The deadline to propose non-headlining features was October 30th, with 48 features proposed in time. Core developers and the community are currently reviewing this list to determine which of these should be prioritized. Features will be chosen based on overall need / urgency, compatibility with other features, and their levels of complexity.
If one of these features is particularly urgent for users of the core protocol, the Ethereum community is asked to chime in to help core developers understand that need.
FOCIL
While the headliner process encouraged the community to choose only one feature each for the execution and consensus layers for the sake of simplicity, Fork-choice enforced Inclusion Lists (FOCIL), which is a censorship-resistance feature, had exceptionally strong support and was moved to a conditional “Considered” status while the two chosen priorities were moved to “Scheduled” status. This was discussed as being dependent on the progression of ePBS (the consensus layer feature and, to some extent, BALs (the execution layer feature) and also requires that FOCIL not significantly delay the upgrade.
In this week’s All Core Devs, there was support for moving FOCIL to the upgrade that will follow Glamsterdam, Heka / Bogotá, conditional on a yet-to-be-determined credible commitment for it to be in that upgrade. This decision will better inform developers on their availability to work on the smaller features, so they’re not in limbo about whether or not they’ll need to be scoping with FOCIL in mind.
Timeline
There is not yet a proposed timeline for Glamsterdam beyond ‘some time in 2026’. It will depend on the total scope of the features chosen and the progress being made on the headliners. It’s likely that the finalized set will be decided by the end of this year, then developers can focus on implementation and choosing the next upgrade’s major features.
It’s Devconnect week, which means that in-person conversations can accelerate consensus for next week’s All Core Devs Execution call, but the next two Monday Testing calls are cancelled.
Gas limit
All clients have confirmed readiness for 60 M by Fusaka. No action is needed by node operators beyond normal client updates before Fusaka – all clients will default to 60 M. Expect continued regular gas limit default increases now that there’s an established framework by Nethermind to think about safe limits to target. Node operators can still always signal their support for higher values by manually configuring their limits.
Heka / Bogotá upgrade
With a now-established cadence of planning one fork while we implement the other, we can begin discussing the headline features for the Heka / Bogotá upgrade after Fusaka is live. Heka was chosen as the star name and the portmanteau is still under discussion. After this week’s All Core Devs call, we can expect FOCIL to be the frontrunner in the headliner selection process.
Fusaka has been subject to the tension between two shipping priority strategies: ship safe or ship fast. The community has been pushing for faster forks and it shows in decision-making – Fusaka will ship 6 months and 26 days after Pectra, partially as a result of prioritizing speed more-so than in the past. Where dates in past forks have generally been chosen based on when all clients are ready, Fusaka’s timeline leaned more into dates when most clients were ready.
There was a unique edge to Fusaka’s readiness in that its major features were originally part of Pectra before the upgrade was split into two, so their implementation had a head start, in a way. I don’t expect to see the same timeliness in Glamsterdam though I do expect there to still be a push to ship as fast as possible.
If this new structured process pioneered in the Glamsterdam upgrade does result in less chaos and stress, and more efficiency than Pectra had, it seems clear to me that the most gain is in long-term planning and defined structure for each step of the upgrade, rather than simply pushing developers to move faster, and we can then move to experiment with better parallelizing planning and development for future forks.
If, however, Glamsterdam does still feel as overwhelming as Pectra initially did, we’ll need to figure out how to more effectively rein in enthusiasm for adopting a wide set of features and a mindset of “we can do it all” at the outset of an upgrade.
For FOCIL being moved to Heka / Bogotá: it’s tricky to definitively commit to a feature in an upgrade two forks in the future. We’ve learned this in the past when a feature has been scheduled but the community moves on from their desire to implement it, and then it’s an unfairly problematic process to have to remove it when developers are planning on it and have already begun work on it.
If moved to the following upgrade, the best thing devs and the community can do for FOCIL is keep up active support for its prompt inclusion and not move on to a shiny new major feature that could diminish the understood urgency. Censorship resistance is critical for the fundamental value of Ethereum and it’s important not to lose focus on that if some other exciting feature gains strong narrative.
Relevant ACD calls:
[ October 2nd – November 13th ]
