Ethereum core developers are preparing Devnet 7 as the final dedicated testing environment for the Glamsterdam upgrade, marking a critical transition from active feature development toward stabilization and ecosystem preparation. This shift signals that the upgrade's core feature set is increasingly locked in, and attention is now moving toward ensuring different client implementations work together smoothly and that infrastructure providers can integrate ePBS (enshrined proposer-builder separation) into their systems.

What Is Glamsterdam and Why Should Infrastructure Teams Care?

Glamsterdam is a major Ethereum upgrade that introduces several technical improvements designed to make the blockchain more efficient and secure. The upgrade includes changes to how validators propose blocks, how state data is accessed, and how gas costs are calculated. For infrastructure teams, staking pools, and block builders, these changes mean significant integration work ahead. Devnet 7 represents the point where the specification becomes largely frozen, meaning large structural changes will no longer be accepted.

The current launch target for Devnet 7 is the week of July 14, 2026, a slight shift from an earlier July 9 target to allow for additional specification refinement. Devnet 6, the previous testing environment, has been running at approximately 80% participation, though several client-specific issues remain under investigation.

Which Technical Changes Are Most Important for Validators and Builders?

Several key proposals within Glamsterdam will directly affect how infrastructure operates. EIP-7928 introduces Block Access Lists, which expose information about the state locations accessed during block execution. This change helps execution clients prepare state data earlier and potentially improves parallel execution and block processing efficiency. An additional change to EIP-7928 will be included directly in Devnet 7 rather than deferred to future testing.

EIP-8038 adjusts gas costs associated with state access to better reflect Ethereum's actual computational and storage costs. This matters for smart contract developers and enterprises running gas-sensitive applications because even if application logic remains unchanged, repricing can affect transaction economics for contracts that perform storage-intensive operations. The repricing numbers are considered sufficiently stable for Devnet 7 testing.

EIP-8282 defines builder deposit and exit contracts supporting Glamsterdam's ePBS architecture. The contracts have been finalized, though an audit remains pending. For staking pools, builders, and infrastructure providers, this proposal is especially important because it helps define how builders enter and exit Ethereum's protocol-enforced proposer-builder separation system.

How to Prepare for Glamsterdam's ePBS Integration

• API Readiness: Review Beacon API PR #625, which introduces a ProduceBlock v4 POST endpoint with per-builder authentication and configuration capabilities. This is a practical readiness issue that can directly affect how external infrastructure interacts with validators and builders once ePBS moves closer to deployment.
• Circuit Breaker Implementation: Understand how circuit breakers work in your infrastructure. Teku and Lodestar have already implemented builder-index-aware ban and unban logic, while Prysm is considering a trusted-builder fallback before switching to local block building to reduce sybil attack risks.
• Deadline Compliance: Prepare for ePBS workflow deadlines: 3-second attestation, 6-second payload, and 9-second PTC (proposer-to-committee) deadlines established for Devnet 7 testing. These parameters establish when different components of the ePBS workflow must be delivered during a slot.
• Testing in Gloas Devnet: Plan to participate in the public Gloas application-testing devnet targeted for early August 2026, which will give staking pools, builders, DVT (distributed validator technology) providers, and other ecosystem participants a more accessible opportunity to test ePBS integration.

The infrastructure teams most directly affected by these changes include staking pools, block builders, DVT providers, and validator client tooling teams. These groups will need to coordinate closely with client development teams to ensure their systems can handle the new ePBS requirements.

Devnet 6 has already exposed several implementation and interoperability problems that client teams are working through ahead of Devnet 7. One notable issue involves a Nethermind disagreement with 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.

The decision to treat Devnet 7 as the final dedicated devnet is significant because it introduces what developers call a "mild specification freeze." This means structural changes should largely stop, though minor parameter adjustments may still be accepted if benchmark data justifies them. Changes such as modifying gas-cost parameters for EIP-8038 or EIP-2780 could still be considered, but larger structural modifications would face a much higher threshold after Devnet 7 begins operating.

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. This stability window is the ideal time for infrastructure teams to begin integration planning and testing strategies before the upgrade moves to public testnets and eventually mainnet deployment.