Stay connected with KayaToday—follow us on Instagram and Facebook for the latest news and reviews delivered straight to you.
Developers are in the final stretch. No launch date yet, but the technical groundwork being laid right now could reshape how Ethereum processes transactions, prices its fees, and scales for the next decade.
Ethereum has been through more transformations than any other major blockchain. The shift from proof-of-work to proof-of-stake in September 2022 — an event the community called The Merge — was the most consequential of them, a years-in-the-making overhaul that changed the network’s fundamental consensus mechanism without breaking it. Since then, each successive upgrade has chipped away at Ethereum’s remaining limitations, gradually expanding what the network can handle and how efficiently it handles it.
Glamsterdam is the next chapter. And by the accounts of the developers building it, it may be the most ambitious one since The Merge itself.
As of this week, Ethereum’s core development team has entered the final stages of testing for the Glamsterdam upgrade — running a developer network, known as a devnet, that contains the full set of Ethereum Improvement Proposals targeted for inclusion. The devnet is the last controlled environment before code gets hardened, sent to public testnets, and eventually activated on the mainnet. No official launch date has been confirmed, but the current trajectory points toward a second-half 2026 deployment.
For anyone holding ETH, building on Ethereum, or simply watching where the smart contract platform space is heading, understanding what Glamsterdam actually does — and why it matters — is worth the time.
Why This Upgrade Carries More Weight Than Usual
Ethereum upgrades have become almost routine in their cadence. The network hard forks on a roughly annual schedule, incorporating incremental improvements through the EIP process. Most upgrades are significant within their technical scope but don’t fundamentally alter the user experience or the network’s architecture in ways that are immediately visible to people outside the developer community.
Glamsterdam is different in scope. Jayanthi described it as potentially the largest fork Ethereum has undergone since The Merge — a characterization that sets expectations considerably above the typical upgrade cycle. The difference lies in what the changes affect: not just incremental improvements to existing mechanisms, but foundational restructuring of how blocks are built, how transactions are priced, and how the network’s execution layer can be optimized for future scaling.
Three areas of change are central to understanding what Glamsterdam delivers. Each addresses a different layer of Ethereum’s architecture, and together they form a coherent vision of where the network is trying to go.
Separating Who Builds Blocks From Who Proposes Them
The most architecturally significant change in Glamsterdam is the implementation of enshrined Proposer-Builder Separation, or ePBS, through EIP-7732.
To understand what this does and why it matters, a brief primer on how Ethereum currently processes transactions is helpful.
When transactions are submitted to the Ethereum network, they don’t go directly from user to block in a clean, ordered sequence. They enter a competitive environment where validators — the participants who secure the network by staking ETH — have the ability to choose which transactions to include in a block and in what order. This ordering discretion has significant financial implications, because the sequence of transactions in a block can affect prices across decentralized exchanges and protocols. The value that can be extracted through strategic transaction ordering is called Maximal Extractable Value, or MEV.
In practice, most validators don’t maximize MEV themselves. Instead, a separate market has evolved where specialized actors called block builders compete to construct the most profitable block, which validators then simply propose to the network in exchange for a share of the value. This arrangement — called proposer-builder separation — has worked reasonably well, but it currently operates largely outside the Ethereum protocol itself, relying on a middleware layer called MEV-Boost that exists off-chain.
EIP-7732 moves this entire mechanism into the protocol. Enshrined PBS means the separation between block builders and block proposers becomes a native feature of Ethereum rather than an external add-on. The consequences are meaningful: the process becomes more transparent, the rules become uniform across all participants rather than dependent on voluntary adoption of external software, and the risks of manipulation or centralization in the block-building market are reduced through protocol-level enforcement rather than market conventions.
For most users, the day-to-day experience of this change will be subtle. But for the integrity of Ethereum’s transaction ordering, the fairness of DeFi markets built on the network, and the long-term decentralization of the validator set, ePBS is a significant structural improvement.
Teaching the Network to Prepare Before It Executes
The second major change in Glamsterdam is Block-level Access Lists, introduced through EIP-7928. This one is less headline-grabbing than ePBS but potentially more immediately impactful for the network’s throughput capacity.
Here’s the problem it solves. When a block of transactions is being executed on Ethereum, the nodes processing that block need to retrieve data from the network’s state — the accumulated record of account balances, smart contract code, and stored variables that represents everything that has happened on Ethereum. Currently, much of this data retrieval happens as transactions are being executed, which means nodes are doing two things simultaneously: running computation and fetching data.
EIP-7928 changes this by allowing a block to declare in advance which data and smart contracts will be needed during its execution. This gives nodes the ability to pre-fetch the required information before execution begins, rather than retrieving it on-demand during the computation process. The result is a meaningfully more efficient execution pipeline — nodes can parallelize the data-fetching and computational workloads rather than handling them sequentially.
For a network that is constantly pushing against the boundaries of how much computation it can handle within each block, this kind of efficiency improvement compounds over time. As Ethereum’s DeFi ecosystem grows, as the number of transactions per block increases, and as smart contracts become more complex, the ability to process those transactions more efficiently becomes increasingly valuable. EIP-7928 is infrastructure work — it doesn’t add visible features, but it makes everything that runs on Ethereum run better.
The Change That Users Will Actually Feel
The third major component of Glamsterdam is perhaps the most directly consequential for everyday users: a comprehensive repricing of gas fees across different types of network activity.
Gas is the unit that measures computational work on Ethereum. Every action — sending ETH, interacting with a smart contract, storing data — consumes a certain amount of gas, and users pay for that gas at a price that fluctuates with network demand. The specific gas costs assigned to different operations were established years ago and reflect assumptions about computational resource consumption that have become increasingly misaligned with reality as the network has evolved.
Glamsterdam’s gas repricing effort recalibrates these costs to more accurately reflect the actual resource demands of different operations. The practical implications run in both directions.
Some computational operations that are currently expensive may become cheaper. Complex smart contract interactions that consume significant computational cycles without proportionally straining other network resources could see their gas costs reduced, making certain types of DeFi activity and smart contract execution more affordable.
Conversely, operations that consume network storage — interactions with Ethereum’s state — are likely to become more expensive. State growth is one of Ethereum’s most significant long-term scaling challenges. Every piece of data permanently written to Ethereum’s state must be maintained by every full node on the network indefinitely, which creates ongoing costs that grow with adoption. Pricing state access more accurately encourages developers to design more efficient contracts and discourages unnecessary state bloat.
There’s a second rationale for the repricing that matters for Ethereum’s longer-term architecture. The gas structure being implemented in Glamsterdam is designed with zero-knowledge proof technology in mind. ZK proofs — cryptographic methods that allow one party to prove they performed a computation correctly without revealing all the data involved — are increasingly central to Ethereum’s scaling roadmap, particularly through ZK rollups that batch large numbers of transactions into compact proofs that can be verified cheaply on mainnet. For ZK proofs to work efficiently, the operations they’re proving need to have gas costs that align with the complexity of generating those proofs. The repricing in Glamsterdam moves Ethereum’s cost structure toward that alignment, preparing the ground for more effective ZK-based scaling in future upgrades.
Jayanthi acknowledged that the gas repricing component requires careful communication with the developer and user community. Changes to gas costs affect how existing applications are priced, how developers estimate costs for their contracts, and in some cases how economic models built on specific cost assumptions need to be adjusted. The Ethereum Foundation’s current focus includes active education work around these changes alongside the technical testing work on the devnet.
