The Glamsterdam Upgrade: What It Is and Why It Matters for Ethereum
av LCX Team ·
Ethereum is preparing for one of its most significant network upgrades yet. Named Glamsterdam, it combines a consensus-layer component (codenamed “Gloas”) and an execution-layer component (codenamed “Amsterdam,” after the city that hosted Devconnect in 2022) into a single coordinated hard fork. In August 2026, the Ethereum Foundation opened Platåberget, the first public testnet built specifically to validate Glamsterdam before it reaches mainnet, a sign that years of research are now entering their final testing phase.
This post breaks down what Glamsterdam actually changes, why those changes matter, and who benefits once it goes live.
Why Ethereum Needs This Upgrade
Ethereum’s mainnet processes transactions largely one at a time, in the order a block builder decides, using a system that leans heavily on external software called MEV-Boost to decide who builds each block. That system works, but it depends on trusted middlemen (relays) sitting outside the core protocol, and it forces validators to make several major decisions inside a single, narrow time window of about 12 seconds per block. As demand for block space grows, especially from Layer 2 rollups that post data back to Ethereum, that narrow window becomes a real bottleneck. Glamsterdam is designed to remove that bottleneck at its root, rather than patch around it.
The Two Headline Changes
1. ePBS: Bringing Block-Building Into the Protocol Itself
The centerpiece of Glamsterdam is EIP-7732, known as enshrined Proposer-Builder Separation, or ePBS.
Today, the job of proposing a block and the job of building its contents (deciding which transactions go in and in what order) are informally split using MEV-Boost relays that sit outside Ethereum’s core rules. It works, but it means validators are trusting third-party software for a function as important as block construction, and everything has to happen inside a tight time budget.
ePBS writes this separation directly into Ethereum’s protocol. Builders become recognized, first-class participants with an on-chain identity and cryptographically signed bids, instead of relying on off-chain relay infrastructure. A new role, the Payload Timeliness Committee, checks that builders deliver their block content on time. Critically, ePBS also stretches the payload delivery window from roughly 2 seconds to about 9 seconds.
Why this matters: that extra breathing room means validators can safely handle larger blocks without the risk of missing their slot, block-building becomes more transparent and harder to centralize around a few trusted relays, and Layer 2 networks gain a credible path to posting more data to Ethereum more cheaply in future upgrades.
2. BALs: Letting Ethereum Process Transactions in Parallel
The second headline change is EIP-7928, Block-Level Access Lists (BALs).
Right now, a validator processes the transactions in a block strictly one after another, because it has no way of knowing in advance which transactions might touch the same piece of data. Even transactions that have nothing to do with each other get processed in sequence, just to be safe.
BALs fix this by attaching a complete map to every block: a list of exactly which accounts and storage slots each transaction will read or write. With that map in hand, a validator’s software can instantly see which transactions are independent of one another and run them at the same time, across multiple CPU cores, instead of one after another. Industry estimates suggest a block that currently takes around 12 seconds to validate sequentially could take roughly 3 seconds when spread across four parallel execution lanes.
Why this matters: parallel execution is what makes it realistic to raise Ethereum’s gas limit, the cap on how much computational work fits in a block from today’s roughly 60 million toward a long-discussed target of 200 million, without asking validators to buy dramatically more powerful hardware just to keep up.
The Supporting Changes That Make It Sustainable
A higher gas limit sounds like an easy win, but it creates a side effect: more transactions per block means Ethereum’s permanent state (the ever-growing record of account balances and contract storage) grows faster too. Left unchecked, a 200 million gas limit could push state growth past 380 GiB per year, which would price ordinary validators out of running a node on consumer-grade hardware.
Glamsterdam addresses this with a set of gas-repricing EIPs, including EIP-8037 and EIP-8038, which separate the cost of permanently storing new data from the cost of temporary computation, and recalibrate the price of reading existing state so it better reflects real hardware costs. A related change also raises the maximum size of a single smart contract, from roughly 24 KiB to 32 KiB, giving developers more room to build complex contracts.
A handful of smaller, practical improvements round out the package: EIP-2780 cuts the base cost of simple ETH transfers by as much as 71%, EIP-7708 makes plain ETH transfers emit event logs the way ERC-20 token transfers already do (which makes them far easier for wallets and exchanges to track automatically), and EIP-7997 introduces a standard, predictable address for deploying certain types of contracts.
Who Actually Benefits, and How
Everyday ETH holders and users benefit indirectly: the upgrade is designed to be invisible to wallets and balances, but it lays the groundwork for higher throughput and, over time, more competitive transaction fees as blob and data capacity expand for rollups.
Developers get cheaper simple transfers, more generous contract size limits, and better on-chain visibility into ETH movements, useful for anyone building wallets, exchanges, or analytics tools.
Stakers and node operators carry the most direct responsibility: they need to upgrade both their consensus-layer and execution-layer client software, and prepare their infrastructure for the new Payload Timeliness Committee duty and for concurrent, multi-core disk access during parallel execution.
Layer 2 rollups stand to benefit from the longer 9-second payload window, which creates room for higher blob capacity in later upgrades, a step toward Ethereum’s long-standing goal of scaling primarily through rollups rather than by simply making the base layer heavier.
Where Things Stand Right Now
Glamsterdam has moved through a long sequence of developer devnets and, as of August 2026, has reached the Platåberget public testnet, the broadest and most realistic testing ground before mainnet. That said, timelines for a change this large tend to shift as testing surfaces edge cases, and reporting through August 2026 has been mixed on the exact mainnet date: some coverage points to a target in the fourth quarter of 2026, while the upgrade has already been pushed back once from an earlier date. The safest way to think about it: Glamsterdam is now in its final public testing stage, with mainnet activation expected later in 2026, but the precise date is still being finalized as testnet results come in.
The Takeaway
Glamsterdam isn’t a single feature, it’s a coordinated overhaul of how Ethereum builds blocks (ePBS), how it processes them (BALs), and how it prices the storage those larger blocks create (the state-cost EIPs). Individually, each piece solves a specific engineering problem. Together, they form Ethereum’s clearest path yet toward higher throughput without sacrificing the decentralization that lets ordinary people run validators on ordinary hardware. For anyone tracking Ethereum’s long-term roadmap, Glamsterdam is the upgrade to watch through the rest of 2026.
