Glamsterdam is moving closer to specification stability. Ethereum core developers are now preparing Devnet 7 as the final Glamsterdam devnet, marking a transition from active structural changes toward stabilization, interoperability testing, and eventual public testnet readiness.

The latest discussions across Ethereum's execution, consensus, and testing calls reveal a clear shift in priorities. Rather than expanding Glamsterdam's scope, developers are concentrating on resolving remaining specification changes, stabilizing client implementations, finalizing ePBS behavior, and testing the upgrade under increasingly production-like conditions.

Devnet 6 remains operational with approximately 80% participation, although several client-specific issues are still under investigation. Meanwhile, Devnet 7 is targeting the week of July 14, 2026, with Prysm, Nimbus, and Lodestar already passing relevant tests, Teku updating its branch, and Grandine expected to become ready shortly.

• Glamsterdam Devnet 7 Becomes the Final Testing Milestone
• What Is Changing in Glamsterdam's Core EIPs?
• ePBS Moves Closer to Stable Implementation
• Client Readiness and Remaining Testing Issues
• What Has Changed Since Upgrade Watch #2?
• What Validators, Developers, and Infrastructure Teams Should Do
• Timeline and What to Watch Next

TL;DR

• Glamsterdam Devnet 7 is expected to be the final dedicated devnet, followed by a mild specification freeze.
• Devnet 6 is running at approximately 80% participation, with a Nethermind storage-read disagreement under investigation.
• EIP-7928 will receive an additional Block Access List change in Devnet 7, rather than deferring it to another devnet.
• ePBS development continues, with 3-second attestation, 6-second payload, and 9-second PTC deadlines established for Devnet 7 testing.
• A public Gloas application-testing devnet is targeted for early August 2026, particularly to help ecosystem applications test ePBS-related changes.

Glamsterdam Devnet 7 Becomes the Final Testing Milestone

The most significant development for Glamsterdam is the decision to treat Devnet 7 as the final dedicated devnet for the upgrade. Once it 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. Changes such as modifying gas-cost parameters for EIP-8038 or EIP-2780 could still be considered if benchmark data justifies them. However, larger structural modifications would face a much higher threshold after Devnet 7 begins operating.

The current launch target is the week of July 14, 2026. This represents a slight shift from the earlier July 9 target discussed during ACDT #86, reflecting the need to incorporate additional specification and testing changes before launch.

Devnet 6, meanwhile, has served as an important interoperability environment. According to the latest ACDC update, it is operating at roughly 80% participation. Developers are investigating a Nethermind disagreement involving storage reads during reverts, while earlier testing also exposed issues involving Besu, Prysm, Nimbus, Teku, and Erigon.

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.

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.

What Is Changing in Glamsterdam's Core EIPs?

Several Glamsterdam EIPs remain central to Devnet 7 testing, with the latest calls focusing primarily on specification refinement rather than adding entirely new features.

EIP-7928: Block-Level Access Lists

EIP-7928 remains one of Glamsterdam's most consequential execution-layer proposals. It introduces Block Access Lists, allowing the protocol to expose information about the state locations accessed during block execution.

The latest ACDC decision confirmed that an additional change proposed for EIP-7928 will be included directly in Devnet 7 rather than deferred to a hypothetical Devnet 8.

This matters because Block Access Lists can help execution clients prepare state data earlier and potentially improve parallel execution, state prefetching, and block processing efficiency.

The updated Execution Layer test release incorporating this change was assigned as an immediate action item.

EIP-8038: State Access Gas Repricing

EIP-8038 adjusts gas costs associated with state access to better reflect Ethereum's actual computational and storage costs.

A remaining specification issue concerns 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 repricing numbers are considered sufficiently stable for Devnet 7, although final confirmation remains dependent on the complete benchmark suite.

This is particularly relevant 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-2780 and EIP-8037: Intrinsic Gas Changes

Developers have also been refining intrinsic gas behavior involving EIP-2780 and EIP-8037.

A newer pull request covering EIP-2780's intrinsic gas calculations superseded earlier proposals, with execution client teams asked to review the technical discussion and ensure consistent implementation.

The broader objective is to make Ethereum's gas schedule better reflect resource consumption while avoiding unnecessary complexity or client disagreement.

EIP-8282: Builder Deposit and Exit Contracts

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.

The EIP language also requires an update to accurately reflect the use of CREATE2 for contract deployment.

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.

ePBS Moves Closer to Stable Implementation

Enshrined Proposer-Builder Separation, or ePBS, remains one of Glamsterdam's defining features.

The proposal moves proposer-builder separation into the Ethereum protocol itself, reducing reliance on external mechanisms for coordinating block proposers and builders. Recent discussions have focused heavily on deadlines, builder behavior, APIs, and circuit breakers.

These parameters establish when different components of the ePBS workflow must be delivered during a slot.

Another important simplification concerns 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.

At the same time, Beacon API PR #625 remains an important ecosystem coordination point. The proposal introduces a ProduceBlock v4 POST endpoint with per-builder authentication and configuration capabilities.

Feedback is urgently needed from:

• Staking pools
• Block builders
• DVT providers
• Validator client tooling teams

This is a practical readiness issue rather than a purely theoretical specification discussion. API design decisions can directly affect how external infrastructure interacts with validators and builders once ePBS moves closer to deployment.

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.

A public, Mekong-style Gloas application-testing devnet is targeted for early August 2026. This environment is expected to give staking pools, builders, DVT providers, and other ecosystem participants a more accessible opportunity to test ePBS integration.

Client Readiness and Remaining Testing Issues

Devnet 6 has exposed several implementation and interoperability problems that client teams are working through ahead of Devnet 7.

One issue involved Besu and Prysm. Prysm was sending multiple new payloads without a corresponding Forkchoice Updated call, which caused state inconsistency in Besu. Prysm planned to revert its behavior, while a related Besu fix was also expected to be reverted and reconsidered if problems continued.

Nimbus encountered a separate fork-choice issue. A known fix was identified, although affected Nimbus nodes had been self-building blocks rather than relying on a remote builder.

The latest ACDC update also identified a Nethermind disagreement involving storage reads on revert, which remains under investigation.

These issues do not necessarily indicate fundamental flaws in Glamsterdam. Multi-client interoperability testing is specifically designed to expose differences in how independently developed clients interpret and implement the same protocol specifications.

The important readiness signal is whether disagreements are identified, reproducible, resolved, and covered by tests before the upgrade advances.

For Devnet 7, developers are also waiting on updated execution specifications and consensus-layer releases incorporating the latest breaking changes. The intention is to reach a sufficiently stable baseline that Devnet 7 can operate as the final major development environment before the upgrade advances toward broader testing.

What Has Changed Since Upgrade Watch #2?

The previous Upgrade Watch focused on Hegota's early development and the growing role of FOCIL. This edition returns attention to Glamsterdam because the upgrade has reached a materially different stage.

The biggest changes are:

1. Devnet 7 is now positioned as the final Glamsterdam devnet. A mild specification freeze is expected after launch.
2. The launch timeline has shifted. Earlier discussions targeted July 9, while the latest ACDC update places Devnet 7 in the week of July 14.
3. EIP-7928 received another important change. The Block Access List modification will be included directly in Devnet 7.
4. Devnet 6 reached approximately 80% participation. However, a Nethermind storage-read disagreement remains under investigation.
5. ePBS implementation has progressed. Slot deadlines are converging around the 3-second, 6-second, and 9-second structure, while circuit-breaker implementations are advancing across clients.
6. A public Gloas application-testing devnet is now targeted for early August. This will broaden testing beyond core client teams and give ecosystem infrastructure providers a dedicated environment for integration work.

What Validators, Developers, and Infrastructure Teams Should Do

Different stakeholder groups face different levels of immediate preparation.

Validators and Node Operators

No mainnet client upgrade is required yet, but operators should monitor client releases closely as Devnet 7 stabilizes. Validators using builder infrastructure should pay particular attention to ePBS deadlines, builder fallback behavior, and upcoming API changes.

Readiness checklist:

• Monitor Devnet 7 client releases.
• Review ePBS changes affecting proposer and builder workflows.
• Track client-specific circuit-breaker implementations.
• Prepare for future testnet participation once fork dates are announced.

Staking Pools, Builders, and DVT Providers

This group has the most immediate opportunity to contribute.

Beacon API PR #625 requires feedback from staking pools, builders, DVT providers, and validator tooling teams. Organizations that depend on builder authentication or custom ProduceBlock workflows should evaluate the proposal before interfaces become harder to change.

Readiness checklist:

• Review ProduceBlock v4 API changes.
• Assess per-builder authentication requirements.
• Prepare for the public Gloas testing environment in early August.
• Test builder failure and fallback scenarios.

Smart Contract Developers and Enterprises

Developers should monitor gas repricing proposals, particularly EIP-8038 and EIP-2780. Storage-heavy contracts or applications with tightly optimized gas assumptions may experience changes in transaction economics.

Readiness checklist:

• Benchmark storage-intensive contract operations against the latest gas schedule.
• Identify workflows sensitive to state-access repricing.
• Monitor final benchmark results for EIP-8038 and EIP-2780.
• Test critical applications once public testnet environments become available.

RPC Providers and Infrastructure Teams

Block Access Lists and ePBS introduce changes that may affect data availability, block processing, APIs, monitoring, and builder integration.

Readiness checklist:

• Review EIP-7928 implementation changes.
• Monitor Engine API and Beacon API updates.
• Track the upcoming SSZ Engine API work.
• Prepare observability systems for new ePBS timing stages.

Timeline and What to Watch Next

Glamsterdam's immediate roadmap now revolves around Devnet 7 and the transition toward specification stability.

The next major signal will be whether Devnet 7 launches successfully with the latest Execution Layer and Consensus Layer changes and whether client teams can maintain stable participation without major specification disagreements.

The full benchmark suite for EIP-8038 and EIP-2780 will also be important. While current repricing values are considered stable enough for Devnet 7, developers have left room for parameter adjustments based on additional evidence.

For enterprises, validators, developers, builders, and infrastructure providers, the appropriate approach is now active monitoring and early testing. Glamsterdam is not yet at mainnet readiness, but the window for major structural changes is narrowing.

If Devnet 7 succeeds and the mild specification freeze holds, Ethereum's focus can increasingly move toward public testnets, broader ecosystem integration, and final operational preparation for one of the network's most consequential upgrades.

If you find any issues in this article or notice missing information, please feel free to reach out at team@etherworld.co for clarifications or updates.

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

Related Articles

1. Upgrade Watch #1: Glamsterdam Devnet 6 Live
2. Upgrade Watch #2: Hegota and FOCIL Take Shape
3. Ethereum Glamsterdam Upgrade
4. Ethereum All Core Developers Execution Updates
5. Ethereum All Core Developers Consensus Updates

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