Ethereum’s next major upgrade is beginning to take shape.
According to Ethereum’s official roadmap, Glamsterdam is planned for mainnet activation in the second half of 2026. As of late June, it had entered an advanced stage of devnet testing, with multi-client devnets continuing to test core features such as enshrined proposer-builder separation, block-level access lists, and gas repricing. The exact activation date has not yet been finalized.
Much of the discussion across major social platforms has focused on the headline claim that Ethereum mainnet could eventually push toward 10,000 transactions per second after the upgrade. But Glamsterdam is about more than throughput. It introduces major changes to Ethereum’s block-production pipeline and execution architecture. Because of the depth and scope of these changes, many developers have described it as the largest Ethereum upgrade since the Merge.
So what exactly does Glamsterdam change?
The name combines Gloas, the consensus-layer upgrade, with Amsterdam, the execution-layer upgrade. Together, they are intended to address several of Ethereum’s most persistent bottlenecks.
What could this mean for Ethereum—and for everyday on-chain users?
1. Why Is Glamsterdam Being Called the Largest Upgrade Since the Merge?
If Dencun and Fusaka were primarily focused on expanding data availability for Layer 2 networks through blobs, Glamsterdam shifts more attention back to Layer 1 and introduces a broad overhaul of L1 performance and architecture.
In many ways, it reflects Ethereum’s renewed protocol-level focus on strengthening L1: allowing the network to process more transactions without simultaneously increasing node operating costs or centralization risks.
For everyday users, Ethereum upgrades are often reduced to two questions: will gas become cheaper, and will throughput increase?
But Glamsterdam is difficult to summarize as either a simple fee-reduction upgrade or a conventional scaling upgrade.
It affects several core components of Ethereum’s architecture, including who builds blocks, how transactions are executed, how nodes access and synchronize state, and how different on-chain operations are priced.
In other words, it aims to redesign the way Ethereum produces and processes blocks.
Based on the technical details disclosed so far, the most important changes are concentrated in three areas:
Enshrined proposer-builder separation, or ePBS: redesigning the relationship between block proposers and builders while reducing reliance on external relays.
Block-Level Access Lists, or BALs: giving transaction execution a clearer map of state access in advance, laying the groundwork for more parallelized processing and faster node synchronization.
Gas repricing: introducing a more accurate resource-pricing model to limit unsustainable state growth in a higher-throughput environment.
Enshrined Proposer-Builder Separation
To understand ePBS, it helps to know that Ethereum blocks today are not always assembled by proposers themselves.
Under the current MEV-Boost architecture, most proposers outsource transaction collection, ordering, and MEV extraction to professional block builders. The proposer mainly selects the highest-paying candidate block and submits it to the network.
This division of labor—where the builder assembles the block and the proposer submits it—is known as proposer-builder separation, or PBS.
The problem is that the current mechanism is not fully integrated into Ethereum’s base protocol.
Proposers and builders still rely on off-protocol third-party software and MEV-Boost relays to handle block bids, payload delivery, and payments.
These relays must ensure that builders eventually reveal the full block while also preventing proposers from viewing the block contents in advance and using them without compensating the builder.
As a result, relays occupy a centralized and potentially fragile intermediary position.
EIP-7732’s ePBS is designed to address this problem by bringing the proposer-builder relationship directly into Ethereum’s consensus protocol.
Instead of relying on third-party relays, builders become protocol-native actors. They first submit block commitments and bids, the protocol locks the corresponding payment, and a dedicated Payload Timeliness Committee determines whether the builder revealed the execution payload on time.
This separates consensus-layer block processing from execution-payload processing, extending the propagation and processing window for execution payloads from approximately two seconds to around nine seconds.
These additional seconds may not sound significant, but they matter for Ethereum scaling.
They give nodes more time to receive and process larger blocks and more blob data, creating room for further increases in the gas limit.
Block-Level Access Lists
Another major execution-layer proposal in Glamsterdam is EIP-7928, which introduces Block-Level Access Lists.
Today, when an Ethereum node receives a block, the block itself does not directly tell the node which accounts each transaction will read from, which storage slots it will access, or which parts of state it will modify.
These dependencies are usually discovered during execution.
It is similar to entering a large warehouse without a complete inventory map. Workers must discover where each item is stored while carrying out the work itself.
To prevent conflicting updates, much of the work must be performed in a strict sequence.
Block-Level Access Lists are designed to function like a state-access map attached to each block.
They record which addresses and storage slots the block accesses, together with the resulting state changes.
With this information, nodes can identify in advance which transactions access the same data and which do not conflict with one another.
For non-conflicting operations, nodes can prefetch relevant state from disk and parallelize parts of transaction verification and state-root computation, rather than forcing all work into a strictly serial process.
Because BALs also record post-execution state changes, some nodes may be able to use those results when synchronizing or catching up, rather than always re-executing every transaction from scratch.
In this sense, BALs introduce some of the benefits associated with sharded or parallelized execution.
Over time, they could become an important foundation for raising Ethereum mainnet’s current performance ceiling.
Gas Repricing
The third major component is gas repricing, which uses economic incentives to better align gas costs with the actual resources consumed by different on-chain operations.
Ethereum’s current gas schedule does not always reflect the real burden that operations place on nodes.
For example, computationally intensive operations may impose relatively little long-term burden once execution is complete.
By contrast, creating a new account, deploying a smart contract, or writing to a new storage slot creates data that full nodes around the world may need to store permanently.
Historically, fees for these state-creating operations have not always fully reflected the long-term storage burden they introduce. This is commonly described as state growth or state bloat.
If Ethereum raises the gas limit while preserving the existing pricing model, additional block space could quickly accelerate state growth and place greater pressure on node hardware.
EIP-8037, which has been included in the Glamsterdam scope, is intended to overhaul this pricing model.
It separates computation and state accounting, recalculates costs based on the amount of newly created state, and distinguishes conventional computation gas from state-related gas.
It is also intended to limit rapid state growth.
Applications that create large numbers of accounts, deploy redundant contracts, or frequently write new state may face higher costs. Meanwhile, applications that primarily consume computation without continuously expanding state may benefit from a more favorable fee structure.
Glamsterdam’s gas reform should therefore not be understood as making every transaction cheaper.
Its goal is to distinguish between immediate computation and long-term storage, then charge operations in a way that more closely reflects the actual resources they consume.
Taken together, these three components point toward the same broader goal: strengthening Ethereum mainnet’s core infrastructure before significantly increasing capacity.
2. Why Not Simply Make Blocks Bigger?
A common question is straightforward: if Ethereum is slow and expensive, why not simply increase the gas limit and double block capacity?
In theory, raising the amount of gas available per block is the most direct way to increase mainnet throughput.
The higher the gas limit, the more transactions and computation each block can contain.
But the gas limit cannot be increased indefinitely.
If blocks become too large too quickly, they can trigger a chain reaction.
Nodes must receive more data, execute more transactions, and calculate a new state within the same time window.
If processing cannot keep up, lower-specification nodes are more likely to fall behind. Block propagation and validation may also slow down, increasing the risk of forks and network centralization.
At the same time, more transactions can also mean more accounts, contracts, and storage data being written permanently into Ethereum’s database.
This data does not disappear once a transaction has been processed. It continues to accumulate in Ethereum’s state database, accelerating state growth over time.
Sustainable Ethereum scaling must therefore address three problems at once:
First, giving nodes more time to propagate and process larger blocks.
Second, reducing the bottlenecks created by sequential execution.
Third, preventing additional block space from accelerating unsustainable state growth.
This is the core logic behind Glamsterdam.
It does not increase capacity first and leave nodes to absorb the consequences.
Instead, it redesigns how blocks are produced, how transactions are executed, and how network resources are priced.
By improving the underlying processing pipeline, it creates a stronger foundation for higher mainnet capacity.
Among these changes, ePBS gives nodes more time to propagate and validate larger blocks by rearranging the processing flow within each slot.
BALs improve client efficiency by making state-access relationships explicit.
Gas repricing helps limit unsustainable state growth.
During coordinated Glamsterdam testing in April 2026, core developers stress-tested multi-client implementations and proposed 200 million gas as a credible lower-bound estimate for post-upgrade capacity.
That estimate reflects the combined foundation provided by ePBS, BALs, and state gas repricing.
Of course, 200 million gas should be understood as an indication of possible post-upgrade capacity and the direction in which the network could gradually evolve.
It does not mean Ethereum mainnet will immediately move to that gas limit on the day Glamsterdam activates.
What matters is that Ethereum is shifting from cautious, incremental scaling toward preparing for substantially greater mainnet capacity through deeper architectural redesign.
3. How Could Glamsterdam Affect Users and the Ethereum Ecosystem?
For everyday users, the most important question remains whether transaction fees will decrease.
The answer is nuanced.
Fees may fall and become more stable, but not every transaction will immediately become cheaper.
Because ePBS and BALs create the conditions for a higher gas limit, each block should eventually be able to include more transactions.
If demand remains unchanged, an increase in block-space supply should help reduce congestion and lower the likelihood of sudden base-fee spikes.
At the level of individual transactions, however, the effects may vary.
A standard ETH transfer may benefit from broader execution and pricing improvements.
More predictable state-access information may also help wallets improve gas estimation, reducing some cases in which users submit transactions with insufficient gas while still incurring gas costs.
However, operations such as deploying contracts, creating accounts in batches, or writing large amounts of new state may become more expensive under the new state-pricing model.
The more likely outcome is therefore that simple transactions become cheaper, fees become more stable during periods of congestion, and state-intensive applications begin paying prices that more accurately reflect the long-term resources they consume.
Impact on Layer 2 Users
For users who primarily interact with Layer 2 networks, Glamsterdam is also relevant.
ePBS extends the processing window for execution payloads from approximately two seconds to around nine seconds.
This supports not only larger mainnet blocks, but also greater room for processing blob data.
As blob capacity continues to expand, rollups may gain more space to submit transaction data, which could help stabilize Layer 2 data costs over time.
Clearer ETH Activity Records
For wallets, exchanges, and cross-chain bridges, one of the more visible changes could come from EIP-7708.
Today, ERC-20 token transfers usually emit standardized Transfer logs. Some native ETH transfers between smart contracts, however, do not produce equivalent standardized event logs.
Wallets and exchanges often need to rely on internal transaction tracing to identify these ETH movements.
EIP-7708 requires non-zero ETH transfers and operations that burn ETH to generate standardized logs.
This could allow wallets, exchanges, and bridges to identify deposits, withdrawals, and internal ETH movements more reliably.
Users may eventually see more complete ETH activity records in their wallets, while some internal transfers that currently require complex tracing may become easier to recognize directly.
Impact on Node Operators and Stakers
For node operators and stakers, the impact will be more direct.
Glamsterdam changes block processing at both the execution and consensus layers, so nodes and validators will need to upgrade to client versions that support Glamsterdam before mainnet activation.
Ordinary ETH holders will not need to migrate their ETH, upgrade their assets, or perform a token swap.
Over the longer term, Glamsterdam’s real significance lies in how Ethereum attempts to balance scaling with decentralization.
If higher block capacity leads to sharply higher hardware requirements, throughput may improve while the network becomes increasingly dependent on large institutions and professional infrastructure providers.
The combination of ePBS, BALs, and state gas repricing attempts to create a different scaling path.
Instead of simply asking nodes to process more work within the same amount of time, Ethereum is rearranging the block-production process, providing transaction dependency information in advance, and pricing different operations according to the computational and storage burden they impose.
This is the fundamental difference between Glamsterdam and a simple gas-limit increase.
It does not rely on a single EIP to solve Ethereum’s scaling challenges.
Instead, it redesigns three interconnected mechanisms at once: block production, transaction execution, and state growth.
Closing Thoughts
In the long run, Glamsterdam’s most important impact may be its role in helping Ethereum find a new balance between higher performance and strong decentralization.
This reflects a long-standing Ethereum principle.
As high-performance monolithic chains continue to apply pressure, Ethereum is not choosing the simplest path of aggressively increasing hardware requirements.
Instead, it is attempting to preserve its decentralized foundation while strengthening the resilience and efficiency of the underlying protocol.
That is what Glamsterdam’s combination of changes is ultimately designed to achieve.
ePBS restructures the block pipeline.
BALs make transaction dependencies more explicit.
Gas repricing aligns fees more closely with the computational and storage burden different operations impose.
Together, these changes are intended to create substantially greater mainnet capacity while preserving the ability of ordinary participants to run nodes and take part in validation.
From this perspective, future reductions in gas costs, clearer ETH activity records in wallets, and greater room for Layer 2 fees to decline may all trace back, at least in part, to the groundwork laid by Glamsterdam.
Its significance lies not in any single headline metric, but in the deeper architectural foundation it creates for Ethereum’s next stage of scaling.