Ethereum’s Glamsterdam upgrade is shaping up as the most extensive protocol overhaul since The Merge, according to the source article. The name combines two tracks: “Amsterdam” for the execution-layer side, named after the host city of a past Devconnect, and “Gloas” for the consensus-layer side, named after a star.
Following the earlier Fusaka upgrade, Glamsterdam is aimed at layer-1 scaling by changing how Ethereum processes transactions and handles its growing database. At a deeper level, it rewires how the network creates and validates blocks.
Three goals sit at the center of Glamsterdam
The package is built around three objectives: faster processing, scaling, and sustainability.
The first is speed through parallelization. Ethereum wants to change how the network records data dependencies so it can safely process large numbers of transactions at the same time instead of moving through them one by one in sequence.
The second is throughput. By splitting heavy work in block creation and validation, the network gets more time to propagate larger amounts of data without slowing down.
The third is sustainability. Glamsterdam would adjust fees so the long-run hardware cost of storing new data is reflected more accurately, clearing room for future gas-limit increases while avoiding hardware degradation.
Headline proposal one: ePBS moves proposer-builder separation into the protocol
On the consensus-layer side, the leading proposal is enshrined proposer-builder separation, or ePBS, under EIP-7732.
As described in the article, Ethereum block production can be thought of in two steps. One party decides which block gets proposed, while another assembles the transactions that go into it. Today, that division of labor is not defined by Ethereum itself. Instead, it relies on off-chain intermediaries known as relays.
That off-chain arrangement creates an extra path during block validation and forces validators to rush transaction dissemination and execution inside a tight 2-second window. The result is a cap on how much data the network can handle.
ePBS is meant to write those coordination rules directly into the protocol. Trusted block delivery and payment mechanics would be built on-chain rather than outsourced to third-party middleware. The article notes that external relays could still be used for more complex features not covered by the protocol.
The design also introduces separate checks for who proposed the block and whether delivery happened on time. In the framework described by the source, that expands the relevant time window from 2 seconds to about 9 seconds, giving Ethereum more room to carry larger amounts of Layer2-oriented data.
Headline proposal two: BALs aim to unlock parallel execution
On the execution-layer side, the main proposal is block access lists, or BALs, under EIP-7928.
The article compares current transaction processing to navigating without knowing in advance which data each transaction will touch. Because the system cannot fully determine ahead of time which accounts or storage slots are involved, it has to process transactions strictly in order. That avoids cases where two transactions try to update the same piece of state at once.
BALs would change that by listing data access in advance. With that information, the network can identify transactions that do not conflict with one another, group them, and process those groups in parallel rather than pushing everything through a single queue.
The source also says access lists could help new nodes sync faster. Instead of replaying all complex historical transactions, a new node could use the final results recorded in the list and catch up more quickly.
To make that possible at the network level, Glamsterdam also includes a transport-protocol upgrade so nodes can share these access lists with each other. According to the article, that transport protocol has already become a mandatory requirement for all execution-layer clients.
Supporting proposals reprice storage-heavy and read-heavy operations
Beyond the two headline items, Glamsterdam includes two repricing proposals that revise the cost of operations which either consume long-term state space or query existing on-chain data.
The first covers actions such as creating new accounts and deploying contracts, which permanently occupy space in the network. The article says the old pricing was not proportional enough to actual storage use. Under the new approach, charges would track how much space is consumed, with the goal of keeping annual network data growth at a safe and predictable 120 GiB so the chain remains runnable on ordinary hardware.
That storage fee would also be accounted for separately rather than being mixed into compute costs. In the source’s description, developers willing to pay more storage fees could still deploy larger and more complex applications without being immediately constrained by the total gas limit.
The second repricing covers operations that query or read data already stored on the network. The article says those opcodes have been underpriced and no longer reflect the real burden of querying a much larger data set. Fees for them would be raised to better match the load profile of modern hardware and reduce the risk of network congestion caused by artificially cheap read-heavy requests.
Mainnet timing is still unsettled
There is still no fixed mainnet date for Glamsterdam.
The article says the latest 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 choose headline proposals for the next upgrade, Hegota.
A schedule widely cited earlier in the industry showed 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.
That schedule now appears likely to have slipped. The source points to EthPandaOps launching a new testnet called Plataberget, described as the first short-lived public testnet built specifically for Glamsterdam. Formal Sepolia and Hoodi deployments are now expected to follow in September, pushing the mainnet target into the fourth quarter of 2026.
According to the article, this is the second date shift for Glamsterdam after an earlier move from the first half of 2026. Core developers have repeatedly stressed that correctness matters more than meeting any specific deadline. Until a formal ACD meeting locks in a block height, the upgrade may not arrive until the fourth quarter or even the end of the year.