Ethereum’s next major upgrade cycle is beginning to take clearer shape through Glamsterdam, a network upgrade currently moving through active testing, implementation review, and client coordination.

State of Upgrade is a new EtherWorld series tracking Ethereum’s next major network upgrade through implementation progress, testing milestones, client readiness, and ecosystem coordination. In this first Glamsterdam edition, developers are focused on stabilizing Devnet-5, preparing Devnet-6, advancing networking improvements, and finalizing key protocol components that could shape the upgrade’s path to mainnet.

Glamsterdam follows Ethereum’s recent upgrade pattern, where major changes are tested across several devnets before being considered ready for public testnets and eventually mainnet. Similar to previous upgrade cycles covered by EtherWorld in All Core Developers Execution call updates and All Core Developers Consensus call updates, Glamsterdam is not only about one headline feature. It is a coordination effort across execution clients, consensus clients, APIs, networking, validator workflows, and builder-related infrastructure.

Recent developer discussions show that Glamsterdam is moving forward, but cautiously. Client teams are prioritizing correctness, stability, and interoperability over speed. This is especially important because several components under discussion, including Gloas-related APIs, builder deposits, SSZ Engine API changes, and networking upgrades, could affect how validators, builders, clients, and infrastructure providers interact with Ethereum after the upgrade.

• Devnet-5 Stability & Testing Progress
• Beacon API, Builder Infrastructure & EIP-8282
• Devnet-6 Roadmap & Ecosystem Impact

Devnet-5 Stability & Testing Progress

A major focus of recent Glamsterdam work has been glamsterdam-devnet-5, which exposed important edge cases across consensus clients.

The devnet experienced instability due to a Prysm peering bug and a Grandine fork-choice bug. These issues became more visible after testing with a malicious Lodestar client that intentionally built chains on empty blocks. While such behavior does not represent normal network conditions, it helped developers uncover edge cases that are valuable before a wider public rollout.

One of the key issues involved Prysm broadcasting invalid PTC attestations across shuffling boundaries during long forks. Developers deployed a mitigation that skips PTC duties when validators are not part of the committee for the observed block’s shuffling configuration.

This matters because Glamsterdam testing is not only about confirming that clients work under ideal conditions. It is also about seeing how clients behave during forks, long reorg-like scenarios, unusual block-building patterns, and adversarial testing conditions.

Developers also raised concerns around how clients currently use only the canonical head for PTC duties. If multiple branches exist without cross-branch PTC attestations, there may be liveness risks that need deeper review. These kinds of findings are exactly why Ethereum upgrades go through multiple devnet stages before reaching production.

Although Devnet-5 has become more stable, some issues remain. Prysm continues addressing gossip and PeerDAS column issues that can trigger fallback to initial sync, while Grandine is still working through remaining edge cases.

This reflects a familiar Ethereum development approach: break things early, diagnose carefully, and avoid rushing toward public testnets until client teams are confident that the network can remain stable under complex conditions.

For readers following Ethereum’s broader development process, EtherWorld’s coverage of Ethereum upgrade calls provides a useful background on how these testing stages fit into the larger roadmap.

Beacon API, Builder Infrastructure & EIP-8282