Updated September 14, 2026.
Ethereum’s Glamsterdam Devnet-11 reaches genesis on September 14 at 12:00 UTC. The short-lived network is designed to test a controlled transition to the Gloas fork, with particular attention to interoperability between clients and the preparation window requested by Layer 2 operators.
The fork is scheduled for epoch 450 on September 16 at 12:00 UTC. An optional experiment then raises the gas limit from 60 million to 200 million. This is not a mainnet upgrade and does not mean Ethereum has selected that limit; it measures stability, execution pressure and bottlenecks.
| Item | Devnet-11 |
|---|---|
| Genesis | September 14, 12:00 UTC |
| Gloas fork | September 16, 12:00 UTC |
| Validators | About 84,000 |
| Gas-limit test | 60 million to 200 million |
| Scope | Multi-client transition, not adversarial testing |
What Glamsterdam Devnet-11 tests
EthPandaOps describes it as a happy-path devnet. The goal is to verify the fork transition rather than simulate extreme attacks. It copies the devnet-8 topology with six consensus clients, seven execution clients and two grid implementations. Lido, Optimism and Arbitrum are among the teams interested in the pre-fork window.
Gloas matters because it introduces enshrined proposer-builder separation and changes how consensus interacts with block construction. Before moving those rules to long-lived testnets, teams need evidence that independent clients interpret payloads, bids and validity rules consistently.
Why client readiness is uneven
The published readiness matrix shows different implementation levels. Geth, Nethermind and Lodestar met the stated floor, while other clients still had incomplete changes or failing fixtures. Prysm and Reth were below the required specification level when the matrix was checked.
That variation is why devnets exist. A multi-client fork cannot be judged through one implementation. A disagreement over bid validation or gas accounting can split a network even if each program appears healthy on its own.
The 200 million gas-limit experiment
The increase at epoch 480 is an optional stress test. More gas per block can provide more execution capacity, but it increases computation, state growth, bandwidth and hardware demands. It is neither a promise of cheaper fees nor confirmation of a mainnet target.
Our previous analysis of Glamsterdam gas repricing explains why per-operation cost and total capacity are separate levers. The guide to institutional onchain settlement provides broader context for why predictable infrastructure matters.
What the launch does not mean
Devnet-11 adds no new EIPs beyond its declared base, does not replace Platåberget and does not set a mainnet date. The Ethereum Foundation has described a staged route: stabilize development networks, upgrade Sepolia and Hoodi, and only then consider mainnet transition.
Signals to watch
The important evidence is finality after the fork, agreement across clients, performance during the gas-limit increase and resolution of known incompatibilities. A useful test is not one that hides every error, but one that finds failures before users and real capital depend on the code.
Sources: EthPandaOps Devnet-11; Ethereum Foundation.
What node and Layer 2 operators need to test
For operators, a successful fork is only the first check. Execution and consensus clients must remain synchronized, nodes should recover cleanly after interruptions and block propagation must withstand the intended load. Monitoring, logs and upgrade procedures also need to be usable before the code reaches public networks.
Layer 2 teams will focus on data availability, blob costs and compatibility with pipelines that publish batches to Ethereum. A base-layer change can affect sequencers, provers and alerting systems indirectly. The test therefore covers a wider operational chain than the client software alone.
Why Devnet-11 is not an ETH price signal
A healthy devnet can reduce engineering risk, but it does not determine demand for ETH or its market price. Public testnet stability, final specifications, broad client adoption and a mainnet date must come first. Onchain activity, application revenue, liquidity and macro conditions remain separate drivers. Devnet-11 is an important development milestone, not a promise of investment returns.
The confirmations to watch next
The strongest evidence will be transparent incident reports, participation by multiple clients, stable finality after the fork and a clear path to the next testing phase. Removing or delaying a problematic feature would not necessarily mean failure. For protocol upgrades, narrowing scope is often more responsible than advancing fragile code toward mainnet.
Glamsterdam Devnet-11 will therefore produce useful evidence even if problems emerge. The outcome of Glamsterdam Devnet-11 should be judged through the technical reports that follow, not only by whether genesis succeeds.
