Ethereum’s upcoming Glamsterdam upgrade is being treated by core developers as the largest protocol-level rebuild since The Merge, according to Odaily. The name combines two tracks: “Amsterdam” for the execution-layer side, named after the Devconnect host city, and “Gloas” for the consensus-layer side, named after a star.
Following the earlier Fusaka upgrade, Glamsterdam is meant to push L1 scaling by reorganizing how the network handles transactions and manages its expanding database. At a more basic level, it changes how Ethereum creates and verifies blocks.
Three goals shape the upgrade package
The article says Glamsterdam is built around three main targets.
The first is faster processing through parallelization. That means changing how the network records data dependencies so that many transactions can be processed safely at the same time instead of being handled one by one in sequence.
The second is scaling. By splitting up the heavier work involved in block creation and block validation, the network gets more time to propagate larger amounts of data without slowing down.
The third is sustainability. The fee model would be adjusted so the long-term hardware cost of storing new data is reflected more accurately, clearing room for future gas-limit increases while trying to avoid hardware degradation pressures across the network.
Two headline proposals sit at the center
ePBS would move proposer-builder separation into the protocol
The lead consensus-layer proposal is enshrined proposer-builder separation, or ePBS, under EIP-7732.
As described in the article, each Ethereum block is effectively produced in two steps: one party selects which block is proposed, and another assembles the actual transactions inside it. Right now, that split is not defined directly by Ethereum’s protocol. Instead, it depends on off-chain intermediaries known as relays.
Odaily says that off-chain arrangement creates an extra path during block validation and forces validators to rush transaction broadcasting and execution inside a tight 2-second window. In turn, that limits how much data the network can handle.
ePBS is designed to write that division of labor into the protocol itself. Trusted block delivery and payment logic would be built directly into Ethereum, reducing reliance on third-party middleware. The article adds that outside intermediaries could still be used if participants want functions that are not covered by the protocol’s built-in rules.
It also says ePBS would extend the delivery window from about 2 seconds to roughly 9 seconds by separating checks around who proposed the block and whether the block was delivered on time. That longer window is intended to let Ethereum carry more Layer2-oriented data.
BALs would let the network know in advance what data a block will touch
The lead execution-layer proposal is block access lists, or BALs, under EIP-7928.
At present, Ethereum cannot know ahead of execution which data a transaction will use, including which accounts it may touch. Because of that, transactions must be processed strictly in order to avoid conflicts when two of them try to modify the same piece of state.
BALs would change that by introducing an access list at the block level. With that list in hand, the system could determine in advance which transactions do not conflict with one another, group those transactions, and process them in parallel instead of forcing everything into a single queue.
The article points to a second benefit as well. A new node joining the network could sync from the final results recorded in those lists instead of re-executing every historical transaction, which would speed up synchronization. To make that possible in practice, Glamsterdam also includes a transport-protocol upgrade so nodes can actually share these access lists. Odaily says that transport protocol has now become a mandatory requirement for all execution-layer clients.
Supporting proposals reprice storage-heavy and read-heavy actions
Beyond the two headline items, Glamsterdam also bundles two repricing proposals tied to storage and data access.
The first targets actions such as creating new accounts and deploying contracts, which permanently take up space on the network. The article says the old pricing did not track actual storage usage closely enough. Under the new model, fees would be recalculated to better match the amount of space consumed.
The stated goal is to keep Ethereum’s total data growth at a safe and predictable 120 GiB per year, so the network can continue to run on ordinary hardware. This storage cost would also be accounted for separately instead of being mixed into the computational fee for transaction execution. In the article’s framing, developers willing to pay more storage cost could still deploy larger and more complex applications without being blocked outright by the overall gas limit.
The second repricing proposal covers query and read operations on data already stored by the network. Odaily says those opcodes have been underpriced relative to the real cost of reading larger state on modern hardware. The upgrade would raise those fees so they better reflect actual load and make it harder to abuse cheap reads in ways that clog the network.
Mainnet activation remains unscheduled
On timing, Glamsterdam is still in an unsettled phase. The most recent verifiable All Core Developers Execution meeting, ACDE #241, took place on July 16. Its agenda included a progress update on the Glamsterdam Devnet phase and a vote to select headline proposals for the next upgrade, Hegota, according to the article.
A widely cited earlier schedule had shown eight Devnet iterations, numbered 0 through 7, running from March 28, 2026 to July 8, 2026. Under that timeline, the Sepolia testnet fork had been set for Aug. 3, 2026, the Hoodi testnet fork for Aug. 17, 2026, and mainnet activation for Sept. 16, 2026.
The article says that schedule has most likely already moved back. EthPandaOps recently introduced a new testnet called Plataberget, described as the first short-term public testnet designed specifically for Glamsterdam. Formal Sepolia and Hoodi deployments are now expected to slip to September, and the mainnet target has moved with them into the fourth quarter of 2026.
Odaily adds that this is the second date shift for Glamsterdam after an earlier delay from its original first-half 2026 target. Core developers have repeatedly said correctness takes priority over meeting any fixed date, so the mainnet launch will remain open until a formal ACD meeting locks in a specific block height. Based on the article, the upgrade may not arrive until the fourth quarter of 2026 or even toward year-end.