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

Alongside Devnet-5 stability work, several important specification and infrastructure updates are progressing under the Glamsterdam umbrella.

One of the most significant updates is the Gloas Proposer Preference API, tracked under beacon-APIs PR #608. This API was approved for merge and introduces new POST and GET endpoints along with Server-Sent Events support. It also deprecates older endpoints such as prepare-beacon-proposer and register-validator.

This change is important because proposer and builder workflows are becoming increasingly sophisticated. As Ethereum continues evolving around proposer-builder separation, APIs need to provide cleaner, more reliable ways for validators, clients, and infrastructure providers to coordinate.

Beacon API PR #606 also expands /eth/v1/node/peers with optional peer scoring information and disconnect reasons. This can help node operators and client teams better diagnose networking issues, especially during devnet instability.

Another API-related discussion involves validator pending-state naming. Following changes introduced by EIP-6110 and EIP-7251, Beacon API terminology may need updates, potentially requiring a version bump due to breaking changes. This is especially relevant for tooling teams, explorers, staking dashboards, and infrastructure providers that rely on Beacon API responses.

Networking upgrades are also progressing. Developers continue moving from MPLEX toward QUIC as Ethereum’s primary transport layer. However, client teams agreed that MPLEX should remain as a fallback for now. Lighthouse plans to remove MPLEX roughly two months after Gloas, while Teku and Nimbus need more time before fully retiring MPLEX.

This cautious decision helps preserve network reliability while still moving Ethereum toward a more modern networking stack.

The most important builder-related proposal currently under discussion is EIP-8282, which introduces a separate builder deposit contract. The goal is to reduce denial-of-service risks that could emerge from using a shared validator and builder deposit contract.

Developers generally agree that EIP-8282 is the correct long-term architectural direction. However, there are concerns around timeline risk, implementation complexity, and audit requirements. Because builder infrastructure is closely tied to Ethereum’s post-Merge block production pipeline, any changes in this area require careful review.

EIP-8282 was initially deferred for more attack-scenario analysis, but it later moved to Considered for Inclusion status for Glamsterdam and was included in Devnet-6 planning. Execution-layer teams are expected to review the EIP-8282 system contract before final approval.

The Staked Builder API was also approved and merged, marking another important step in Ethereum’s builder infrastructure roadmap. Discussions around submitBeaconBlock continue because of concerns about beacon nodes needing to track which builder supplied each bid.

For more context on Ethereum’s builder and censorship-resistance roadmap, readers can explore EtherWorld’s article on Hegota and censorship resistance, which connects future upgrade planning with Ethereum’s neutrality goals.

Devnet-6 Roadmap & Ecosystem Impact

The next major milestone is glamsterdam-devnet-6, currently targeted for launch on June 25.

Developers aim to have test vectors ready for all remaining Devnet-6 EIPs before launch. EIP-8282 is expected to be included, alongside remaining repricing proposals. Client and tooling teams are also expected to align implementations with the updated SSZ Engine API specification.

The SSZ Engine API, tracked under execution-apis PR #793, already has implementations across multiple clients. While it is considered lower priority than immediate fork work, it remains an important part of Ethereum’s long-term technical cleanup and standardization effort.

The main action items before Devnet-6 include:

• Client teams reviewing EIP-8282 attack scenarios and implementation costs
• Execution-layer teams reviewing the EIP-8282 system contract
• Consensus and execution clients aligning SSZ Engine API implementations
• Tooling teams evaluating validator-state API renaming impacts
• Test vector readiness for remaining Devnet-6 EIPs

The ecosystem implications of Glamsterdam are significant. For validators, Beacon API updates and proposer preference changes could affect how staking operations interact with clients. For builders, EIP-8282 and the Staked Builder API could reshape parts of Ethereum’s builder participation model. For node operators, QUIC migration and peer diagnostics may improve networking visibility and reliability. For developers and infrastructure providers, API changes may require updates across dashboards, monitoring tools, and backend systems.

More broadly, Glamsterdam shows Ethereum continuing to mature as a protocol. The upgrade is not only about shipping new features; it is about improving the reliability of Ethereum’s core infrastructure while preparing the network for more advanced proposer-builder and validator workflows.

This also connects with the wider Ethereum roadmap covered in EtherWorld’s ACDE updates and ACDC updates, where client readiness, EIP inclusion, and devnet testing remain central to every major upgrade cycle.

If Devnet-6 launches successfully and proposals like EIP-8282 perform well under testing, Glamsterdam will move one step closer to becoming Ethereum’s next major protocol upgrade. However, developers remain clear that correctness comes before speed.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Highlights from the All Core Developers Consensus Call #180
2. Hegota Should Complete the Holy Trinity of Censorship Resistance
3. Vitalik Buterin’s 2026 Vision for Ethereum Foundation
4. Ethereum Introduces Clear Signing for Safer Crypto Transactions
5. TheDAO Security Fund’s First Funding Round Goes Live with Over $1M for Ethereum Security

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.