Core developers have moved Glamsterdam's multi-client devnet into its final stage, with a 200 million gas-limit target that would roughly triple current L1 capacity if it survives contact with mainnet.
Ethereum's core development teams moved the Glamsterdam upgrade into its final devnet stage in mid-June, running a multi-client testbed that carries the full slate of proposed EIPs and a 200 million gas-limit target. The mainnet activation is being scheduled for the second half of 2026, most likely between September and December on the two-to-four month public-testnet cadence the last three hard forks have followed.
The gas-limit number is the one every builder outside protocol research will notice first. Ethereum's current base-layer capacity sits at roughly 60 million gas per block. A 200 million floor would roughly triple that, and — if the pipes hold under real load — put the L1 in a position to handle a workload proponents estimate at around 10,000 transactions per second under realistic conditions. That is not a headline TPS number pulled from a synthetic benchmark; it is what the client teams believe the network can sustain once parallel execution is wired in.
The two EIPs that make the higher limit safe are EIP-7732 and EIP-7928. EIP-7732 introduces enshrined proposer-builder separation — ePBS in the shorthand — which splits the responsibility for building a block from the responsibility for finalising it. Under today's arrangement, validators do both, which forces the propagation window to stay narrow enough that a single node can process the full block before the next slot begins. ePBS widens that window from about two seconds to roughly nine seconds, because builders and proposers can operate on different timelines. That extra headroom is what allows the base layer to safely carry more data blobs for layer-twos and larger execution loads for the L1 itself.
EIP-7928 handles the other half of the problem. Block-Level Access Lists require every transaction in a block to declare, in advance, which state it will touch. That declaration lets clients pre-fetch state in parallel and execute independent transactions concurrently, which is the mechanism that turns a higher gas limit from a theoretical target into a workable one. Without BALs, tripling the gas limit would triple validator hardware requirements and start pricing out home stakers within a fork or two. With BALs, most of the added capacity comes from parallelism, not from bigger machines.
The other proposals in the fork are more incremental. EIP-8037 tightens the rules for how the beacon chain handles late blocks; the balance of the slate is a set of housekeeping changes covering log formats, gas repricing on a handful of opcodes, and the standard cleanup a hard fork uses to retire technical debt. None of them will move ETH's market price. The two that matter — ePBS and BALs — are what Glamsterdam is really about.
The multi-client devnet is where the plan meets the code. Geth, Nethermind, Besu, Erigon and Reth on the execution side, and Prysm, Lighthouse, Teku, Lodestar and Nimbus on the consensus side, all have to produce compatible implementations that agree on every edge case. Multi-client testing at devnet scale is the point where hard forks quietly fail; the Dencun cycle uncovered client-specific issues that were caught before mainnet activation, and Pectra's testnet phase did the same. Glamsterdam's devnet has been running for roughly six weeks, and the final phase is where the difficult bugs surface.
The 200 million target isn't locked. It's what client teams believe they can defend if the devnet phase closes cleanly and if the two public testnets — probably Sepolia and Holesky — hold at the same target under adversarial load. If the load tests expose a client-specific memory or bandwidth ceiling, the mainnet limit will be raised in stages after activation rather than all at once. That is exactly how Dencun and Pectra handled their most aggressive parameters: ship the mechanism, dial the number.
For rollups, the practical consequence is cheaper data availability. The Cancun fork's introduction of EIP-4844 blob transactions gave layer-twos a dedicated pricing lane for calldata, and the drop in rollup fees was the visible result. Glamsterdam's expanded propagation window means the base layer can safely carry more blobs per slot without pushing validator requirements up. That translates directly into lower per-transaction costs on Arbitrum, Optimism, Base and every other rollup that pays for its data through 4844.
The developers running Glamsterdam are not selling a headline throughput number. They are selling a base layer that can, for the first time since the Merge, take a genuine step-change in capacity without asking home stakers to buy new hardware. Whether the mainnet configuration lands at 200 million gas or a more conservative 120 million will depend on what the last devnet weeks and the two public testnets uncover. The mechanism is what matters. The number will follow.
