Ethereum’s planned Glamsterdam upgrade has moved toward a fourth-quarter 2026 mainnet target after developers pushed back earlier testnet milestones, giving client teams more time to test a package that would reshape block construction, transaction execution and the cost of retaining data on the network.
Glamsterdam combines the execution-layer upgrade track known as Amsterdam with Gloas, its consensus-layer counterpart. The package centers on enshrined proposer-builder separation, parallel execution tools and revised gas pricing for state storage and read-intensive operations. EthPandaOps has launched Plataberget, a short-term public testnet dedicated to the upgrade, while Sepolia and Hoodi deployments are now expected in September.
An earlier roadmap had placed a Sepolia fork on Aug. 3, a Hoodi fork on Aug. 17 and mainnet activation on Sept. 16. The revised sequence marks the second schedule shift for Glamsterdam after previous planning had aimed for a release in the first half of 2026.
Block building moves further into Ethereum’s protocol
The most consequential proposed component is EIP-7732, which introduces enshrined proposer-builder separation, commonly called ePBS. Ethereum’s current block-building market relies heavily on external infrastructure, including relays that pass builder-created blocks to validators. The proposed change would place the fundamental handoff and payment process inside Ethereum’s protocol rules.
Under the design, block builders would assemble transaction payloads, while validators selected to propose blocks would commit to a bid before receiving and validating the full block contents. The protocol would then govern delivery and payment conditions that are presently coordinated through external systems.
EIP-7732 would also extend the validator timing budget associated with block verification from roughly two seconds to about nine seconds. Developers are targeting additional room for block propagation and execution as Ethereum handles larger data workloads. That timing change would be especially relevant if block builders submit more complex payloads or if future scaling changes increase the amount of data nodes must process.
The proposal does not eliminate every specialized service around block construction, nor does it guarantee particular transaction outcomes for traders. It would, though, reduce the number of essential off-chain coordination steps required for a proposer to receive a block and collect its payment.
Access lists target parallel processing
On Ethereum’s execution layer, EIP-7928 would introduce block-level access lists, or BALs. The mechanism requires transactions within a block to declare the accounts and parts of Ethereum’s state that they expect to read or modify.
That information would allow clients to identify transactions that do not conflict with one another before execution begins. Non-conflicting transactions could then be grouped for parallel processing rather than being handled strictly one after another.
Ethereum execution has traditionally been ordered and sequential because one transaction can alter the state used by the next. BALs seek to preserve deterministic results while exposing cases where independent work can happen simultaneously. The approach could improve execution efficiency without requiring applications to move to a separate execution environment.
The proposal also has implications for node synchronization. A node joining the network ordinarily needs to reproduce historical execution to validate how Ethereum reached its current state. Recorded access outcomes could reduce some of that re-execution burden, according to the design described for EIP-7928, potentially shortening the work needed to synchronize a new node.
Glamsterdam includes a required update to the network transport protocol so Ethereum nodes can exchange the access-list information. The transport requirement has been incorporated across execution-layer client implementations, making it a necessary companion to the block-level access-list design rather than an optional networking improvement.
State growth becomes a direct pricing target
Two proposed changes would alter how Ethereum charges for resource use. One focuses on long-lived state: the data Ethereum nodes must retain and serve over time, including contract storage and account information.
The storage-oriented proposal would add a charge for operations that expand persistent state, such as creating accounts or deploying contracts. Fees would be recalculated according to the space consumed and tracked separately from gas charges tied to computation.
Developers have set an annual state-growth target of 120 GiB for the pricing model. By separating storage costs from execution gas, the proposal aims to make the ongoing burden imposed on node operators more visible in transaction economics. A contract deployment that permanently adds data to Ethereum creates a different cost for the network than a short computation, even when both currently consume gas.
A companion proposal would raise charges for read and query operations. It is intended to bring gas prices for operations that retrieve existing state closer to the load they place on modern hardware. Applications that repeatedly inspect large amounts of on-chain data could face materially different cost assumptions if the changes reach mainnet in their proposed form.
The adjustments would place more pressure on decentralized-finance protocols, analytics-heavy contracts and automated systems to distinguish between computation, data reads and persistent storage. Developers would need to evaluate their contracts against the final gas schedule rather than assume today’s prices will carry over unchanged.
Testnet schedule takes priority over an early launch
At all core developers execution meeting ACDE #241 on July 16, developers discussed Glamsterdam devnet progress alongside voting on headliner proposals for Hegota, the upgrade expected to follow Glamsterdam. Earlier planning had outlined eight devnet iterations, numbered zero through seven, between March 28 and July 8.
The move to Plataberget adds a public proving ground before Sepolia and Hoodi. Public testnets allow client teams, infrastructure operators and application developers to test software under more realistic conditions than private development networks, including block propagation, validator behavior and cross-client compatibility.
A fourth-quarter release target leaves the final mainnet date open. That is a more cautious position than the previously published September activation goal, particularly for an upgrade whose major components touch both Ethereum’s consensus process and its execution engine.
The September testnet forks will offer the clearest near-term evidence of whether ePBS timing, access-list exchange and revised execution behavior operate consistently across Ethereum’s clients. Results from those deployments are likely to determine whether the fourth-quarter target remains viable or requires further adjustment.
Preparing for Glamsterdam’s changes to Ethereum? Deepen your strategy with our concise guide, master Ethereum fundamentals first.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
