Ethereum’s next major network upgrade, known as Glamsterdam, is being aimed at the second half of 2026, though no official mainnet launch date has been set. Developers are working toward a Q4 target, according to an X post cited from SSV Network, but Ethereum has not confirmed when the fork will go live.
What Glamsterdam Includes
Glamsterdam combines two parts of Ethereum’s upgrade process: Gloas for the consensus layer and Amsterdam for the execution layer. The consensus-side changes are meant to update validator coordination, while the execution-side changes focus on how transactions and smart contracts are processed. Together, they make up a single network upgrade.
Testing remains a key checkpoint before any launch date is announced. In May, the Ethereum Foundation said a multi-client devnet had tested the external-builder pipeline across nearly all clients. Developers also aligned around a post-Glamsterdam gas-limit target of 200 million. That figure is a target for after activation, not a current mainnet setting. Before setting a fork date, developers still plan to stabilize a complete devnet, publish compatible clients, complete security reviews and confirm stable public testnets.
Changes to Block Production
One of the central proposals in the upgrade is EIP-7732, which would introduce enshrined proposer-builder separation, or ePBS. Today, many Ethereum proposers depend on external builders to assemble execution payloads, with trusted relays helping pass those payloads to validators. The proposal would move that basic workflow into Ethereum’s consensus rules.
Under the design described in the roadmap, a builder would commit to an execution payload and payment, and the proposer would choose a bid. A Payload Timeliness Committee would then check whether the builder revealed the payload on time and whether the related blob data was available. The change is intended to separate consensus checks from execution checks. Ethereum’s roadmap says that could extend the effective data-sharing window from about two seconds to roughly nine seconds.
The shift would also create new duties for validators, including handling builder commitments, payload checks and timing requirements. Staking pools and node operators may need system updates, along with compatible execution and consensus clients.
Preparing for Parallel Processing
Another scheduled proposal, EIP-7928, would add Block-Level Access Lists, or BALs. These lists would record the accounts and storage locations touched in a block, along with the values left after transactions finish. Ethereum currently discovers many transaction dependencies only during execution, which limits how safely work can be split up.
BALs are intended to help clients identify which transactions are independent, allowing tasks such as database reads, transaction validation and state-root calculations to run in parallel. The lists could also support executionless state updates, letting a syncing node read recorded results instead of replaying every transaction. EIP-8159 would provide the method for clients to exchange those lists.
The source article notes that BALs do not guarantee a fixed increase in transaction speed. Capacity would still depend on client performance, block composition and the gas limit used after activation.
State Growth, Fees and User Impact
Higher throughput could also increase the growth of Ethereum’s permanent state database. According to the Glamsterdam roadmap, unchecked state growth could raise storage costs and make it harder to run nodes at home. Scheduled EIP-8037 is meant to address that by assigning a fixed cost for each new byte of state, with a model targeting average growth of 120 GiB per year at a reference block gas limit of 150 million. A separate reservoir would manage state-creation charges.
A related proposal, EIP-8038, would raise fees for reading and modifying existing state, though the roadmap lists it as considered rather than scheduled. Other scheduled changes include EIP-7954 to raise the maximum contract size and EIP-7708 to create standard logs for non-zero ETH transfers and burns. Two other ideas, EIP-2780 and EIP-7997, remain under consideration.
Existing contracts are expected to continue working after the fork, but application teams may still need to test gas usage and supporting tools such as indexers, tracing systems and fee estimators. Node operators and validators will need to update both execution and consensus clients to stay on the upgraded chain.
For ETH holders, the guidance is straightforward: no token swap, conversion or coin upgrade is expected. Balances should remain accessible after the fork, and the roadmap warns that any request to exchange ETH for a replacement token would be a scam.
Glamsterdam is designed to expand Ethereum’s capacity, change how blocks are coordinated and lay groundwork for more parallel transaction processing while trying to keep node hardware demands manageable. But its final EIP list, testing results, security reviews and launch date are still developing, and the source article notes that any effect on fees, adoption or ETH’s price remains unproven until the upgrade is actually deployed and measured.
Source: Coin Edition