Ethereum's next major upgrade, Glamsterdam, is moving from active development into a stabilization phase, with core developers preparing Devnet 7 as the final dedicated testing environment before the upgrade reaches public testnets. This transition marks a significant milestone for one of Ethereum's most ambitious protocol changes, introducing enshrined proposer-builder separation (ePBS) and other execution-layer improvements designed to enhance the network's scalability and security.

What Is Glamsterdam and Why Should Ethereum Users Care?

Glamsterdam represents a coordinated set of protocol improvements targeting Ethereum's execution layer, the part of the network that processes transactions and maintains state. The upgrade introduces several technical enhancements, but the most significant is ePBS, which moves proposer-builder separation into Ethereum's protocol itself rather than relying on external mechanisms. This change aims to reduce centralization risks and improve how blocks are constructed and proposed.

For everyday Ethereum users and stakers, Glamsterdam's improvements could translate into more efficient block production, better transaction ordering, and reduced reliance on external services that coordinate block building. Staking pools, validators, and infrastructure providers will need to prepare for API changes and new builder deposit and exit mechanisms that the upgrade introduces.

When Will Devnet 7 Launch and What Happens Next?

Devnet 7 is targeted for the week of July 14, 2026, representing a slight delay from an earlier July 9 target to incorporate additional specification and testing changes. Once Devnet 7 launches, developers intend to introduce a mild specification freeze, meaning structural changes should largely stop while minor parameter adjustments may still be accepted.

This distinction is important for understanding the upgrade's timeline. Changes such as modifying gas-cost parameters could still be considered if benchmark data justifies them, but larger structural modifications would face a much higher threshold. Devnet 6, the current testing environment, is operating at approximately 80% participation, with client teams investigating remaining interoperability issues before the transition to Devnet 7.

Following Devnet 7's stabilization, a public Gloas application-testing devnet is targeted for early August 2026. This environment will give staking pools, builders, distributed validator technology (DVT) providers, and other ecosystem participants a more accessible opportunity to test ePBS integration before mainnet deployment.

How to Prepare for Glamsterdam: Key Steps for Ecosystem Participants

• Staking Pools: Review the updated Beacon API PR #625, which introduces a ProduceBlock v4 POST endpoint with per-builder authentication and configuration capabilities. Test integration with the new builder deposit and exit contracts defined in EIP-8282 before mainnet activation.
• Block Builders: Understand the new ePBS deadlines, including 3-second attestation, 6-second payload, and 9-second payload-timeliness committee (PTC) deadlines established for Devnet 7 testing. Prepare for circuit breaker logic that may ban or unban builders based on performance.
• DVT Providers and Validator Tooling Teams: Monitor the Gloas public devnet launching in early August 2026 to test ePBS-related changes in a production-like environment. Ensure validator client implementations support the new API endpoints and builder interaction flows.
• Infrastructure Providers: Investigate and resolve any client-specific issues identified during Devnet 6 testing, such as storage-read disagreements during reverts. Ensure consistent implementation across execution clients before Devnet 7 launch.

What Technical Changes Are Included in Glamsterdam?

Several key Ethereum Improvement Proposals (EIPs) form the backbone of Glamsterdam. EIP-7928 introduces Block Access Lists, allowing the protocol to expose information about state locations accessed during block execution. This change helps execution clients prepare state data earlier and potentially improves parallel execution and block processing efficiency.

EIP-8038 adjusts gas costs associated with state access to better reflect Ethereum's actual computational and storage costs. The repricing numbers are considered sufficiently stable for Devnet 7, although final confirmation remains dependent on the complete benchmark suite. For smart contract developers and enterprises operating gas-sensitive applications, even if application logic remains unchanged, repricing can affect transaction economics for contracts that perform storage-intensive operations.

EIP-8282 defines builder deposit and exit contracts supporting Glamsterdam's ePBS architecture. The contracts have been finalized, although an audit remains pending. The builder exit queue will remain disabled before the fork and become active afterward. For staking pools, builders, and infrastructure providers, EIP-8282 is especially important because it helps define how builders enter and exit Ethereum's protocol-enforced proposer-builder separation system.

How Is ePBS Changing Block Production on Ethereum?

Enshrined proposer-builder separation represents a fundamental shift in how Ethereum constructs blocks. Rather than relying on external mechanisms like MEV-Boost, ePBS moves this coordination into the protocol itself. Recent discussions have focused heavily on deadlines, builder behavior, APIs, and circuit breakers that establish when different components of the ePBS workflow must be delivered during a slot.

One important simplification involves Produce Block v4. Developers agreed to remove the blinded execution payload from the stateful flow because it introduced additional complexity while offering minimal performance benefit. This decision reflects the broader goal of balancing technical sophistication with practical implementation simplicity.

Circuit breakers are also progressing. Teku and Lodestar have implemented builder-index-aware ban and unban logic. Prysm is considering a trusted-builder fallback before switching to local block building, designed to reduce the risk of sybil attacks involving malicious peer-to-peer bids. These safety mechanisms help protect the network from bad-acting builders while maintaining the benefits of external block production.

What Issues Remain Before Mainnet Deployment?

Devnet 6 has exposed several implementation and interoperability problems that client teams are working through ahead of Devnet 7. Developers are investigating a Nethermind disagreement involving storage reads during reverts, while earlier testing also exposed issues involving Besu, Prysm, Nimbus, Teku, and Erigon clients. These problems are precisely why devnets exist; they allow client teams to identify disagreements and edge cases before an upgrade reaches public testnets or mainnet.

A remaining specification issue concerning EIP-8038 involves an additional pre-access check before a slot database read. Developers identified the need for a behavioral specification change in either EIP-8038 itself or EIP-7928. The execution client teams have been asked to review the technical discussion and ensure consistent implementation across all clients.

For enterprises and infrastructure providers, the main takeaway is that Glamsterdam is entering a more stable phase. The feature set is increasingly fixed, and attention is moving toward interoperability, implementation consistency, and ecosystem preparation. The transition from Devnet 6 to Devnet 7 signals that the upgrade is progressing on schedule toward eventual public testnet and mainnet deployment.