Why might Glamsterdam be one of the most crucial upgrades post-Ethereum Merge?
Written by: KarenZ, Foresight News
The Ethereum Glamsterdam upgrade is often misinterpreted as just another technical iteration to boost throughput. More accurately, it is about restructuring Ethereum's block production process, validation process, and resource pricing methods to pave the way for higher gas limits, larger blob capacities, and future parallel execution.
As of June 23, 2026, ethereum.org has marked Glamsterdam as an upgrade planned for the second half of 2026. The name Glamsterdam comes from the combination of the execution layer upgrade Amsterdam and the consensus layer upgrade Gloas. The official roadmap places it after the December 2025 Fusaka and before Hegotá, clearly listing two main features: the protocol-level proposer-builder separation, known as ePBS, and the block-level access list, or BAL.
Who proposes, who builds: ePBS formalizes block production roles within the protocol.
Today's Ethereum block production resembles a very tight shift change: someone proposes a block, someone else builds the transaction content, all while relying on MEV-Boost and third-party relays as off-protocol infrastructure.
This system has been running for years, but it places part of the trust relationship outside the protocol, making validators handle consensus, execution, and data availability tasks simultaneously in a short time window.
One of Glamsterdam's biggest changes is EIP-7732, which is ePBS (Enshrined Proposer-Builder Separation), formalizing the division of labor between proposers and builders in the protocol.
In simple terms, the proposer is responsible for selecting consensus blocks, while the builder prepares the transaction content within. Builders can't just verbally commit; they must 'post a bond' in the protocol: clearly stating which execution block they will deliver and how much they are willing to pay the proposer; afterward, the Payload Timeliness Committee (PTC) will check if it delivers on time.
The key to this change isn't just reducing reliance on third-party relays, but also buying time for block propagation and verification.
Today, validators need to handle consensus and execution simultaneously in very short critical windows; ePBS separates these two tasks, allowing the execution load to be revealed and verified later. According to EIP-7732's design, the propagation window for execution load, which is the time available for data to propagate in the network and be received by nodes, can be extended from about 2 seconds to about 9 seconds. With a longer window, Ethereum can handle larger loads more safely while increasing block capacity, making it less likely to increase dropping votes or reorganization risks due to nodes not being able to download, validate, and vote in time.
This may not have a strong immediate perception for ordinary users, but it's crucial for Ethereum's expansion. A longer propagation and validation window means the network can handle larger loads more securely. CoinDesk reported on June 16, 2026, quoting Ethereum Foundation DevOps engineer Parithosh Jayanthi, that Glamsterdam could be one of the largest forks since the Merge, changing many assumptions about Ethereum and preparing for future larger-scale expansions.
BAL and repricing: expansion cannot just step on the gas; it must also manage the database.
Another core change in Glamsterdam is EIP-7928, Block-Level Access Lists.
It can be understood as equipping each block with an 'access record': which accounts and storage locations were touched during the block execution and what the relevant states became afterward will all be recorded. This way, nodes processing blocks will no longer be like opening blind boxes; they can know earlier which data needs to be read and which computations can proceed in parallel.
The previous EIP-2930 had already introduced transaction-level access lists, but it was optional, with limited actual usage. The change in EIP-7928 is that it raises the access list to the block level: leaving a 'fingerprint' (hash record) of this list in the block header, while the execution load stores the full list. When nodes execute the block, they will verify whether the access records written in the list truly match the block execution process; if not, the block is invalid.
Why is this important? Today, when Ethereum executes transactions, much of the data access is only known once it reaches that step. Nodes don't know if a batch of transactions will simultaneously read and write the same account or storage slot, making parallel processing challenging. BAL effectively writes out the access trajectory during block execution, allowing clients to perform parallel disk reads, parallel transaction verifications, and parallel state root calculations, and also update states in certain scenarios without fully replaying transactions. It's not a direct button to lower user fees, but it opens up parallelization space for client engineering.
But Glamsterdam's expansion logic isn't just about 'widening the road'. It also aims to manage the long-term expansion of the Ethereum database. EIP-8037 increases the cost of state creation and introduces a CPSB (Cost Per State Byte) for every state. A state can be understood as the database content that Ethereum must retain long-term, such as new accounts, contracts, and storage slots. Transaction execution ends, but states remain on the ledger that all nodes must maintain; if states grow too quickly, running nodes will become increasingly expensive, slowly squeezing decentralization.
The background numbers provided by EIP-8037 are quite telling: as of January 2026, a dedicated state Geth node database is about 390 GiB; after the mainnet Gas limit was raised from 30 million to 60 million, the daily new state rose from about 105 MiB to about 326 MiB, translating to an annual growth of about 116 GiB. If extrapolated proportionally at a 200 million Gas limit, the annual state growth could reach about 387 GiB and exceed the performance degradation threshold of 650 GiB in less than a year.
Thus, what EIP-8037 aims to do is separate the pricing for 'temporary computation' and 'permanent database occupancy'. Creating new states will be more expensive because it imposes a long-term storage burden on the network rather than just a one-time computation cost.
Vitalik Buterin also mentioned in explaining the Glamsterdam expansion path that Glamsterdam will separate state creation costs from execution and calldata costs: the goal is to allow for more capacity in execution while not letting the state scale grow at the same rate.
Put together, BAL allows nodes to handle blocks more easily in parallel, addressing the issue of 'running faster'; on the other hand, the repricing of state creation imposes higher costs on operations that occupy the database long-term, tackling the problem of 'not letting the ledger get too bloated'. Glamsterdam's expansion isn't merely about raising the Gas limit; it's asking a more realistic question: can Ethereum handle more transactions while avoiding uncontrolled pressure on block propagation, transaction validation, and state storage?
The Glamsterdam EIP list is taking shape: which are confirmed, and which are still waiting?
As of June 23, 2026, based on Forkcast's tracking of Ethereum upgrades, current Ethereum developers are testing the Glamsterdam upgrade in devnets, set to go live on Sepolia on August 3 and on the mainnet on September 16 (specific launch times may vary).
Currently, there are 10 EIPs planned for inclusion in the Glamsterdam list:
EIP-7708 (ETH transfers will also trigger logs for easier indexing and tracking of native ETH transfers)
EIP-7732 (ePBS, formalizing the separation of proposers and builders in the protocol to reduce reliance on off-protocol relays)
EIP-7778 (eliminate Gas refund-related block Gas accounting to simplify block Gas calculations)
EIP-7843 (introducing SLOTNUM opcode to allow contracts to read the current slot number)
EIP-7928 (Block-Level Access Lists, recording accounts and storage locations accessed during block execution to pave the way for parallel verification)
EIP-7954 (increasing the maximum contract size limit to allow larger contract bytecode)
EIP-7976 (raising calldata floor cost, adjusting the minimum cost of calldata)
EIP-7981 (increasing access list costs, recalibrating the Gas pricing for access lists)
EIP-8024 (backward-compatible SWAPN, DUPN, EXCHANGE opcodes to enhance EVM stack operation capabilities)
EIP-8037 (increasing the Gas cost for state creation to curb excessive growth of the state database)
These EIPs can be roughly categorized into several types: the first category focuses on restructuring block production and validation processes, centered around EIP-7732 and EIP-7928; the second category involves resource pricing adjustments, including EIP-7778, EIP-7976, EIP-7981, and EIP-8037; the third category includes changes to EVM and developer experience, including EIP-7708, EIP-7843, EIP-7954, and EIP-8024.
In other words, Glamsterdam is not just about changing one functionality; it's upgrading block production roles, parallel verification, Gas pricing, and EVM usability all at once.
There is also a batch of EIPs still on the 'consideration' list:
EIP-2780 (splitting transaction intrinsic Gas by resources)
EIP-7610 (rollback when creating contracts with non-empty storage accounts)
EIP-7688 (future-compatible consensus layer data structures)
EIP-7904 (Gas cost analysis, potentially to be excluded from Glamsterdam)
EIP-7975 (eth/70, part of block receipt list)
EIP-7997 (deterministic factory contract)
EIP-8038 (updates to state access Gas costs)
EIP-8045 (exclude already penalized validators from continuing to propose blocks)
EIP-8061 (increasing exit and merge churn)
EIP-8070 (eth/72, Sparse Blobpool)
EIP-8080 (allowing exits to utilize the consolidation queue)
EIP-8136 (cell-level deltas for data column broadcasting)
EIP-8159 (eth/71, block access list exchange)
EIP-8246 (removing SELFDESTRUCT burn)
EIP-8282 (Builder Execution Requests, providing dedicated registration and exit requests for ePBS builders)
Additionally, Forkcast currently lists EIP-8254 (limiting the number of deposit requests in each execution layer block to 8192) as 'suggested for inclusion'.
From the staker's perspective, the inclusion of EIP-8061 and EIP-8080 in the list is particularly noteworthy. For stakers, this means that exit liquidity may improve. Figment stated in an article on May 5, 2026, that institutional stakers should pay close attention to ePBS, EIP-8061, and EIP-8080, estimating that with about 38.9 million ETH staked as of April 2026, EIP-8061 could raise the exit churn limit from 256 ETH/epoch to about 1187 ETH/epoch, while EIP-8080 would allow ordinary exits to utilize the spare capacity of the merge queue. Figment also cautioned that all numbers prior to mainnet launch should be considered speculative.
Source: Figment
The protocol is upgrading, and the foundation members are also changing.
The technical preparations for Glamsterdam are occurring almost simultaneously with personnel adjustments within the Ethereum Foundation's protocol cluster. On May 11, 2026, the Ethereum Foundation announced that Glamsterdam reached several milestones: the 200 million Gas limit floor was established as a credible post-Glamsterdam target, ePBS is running stably in the multi-client Glamsterdam devnet, and EIP-8037 has been finalized.
The same article announced a leadership transition in the Protocol cluster: Will Corcoran, Kev Wedderburn, and Fredrik will become the new protocol cluster coordinators. Former coordinators Barnabé Monnot and Tim Beiko have left the Ethereum Foundation, while Alex Stokes is on leave.
The Foundation's description of the roles of three new coordinators is as follows: Will Corcoran has cross-team coordination experience; Kev Wedderburn leads the zkEVM team; Fredrik leads the Protocol Security and Trillion Dollar Security projects.
These changes aren't just limited to the protocol team. On June 18, 2026, Hsiao-Wei Wang announced after a vacation that he decided to resign from his position as co-executive director and board member of the Ethereum Foundation.
Former Ethereum Foundation researcher Dankrad Feist stated on June 19, 2026, that those leaving the EF are CROPS (anti-censorship, anti-capture, open source, privacy, security) believers, with the issue not being strategic but managerial. He noted that this wave of talent outflow might be bearish for Ethereum. Miden co-founder Azeem interpreted it from the opposite direction, believing that the EF struggles to self-change; after the talent outflow, a new organization more capable of executing Ethereum's roadmap might emerge, which could be a net positive for the ecosystem in the long run.
The Ethereum Foundation insiders are setting clearer boundaries. Bastian Aue (Aerugo), the interim co-executive director of the Ethereum Foundation, responded that the reasons for members leaving include strategic differences, role fit, normal organizational changes, or personal choices. The EF won’t discuss personal HR issues on social media, but stated that departing members should have a dignified exit.
The Ethereum Foundation subsequently provided a clearer narrative on their official Twitter thread: realizing Ethereum's potential requires multiple organizations to form alliances, and several organizations have been enhancing ecosystem resilience and capabilities over the past year. Examples listed by the EF include: ethlabs, a nonprofit R&D lab focused on the next phase of Ethereum and ETH adoption announced on June 23; the Eth Apps Guild launched in April 2026, focusing on the real adoption of Ethereum-native applications, especially in emerging markets; the Ethereum Economic Zone, launched in 2026, aims to reduce ecological fragmentation through synchronous composability and zero-knowledge real-time proofs; and Argot, formed in 2025, a collective of engineers and researchers maintaining Solidity and open-source compiler tools.
This official thread makes it easier to understand the recent changes in the Ethereum Foundation: the Foundation isn't simply pushing people and projects out or abandoning central coordination; rather, it may be disassembling the Ethereum roadmap to be jointly undertaken by more organizations.
Summary
Thus, Glamsterdam shouldn't just be seen as a set of EIPs. It's an engineering rearrangement that Ethereum is making before achieving higher throughput: who builds blocks, who proposes, who validates, which data must be stored long-term, and which resources should be more expensive are all being reconsidered.
The technical roadmap's keywords are ePBS, BAL, and the beginning of multi-dimensional Gas; the organizational roadmap's keywords are more realistic: can the Ethereum Foundation maintain coordination, and can new organizations outside the Foundation turn this coordination into continuous delivery.
Reference:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122