Skip to content
Blockchain Posts

protocol

Ethereum Glamsterdam enters final devnet phase, all EIPs in one bundle

Glamsterdam-devnet-5 and -6 are now running with every planned EIP — ePBS, BALs, gas repricing. Foundation engineers describe it as the last phase before testnet hardening.

by 5 min read
protocolethereuminfrastructure

Ethereum's next hard fork, Glamsterdam, entered its final development-network phase this week. Multi-client devnets labelled glamsterdam-devnet-5 and devnet-6 are now running with the full slate of planned EIPs combined, per a CoinDesk report dated June 16, 2026 citing core developer Parithosh Jayanthi of the Ethereum Foundation. The roadmap page on ethereum.org/roadmap/glamsterdam carries the same EIP set; mainnet activation is targeted for the second half of 2026, with no firm date yet.

What happened

After three months running individual EIPs on isolated devnets — Soldøgn closed around May 2, 2026 — the Foundation's DevOps team merged the full Glamsterdam package into devnet-5 last week and devnet-6 followed. "We're working on devnets with all the EIPs in them right now," Jayanthi told CoinDesk. "This is the last phase before we work on hardening and then shipping the testnets."

For client teams (Geth, Nethermind, Besu, Reth, Erigon on execution; Lighthouse, Prysm, Teku, Lodestar, Nimbus, Grandine on consensus), the merge is the first time every planned change runs together against the same network — the integration step that uncovers cross-EIP interactions invisible on single-EIP devnets.

What's in the fork

Three changes carry the upgrade.

EIP-7732 — Enshrined Proposer-Builder Separation (ePBS). Moves the proposer/builder split, currently handled off-chain by mev-boost relays, into the consensus protocol itself. A block builder commits to a payload header; the proposer signs only the header; the payload reveals later. The change removes the relay-as-trusted-third-party from the MEV pipeline and constrains the set of cross-actor manipulations available to MEV searchers. The proposal text is at EIPs.ethereum.org/EIPS/eip-7732.

EIP-7928 — Block-Level Access Lists (BALs). Each block declares up front which accounts and storage slots its transactions will touch. Execution clients can parallelise reads and warm state caches before processing — the prerequisite for the per-block throughput numbers that Glamsterdam targets. Specification at EIPs.ethereum.org/EIPS/eip-7928.

EIP-7904 — Gas repricing. Realigns opcode and precompile costs with measured execution times. The motivating analysis was the gap between gas-as-priced and CPU-as-spent on operations that have moved during the past five years of client optimisation. Specification at EIPs.ethereum.org/EIPS/eip-7904.

Numbers

- Glamsterdam scope            : 3 headline EIPs (7732, 7928, 7904) + smaller items
- Current Ethereum gas limit   : ~60M gas per block
- Glamsterdam gas-limit floor  : 200M gas per block (3.33×)
- Devnet status (Jun 16, 2026) : devnet-5 + devnet-6, all EIPs bundled
- Prior devnet (Soldøgn)       : concluded ~May 2, 2026
- Targeted mainnet window      : H2 2026, no firm date
- Reference                    : ethereum.org/roadmap/glamsterdam/

The 200M target is a floor — proposers can vote it higher block-by-block, as they currently do above the 30M baseline that Pectra set. Whether validators actually run at 200M from day one is a separate question from whether the consensus protocol allows it.

What it changes for operators

  • Validator operators. ePBS replaces the mev-boost trust assumption with a protocol-level commitment-reveal pattern. Existing relay setups need to be re-evaluated against the new flow; the timing of the proposer's slot changes, which interacts with attestation deadlines.
  • Block builders and searchers. The off-chain auction continues, but the settlement primitive shifts. Builder reputation systems and bond mechanics are explicit on-chain rather than implicit on relay policy.
  • Execution clients. BALs add a new pre-execution stage. Implementations that already parallelise transactions (Reth's pipelined design, Erigon's staged sync) start with a structural advantage; sequential clients carry the larger porting cost.
  • dApp builders. Most application code is untouched. The two contract-visible effects are the EIP-7904 gas repricing (some opcodes get cheaper, some get more expensive — re-estimate gas on the public testnet) and any contract that explicitly inspects block-builder addresses.

What to watch

  1. Devnet stability. The relevant signal is whether devnet-5/6 produce blocks without restarts across all client pairs for multi-day runs. The ethpandaops dashboards and the All Core Devs calls are the primary trackers.
  2. Testnet schedule. Hoodi was the Pectra/Fusaka testnet path; the Glamsterdam testnet order has not been publicly fixed. Expect Holesky and Sepolia activations between devnet stabilisation and mainnet.
  3. ACD calls. All Core Devs (Execution + Consensus) meetings publish notes on the ethereum/pm GitHub repo. The hardening checklist surfaces there first.
  4. Mainnet date proposal. A specific epoch/slot proposal lands at an ACD call after testnets settle. Mid-summer announcement, late-summer or early-autumn activation, is the implied window from the H2 framing.

Context — biggest fork since the Merge

Glamsterdam is the most-changed Ethereum fork since the Merge in 2022. Pectra (May 2025) shipped EOA delegation, validator-balance changes and small calldata adjustments — surface-level tuning. Fusaka (December 2025) shipped EIP-7594 (PeerDAS) for data-availability scaling. Glamsterdam, by contrast, touches the consensus protocol (ePBS), the execution-layer state model (BALs) and the gas-pricing schedule simultaneously. The merged-devnet phase is where forks of this scope earn or lose their planned activation window — Shapella, Dencun and Pectra each held devnet-stage timelines; Fusaka's slipped by roughly a quarter.

Sources:

Related stories