Ethereum’s core development is currently buzzing with activity, navigating a dual mandate of delivering imminent network upgrades while meticulously planning future enhancements. The highly anticipated Fusaka upgrade is on the cusp of mainnet deployment, scheduled for December 3rd, 2025, marking a significant step in the network’s evolution. Concurrently, core developers are intensely focused on shaping the Glamsterdam upgrade, slated for some time in 2026, which promises foundational changes like enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs). This period also sees the initial discussions for the subsequent Heka / Bogotá upgrade, highlighting a strategic shift towards a more structured and parallelized development roadmap aimed at optimizing efficiency and responsiveness to the community’s needs.
The Fusaka Upgrade: A Seamless Transition and Enhanced Capacity
The Fusaka upgrade, identified by EIP-7607, stands as a testament to the Ethereum core developers’ commitment to continuous improvement and agile deployment. Its journey to mainnet has been remarkably smooth, with comprehensive testing phases concluding successfully across all three major testnets. This includes the successful implementation of two subsequent BPO (Blob transaction Paging Optimization) forks, EIP-7892, which will incrementally increase the network’s data blob capacity. These testnet forks proceeded with notably fewer complications compared to previous Ethereum upgrades, indicating refined processes and robust client implementations. While minor, non-consensus-critical issues are still being addressed by some clients, these are not expected to impede the mainnet activation.
Fusaka is set to go live on December 3rd, 2025, at 21:49 UTC. Ethereum node operators are mandated to update their client software before this activation time to ensure continued compatibility and participation in the upgraded network. An official watch party will be streamed on the Ethereum Protocol YouTube channel, inviting the community to witness this pivotal moment. The upgrade’s features are designed to enhance various aspects of the network, with further details available on the official Ethereum blog and ethereum.org. Notably, the Fusaka-ready client releases incorporate configurations for all three upcoming forks—Fusaka mainnet and both BPO forks—meaning a single client update will prepare node operators for the entire sequence of enhancements.
The BPO forks, part of the broader EIP-7892, represent a strategic effort to scale Ethereum’s data availability layer, which is crucial for the burgeoning Layer 2 ecosystem. The first BPO fork is scheduled for December 9th, 2025, at 14:21 UTC, increasing the target blobs to 10 and max blobs to 15. The second BPO fork will follow on January 7th, 2026, at 01:01 UTC, further expanding these limits to 14 target blobs and 21 max blobs respectively. These incremental increases are vital for managing the growing demand for block space and reducing transaction costs on rollup networks, thereby contributing to Ethereum’s overall scalability roadmap.
This rapid deployment of Fusaka, occurring just 6 months and 26 days after the Pectra upgrade, reflects a deliberate shift in development philosophy. The community has increasingly advocated for faster upgrade cycles, and Fusaka’s timeline prioritizes readiness among most clients rather than waiting for all clients, a departure from previous approaches. This expedited pace was also facilitated by Fusaka’s major features having a head start in implementation, as they were initially scoped as part of the Pectra upgrade before it was strategically split.
Glamsterdam: Forging the Next Generation of Ethereum
As Fusaka reaches its conclusion, the collective focus of the Ethereum development community is rapidly shifting towards the Glamsterdam upgrade (EIP-7773), which is anticipated to launch sometime in 2026. This upgrade is being defined by a more structured and disciplined approach, a direct response to the challenges encountered during the scoping of the Pectra fork, which became overburdened and ultimately had to be divided.
The "headliner" features for Glamsterdam were strategically chosen in August, establishing clear priorities for the upgrade. These include Enshrined Proposer-Builder Separation (ePBS) (EIP-7732) and Block-level Access Lists (BALs) (EIP-7928). ePBS is a critical development aimed at mitigating Maximal Extractable Value (MEV) by separating the roles of block proposer and block builder, thereby enhancing decentralization and censorship resistance at the protocol level. BALs, on the other hand, are designed to improve transaction efficiency and predictability by allowing proposers to specify which accounts can interact with a block, potentially reducing transaction failures and optimizing block space. The implementation of these features is already well underway, forming the backbone of the Glamsterdam upgrade.

The process for selecting minor, "non-headlining" features has also been refined under a new, more stringent structure proposed by ACDE call facilitator Tim Beiko. This new framework, designed to optimize the upgrade process and prevent the issues of scope creep seen in past forks, established clear timelines and deadlines for feature proposals. This resulted in a significantly larger number of proposals than in previous cycles, with 48 features submitted by the October 30th deadline. Core developers and the broader Ethereum community are now engaged in a meticulous review process, evaluating these proposals based on their urgency, compatibility with existing features, and implementation complexity. The community is actively encouraged to provide feedback on these proposed features, particularly if any are deemed critical for users of the core protocol, to ensure that developer priorities align with the most pressing needs.
The Debate Around FOCIL: Censorship Resistance at the Forefront
One of the most intensely debated features for Glamsterdam has been Fork-choice enforced Inclusion Lists (FOCIL). FOCIL, a robust anti-censorship mechanism, garnered exceptionally strong support within the community. While the headliner process typically limits the selection to one feature each for the execution and consensus layers to simplify development, FOCIL’s importance led to its designation as a "Considered" feature, contingent on the progress of ePBS and BALs, and the condition that its inclusion would not significantly delay the overall upgrade.
However, recent discussions in the All Core Devs (ACDC) calls have seen a growing sentiment to move FOCIL to the subsequent upgrade, Heka / Bogotá. This potential decision, while conditional on a credible commitment for its inclusion in that future upgrade, aims to provide clarity for developers. By deferring FOCIL, developers can proceed with the smaller Glamsterdam features without the uncertainty of FOCIL’s complex scoping requirements hanging over their heads.
The implications of this decision are profound. Censorship resistance is a fundamental tenet of Ethereum’s value proposition, ensuring that transactions cannot be arbitrarily excluded from blocks. Delaying FOCIL, even with a commitment for future inclusion, underscores the delicate balance between technical complexity, development bandwidth, and the imperative to deliver critical features. It places the onus on developers and the community to maintain active support and advocacy for FOCIL, preventing it from being overshadowed by other "shiny new major features" that might emerge in the interim. The potential for community desire to wane or for development priorities to shift over time poses a risk to any feature deferred to a distant upgrade, making sustained engagement crucial for FOCIL’s eventual implementation.
Heka / Bogotá: The Next Horizon
Following Glamsterdam, the Heka / Bogotá upgrade represents the next frontier in Ethereum’s roadmap. In line with the new structured cadence of planning one fork while implementing another, discussions for Heka / Bogotá’s headlining features are set to commence shortly after Fusaka’s mainnet activation, likely in early 2026. The star name "Heka" has already been chosen for the consensus layer, and a portmanteau for the combined upgrade is currently under discussion. Given the recent deliberations, FOCIL is widely anticipated to be a frontrunner for inclusion as a headliner in the Heka / Bogotá upgrade, reflecting its continued importance and the community’s strong desire for its implementation. Proposers with significant features for Ethereum are encouraged to begin preparing their "headliner" proposals now, using the established template on Ethereum Magicians, to contribute to the earliest stages of Heka / Bogotá’s definition.
Enhancing Network Throughput: The Gas Limit Increase
Parallel to these structural upgrades, Ethereum is also steadily increasing its fundamental network capacity. All client teams have confirmed their readiness to support a 60 million gas limit with the Fusaka upgrade. This means that node operators are not required to take any special action beyond their regular client updates; all clients will automatically default to the higher 60 million gas limit.
This increase is part of a broader, more systematic approach to managing the network’s gas limit. Nethermind, a leading client team, has established a robust framework for evaluating and targeting safe gas limit increases, providing a data-driven methodology for these crucial decisions. This structured approach is expected to lead to continued regular increases in the default gas limit, enhancing the network’s transaction throughput and overall efficiency. Furthermore, individual node operators retain the ability to signal their support for even higher gas limits by manually configuring their client settings, contributing to the decentralized governance of this vital network parameter.

Developer Engagement and Community Dynamics
The current period is also influenced by Devconnect week, a major gathering of the Ethereum community. While such events can sometimes lead to a temporary slowdown in remote development progress, as many core developers are traveling or engaged in in-person meetings, they also present unique opportunities. Face-to-face discussions among core developers can often accelerate consensus on complex issues and lead to decisive breakthroughs for future upgrades like Glamsterdam. However, the immediate impact includes the cancellation of the next two Monday Testing calls, highlighting the trade-offs involved.
The weekly All Core Developer calls (ACDT for Testing, ACDC for Consensus, ACDE for Execution) remain the primary forums for coordinating Ethereum’s technical roadmap. These calls, while highly technical and frequent, are crucial for transparent decision-making. Resources like the "Checkpoint" series and Forkcast summaries, which provide call summaries, chats, and transcripts within hours of each meeting, are invaluable tools for the broader community to stay informed and engaged with the intricate details of core protocol development.
Analysis: Evolution of Ethereum’s Upgrade Strategy
The current phase of Ethereum development marks a significant evolution in its upgrade strategy. The tension between "shipping safe" and "shipping fast" has been a perennial challenge. Fusaka’s expedited delivery, driven by community demand for faster forks and a head start in feature implementation, demonstrates a leaning towards speed, with dates chosen based on the readiness of most clients. This stands in contrast to past approaches where readiness from all clients was a prerequisite, often leading to longer delays.
The new structured process pioneered for Glamsterdam, with its clear headliner selection, strict deadlines for minor feature proposals, and community feedback mechanisms, is a direct attempt to mitigate the "chaos and stress" observed in previous, less-defined upgrade cycles like Pectra. If this new framework proves effective, it suggests that the greatest gains in efficiency might come from long-term planning and a well-defined structure for each step of the upgrade process, rather than simply pressuring developers to accelerate their work. This could pave the way for experimenting with even better parallelization of planning and development across multiple future forks.
Conversely, if Glamsterdam still feels as overwhelming as Pectra initially did, it will necessitate a re-evaluation of how to manage the community’s enthusiasm for a wide array of features. The "we can do it all" mindset, while reflective of Ethereum’s innovative spirit, must be balanced against the practical constraints of development.
The saga of FOCIL underscores a critical challenge in long-term protocol development: making definitive commitments for features two or more forks into the future. Historical experience shows that community priorities can shift, and what seems urgent today might lose momentum tomorrow. Removing a feature that developers have already begun planning or working on can be a problematic and demoralizing process. Therefore, for FOCIL, or any other critical feature deferred, sustained advocacy from both developers and the community is paramount. The fundamental value of censorship resistance for Ethereum cannot be understated, and it is imperative that this focus is not diluted by the emergence of other exciting, but potentially less foundational, features.
In conclusion, Ethereum is navigating a complex and dynamic period of growth and refinement. With Fusaka’s successful testnet phase and imminent mainnet launch, the network demonstrates its capacity for rapid, yet robust, upgrades. The methodical planning for Glamsterdam, coupled with a renewed focus on structured development processes, reflects a maturing ecosystem striving for greater efficiency and predictability. The ongoing debates, particularly around features like FOCIL, highlight the vibrant, community-driven nature of Ethereum’s evolution, where technical progress is constantly balanced against core philosophical values. As Devconnect facilitates intense, in-person collaboration, the foundation for Ethereum’s future trajectory is being laid, promising continued innovation and an unwavering commitment to its decentralized vision.








