Why might Glamsterdam be one of the most important upgrades after the Ethereum Merge?

Written by: KarenZ, Foresight News

The Glamsterdam upgrade of Ethereum can easily be misinterpreted as yet another purely technical iteration aimed at increasing throughput. A more accurate description would be: it reorganizes elements such as Ethereum's block production process, validation process, and resource pricing method, laying the groundwork for higher gas limits, larger blob capacity, and future parallel execution.

As of June 23, 2026, ethereum.org marks 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 Fusaka in December 2025 and before Hegotá, clearly listing two main features: in-protocol proposer-builder separation, or ePBS, and block-level access lists, or BAL.

Who proposes, who builds: ePBS writes the block production division of labor into the protocol

Today's Ethereum block production resembles a tightly scheduled shift handover: someone is responsible for proposing blocks, someone else is responsible for constructing transaction content, and external infrastructure such as MEV-Boost and third-party relays relies on these processes.

This system has been running for many years, but it places some of the trust relations outside of the protocol and requires validators to handle consensus, execution, data availability, and other tasks simultaneously within a very short time window.

One of the key changes in Glamsterdam is EIP-7732, namely ePBS (Enshrined Proposer-Builder Separation), which writes the division of labor between proposers and builders into the protocol.

In simple terms, proposers are responsible for selecting consensus blocks, while builders prepare the transaction content contained within. Builders cannot merely make verbal commitments; they must first submit a "commitment" within the protocol: specifying which execution block they will deliver and how much they are willing to pay the proposer; thereafter, the Payload Timeliness Committee (PTC) will check whether it meets the delivery time.

The significance of this change lies not only in reducing reliance on third-party relays but also in buying more time for block propagation and verification.

Currently, validators need to handle consensus and execution simultaneously within a very short critical window; ePBS separates these two tasks, allowing execution loads to be revealed and verified later on. According to the design of EIP-7732, the propagation window for execution loads, which is the available time for data to propagate across the network and be received by nodes, can be extended from about 2 seconds to approximately 9 seconds. With the extended window, Ethereum becomes less vulnerable to increased drop or reorganization risks when enhancing block capacity, as nodes have more time to download, verify, and vote.

This change may not be directly perceived by ordinary users, but it is crucial for Ethereum's scalability. A longer propagation and verification window means the network can handle larger loads more securely. According to a June 16, 2026 report by CoinDesk, quoting Ethereum Foundation DevOps engineer Parithosh Jayanthi, Glamsterdam could be one of the largest forks since the Merge, fundamentally altering many assumptions about Ethereum and preparing for larger-scale expansions in the future.

BAL and repricing: scaling can't just push the accelerator, but also manage the database

Another core change in Glamsterdam is EIP-7928, Block-Level Access Lists, which establishes a record of "access logs" for each block: which accounts and storage locations the block executed, and what the states turned into after execution, all must be recorded.

This way, nodes no longer process blocks blindly like unboxing a mystery box; they can know earlier what data needs to be read and what computations can be advanced in parallel.

The previous EIP-2930 had already introduced transaction-level access lists, but they were optional and had limited actual usage. EIP-7928 changes this by elevating access lists to the block level: it leaves a "fingerprint" (hash record) of this list in the block header, while the execution load stores the complete list. Nodes will verify during block execution whether the access records listed in the list truly align with the block's execution process; if they don't match, the block is considered invalid.

Why is this important? Today, when executing transactions on Ethereum, many data accesses are only known when that step is actually executed. Nodes do not know whether a batch of transactions will simultaneously read from or write to the same account or storage slot, making it difficult to securely process them in parallel. BAL effectively makes the access trajectory during block execution explicitly visible, enabling clients to perform parallel disk reads, parallel transaction validations, and parallel state root calculations; it can also update states without re-executing incomplete transactions in certain scenarios. It doesn't directly reduce user gas fees but opens up parallelization space for client engineering.

However, the scaling logic of Glamsterdam doesn't only consist of "widening the road." It also aims to curb the long-term expansion of the Ethereum database. EIP-8037 increases the cost of state creation and introduces a cost per state byte (CPSB). States can be understood as the database content that Ethereum must retain in the long term, such as new accounts, new contracts, and new storage slots. Once a transaction is executed, it ends, but the state remains in the ledgers that all nodes must maintain; if the state grows too quickly, running nodes will become increasingly expensive, gradually squeezing decentralization.

The background numbers provided by EIP-8037 are quite striking: as of January 2026, a dedicated Geth node database for state is approximately 390 GiB; after the mainnet gas limit increased from 30 million to 60 million, the daily new state grew from about 105 MiB to about 326 MiB, equivalent to an annual increase of approximately 116 GiB. If projected proportionally under a 200 million gas limit, the annual state growth could reach approximately 387 GiB and surpass the 650 GiB performance degradation threshold in less than a year.

Therefore, what EIP-8037 aims to do is to separate the pricing of "temporary computations" from the "permanent database occupancy." Creating new states will be more expensive because it doesn't just impose one-time computing costs on the network, but rather long-term storage burdens.

Vitalik Buterin also mentioned when explaining the scaling route of Glamsterdam that Glamsterdam will separate the cost of state creation from execution and calldata costs: the goal is to allow execution capacity to expand more while preventing the state size from growing at the same speed.

In summary, BAL allows nodes to process blocks more easily in parallel, addressing the "run faster" aspect; state creation repricing makes long-term database-occupying operations incur higher costs, tackling the issue of "not making the ledger overly bloated." The scaling of Glamsterdam is not simply about raising the gas limit but is asking a more pragmatic question: can Ethereum handle more transactions while preventing uncontrolled pressure on block propagation, transaction validation, and state storage?

Glamsterdam EIP list takes shape: which are confirmed, which are still awaiting?

As of June 23, 2026, according to tracking content about Ethereum upgrades on Forkcast, Ethereum developers are currently conducting devnets environment testing for the Glamsterdam upgrade, with a planned launch on Sepolia on August 3, and on the mainnet on September 16 (specific launch times may change).

The current plan includes 10 EIPs in the Glamsterdam list:

• EIP-7708 (ETH transfers will also trigger logs, facilitating indexing and tracking of native ETH transfers)
• EIP-7732 (ePBS, writing the division of labor between proposers and builders into the protocol to reduce reliance on external relays)
• EIP-7778 (cancellation of block gas accounting related to gas refunds, making block gas calculations simpler)
• EIP-7843 (new SLOTNUM opcode, enabling contracts to read the current slot number)
• EIP-7928 (block-level access lists BAL, recording accounts and storage locations accessed during block execution, paving the way for parallel validation)
• EIP-7954 (increasing the maximum contract size limit, allowing for larger contract bytecode)
• EIP-7976 (increasing calldata floor cost, adjusting the minimum cost of calldata)
• EIP-7981 (increasing access list costs, recalibrating the gas pricing of access lists)
• EIP-8024 (backward-compatible SWAPN, DUPN, EXCHANGE opcodes, enhancing EVM stack operation capabilities)
• EIP-8037 (increasing state creation gas costs, controlling the rapid expansion of the state database)

These EIPs can be roughly divided into several categories: the first category focuses on restructuring block production and verification processes, with EIP-7732 and EIP-7928 as the core; 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, comprising EIP-7708, EIP-7843, EIP-7954, and EIP-8024.

In other words, Glamsterdam does not only modify a single functional point but upgrades block production division of labor, parallel validation, gas pricing, and EVM usability simultaneously.

Additionally, there is a group of EIPs still on the "consider for inclusion" 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, may be removed from Glamsterdam)
• EIP-7975 (eth/70, partial block receipt list)
• EIP-7997 (deterministic factory contracts)
• EIP-8038 (state access gas cost updates)
• EIP-8045 (excluding 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 use consolidation queue)
• EIP-8136 (cell-level deltas for data column broadcasts)
• 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)

Furthermore, Forkcast currently lists EIP-8254 (limiting the number of deposit requests in each execution layer block to 8192) as "suggested for inclusion."

From the perspective of stakers, EIP-8061 and EIP-8080, which are being considered for inclusion, are particularly noteworthy. For stakers, this means that exit liquidity could improve. Figment stated in an article on May 5, 2026, that institutional stakers should focus on ePBS, EIP-8061, and EIP-8080, estimating that under a staking scale of about 38.9 million ETH as of April 2026, EIP-8061 could increase the exit churn limit from 256 ETH/epoch to approximately 1187 ETH/epoch, while EIP-8080 would enable regular exits to utilize the spare capacity of the merge queue. Figment also cautioned that all figures before the mainnet launch should be considered speculative.

Source: Figment

The protocol is upgrading, and the foundation members are also changing

The technical preparation for Glamsterdam coincided almost simultaneously with personnel adjustments within the Ethereum Foundation's protocol cluster. On May 11, 2026, the Ethereum Foundation indicated that Glamsterdam had achieved several milestones: a 200 million gas limit floor had been established as a credible post-Glamsterdam target, ePBS was operating stably in a multi-client Glamsterdam devnet, and EIP-8037 was 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 left the Ethereum Foundation, while Alex Stokes is on leave.

The Foundation described the roles of the three new coordinators: Will Corcoran has cross-team coordination experience; Kev Wedderburn leads the zkEVM team; Fredrik leads the Protocol Security and Trillion Dollar Security projects.

This wave of changes did not remain confined to the protocol team. On June 18, 2026, Hsiao-Wei Wang announced that after a leave of absence, they decided to resign from their 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 EO were believers in CROPS (Anti-censorship and Anti-capture, Open-source, Privacy, Security) whose issues lie not in strategy but in management, suggesting that this wave of talent outflow is bearish for Ethereum. On the contrary, Miden co-founder Azeem interpreted it differently, suggesting that EF's difficulty in self-reform could lead to the establishment of a new organization more capable of executing Ethereum's roadmap, benefiting the ecosystem in the long run.

Internal insiders at the Ethereum Foundation have a perspective on establishing boundaries. Ethereum Foundation's interim co-executive director Bastian Aue (Aerugo) responded that the reasons for the departures of Foundation members include strategic differences, job fit, normal organizational changes, or personal choices, and that EF would not discuss personal personnel issues on social media but stated that outgoing members should have a dignified exit.

The Ethereum Foundation subsequently provided a clearer organizational narrative through an official Twitter thread: Realizing Ethereum's potential requires a coalition of multiple organizations, and several organizations have already enhanced ecological resilience and capabilities together over the past year. Examples listed by EF include: ethlabs announced on June 23 (a non-profit R&D laboratory focusing on the next phase of Ethereum and ETH adoption), Eth Apps Guild launched in April 2026 (targeting genuine adoption of Ethereum native applications, especially in emerging markets), the Ethereum Economic Zone launched in 2026 (aiming to reduce ecological fragmentation by synchronizing composability and zero-knowledge real-time proofs), and Argot established in 2025 (a self-governing collective of engineers and researchers maintaining Solidity and open-source compiler tools).

This official thread makes the recent changes in the Ethereum Foundation easier to understand: the Foundation is not merely pushing people and projects out, nor abandoning central coordination, but rather may be sharing the Ethereum roadmap among more organizations to collectively bear.

Conclusion

Therefore, Glamsterdam should not be seen merely as a set of EIPs. It represents an engineering reorganization by Ethereum before achieving higher throughput: who builds blocks, who proposes, who validates, which data must be retained long-term, and which resources should be more costly, all have been brought back to the table.

The key terms of the technical route are ePBS, BAL, and the beginning of multi-dimensional gas; the key terms of the organizational route are more pragmatic: whether the Ethereum Foundation can maintain its coordination strength, and whether new organizations outside the Foundation can turn this coordination strength into sustained delivery.

References:

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