Ethereum's core development team is moving forward on two parallel upgrade tracks: finalizing Glamsterdam, the immediate priority, while beginning early design work on Hegota, the upgrade expected to follow. This dual-track approach reflects how Ethereum's roadmap evolves, with developers testing near-term protocol changes while researching longer-term improvements to censorship resistance, validator efficiency, and application infrastructure.

What Is Glamsterdam and Why Does It Matter?

Glamsterdam remains Ethereum's immediate delivery priority, with developers preparing for Devnet-6, an important testing checkpoint for the upgrade's remaining protocol changes. Devnet-5 has reportedly stabilized with strong participation, though some client-specific issues remain unresolved. This is normal in Ethereum's upgrade process, where devnets expose edge cases across different client implementations before mainnet deployment.

A major focus of Glamsterdam discussions has been EIP-8282, which introduces builder execution requests through a system contract. This proposal separates validator and builder deposit flows, improving how the protocol handles builder-related execution requests. Core developers broadly agreed the design is directionally correct, but emphasized that correctness matters more than rushing inclusion. Glamsterdam is expected to include major infrastructure work connected to proposer-builder separation and execution-layer coordination, which affects how validators and block builders interact on the network.

Other Glamsterdam-related proposals under review include EIP-8037, which updates state gas refund behavior, and EIP-7928, which focuses on BAL state access restructuring. Developers are still reviewing implementation details for EIP-7928, showing that even seemingly narrow execution-layer changes require careful cross-client coordination.

How Are Developers Preparing Ethereum's Next Major Upgrade?

• Devnet Testing: Glamsterdam Devnet-6 serves as a critical checkpoint where developers test protocol changes across multiple client implementations before mainnet deployment.
• Cross-Client Coordination: Ethereum's upgrade process depends on implementation and testing across multiple execution and consensus clients to ensure interoperability and safety.
• Empirical Validation: Developers use benchmarks and real-world data to determine whether proposed changes are necessary, as shown when EIP-7904 was converted to informational status after data showed clients already exceed targeted compute thresholds.
• Specification Refinement: Teams like Lodestar and Lighthouse rebase their work on devnets and continue testing implementations to catch serialization issues and other technical problems early.

What Is Hegota and Why Focus on Censorship Resistance?

While Glamsterdam remains the near-term focus, Ethereum developers are already shaping Hegota, the next major network upgrade expected after Glamsterdam. Hegota is still in its early design phase, with developers evaluating proposals related to censorship resistance, validator efficiency, transaction inclusion, and execution-layer improvements.

Two proposals stood out in early Hegota discussions. EIP-7645 proposes aliasing ORIGIN to SENDER, addressing long-standing technical debt in the Ethereum Virtual Machine (EVM), the software layer that executes smart contracts. The ORIGIN opcode has historically been discouraged because it can create unsafe assumptions in contract logic. By aligning it more closely with SENDER, Ethereum could simplify old behavior while reducing risks associated with legacy usage patterns. This proposal fits into Ethereum's larger account abstraction roadmap, where smart wallets and delegated execution patterns become increasingly important.

EIP-8304 introduces a trustless log and transaction indexing mechanism using sorted SSZ tables and system-contract commitments. The goal is to allow users and applications to prove log or transaction inclusion without relying entirely on centralized indexing services. This could become important for wallets, explorers, bridges, light clients, and rollup infrastructure. If Ethereum can make transaction and log proofs easier to verify, it would improve the trust model for many applications that currently depend on third-party data providers.

How Does FOCIL Address Ethereum's Censorship Concerns?

One of the most important long-term research tracks remains FOCIL, or Fork Choice Enforced Inclusion Lists. FOCIL is widely discussed as a leading Hegota candidate because it directly addresses Ethereum's censorship resistance guarantees. The basic idea is to make it harder for builders or block producers to indefinitely exclude valid transactions. Instead of relying only on block builders to decide what gets included, inclusion lists would give the protocol a stronger mechanism for enforcing transaction availability.

This week, FOCIL discussions focused on specification cleanup and enforcement details. Developers agreed to remove inclusion-list bitlists from the specification because builders could potentially fake them without a reliable enforcement mechanism. This is a useful example of Ethereum's design discipline: if a mechanism creates complexity without enforceable security guarantees, it is better removed or redesigned.

Another major discussion involved payload status reporting. Developers proposed adding a new payload status field to help clarify whether branches satisfy inclusion-list requirements. This would help consensus clients reason more clearly about compliance across competing branches. The team also discussed a non-finality circuit breaker, which would temporarily disable inclusion-list enforcement after extended periods without finality. This matters because censorship resistance mechanisms should not accidentally worsen chain instability during abnormal network conditions.

FOCIL represents Ethereum's broader commitment to credible neutrality. As block-building markets become more specialized, Ethereum needs protocol-level safeguards that preserve open access and prevent transaction exclusion from becoming a systemic risk.

What Progress Are Ethereum's Client Teams Making?

Ethereum's upgrade process depends heavily on client diversity. Every protocol change must be implemented, tested, and validated across multiple execution and consensus clients before it can safely reach mainnet. This week, client teams reported progress across several areas. Lodestar rebased its FOCIL work on Glamsterdam Devnet-5 and confirmed that a previous serialization issue had been fixed. Lighthouse also rebased on Devnet-5 and continued testing its FOCIL implementation. These updates are important because FOCIL touches consensus behavior, and any ambiguity in implementation could lead to interoperability issues across the network.

The parallel advancement of Glamsterdam and Hegota demonstrates how Ethereum's governance model balances immediate protocol needs with longer-term research. By maintaining active devnets, coordinating across multiple client teams, and iterating on specifications based on empirical data, Ethereum's core development ecosystem continues to evolve the network's infrastructure layer while preserving its commitment to decentralization and censorship resistance.