Ethereum's Glamsterdam hard fork entered its final devnet phase on June 16, 2026, bundling ten Ethereum Improvement Proposals under Meta EIP-7773 before public testnet deployment. The upgrade — which simultaneously updates the Execution Layer (Amsterdam) and Consensus Layer (Gloas) — targets a ma...
"This is probably the largest fork we've had since the Merge." — Parithosh Jayanthi, Ethereum Foundation DevOps Engineer
Ethereum's Glamsterdam hard fork entered its final devnet phase on June 16, 2026, bundling ten Ethereum Improvement Proposals under Meta EIP-7773 before public testnet deployment. The upgrade — which simultaneously updates the Execution Layer (Amsterdam) and Consensus Layer (Gloas) — targets a mainnet activation window of late August to September 2026, according to validator infrastructure provider Everstake.
Two headline EIPs carry the structural load. EIP-7732 enshrines Proposer-Builder Separation (ePBS) directly into the consensus protocol, eliminating reliance on external relay infrastructure that currently handles approximately 88% of Ethereum blocks. EIP-7928 introduces Block-Level Access Lists (BALs), which pre-declare accounts and storage slots touched per block, enabling parallel transaction execution across multiple CPU cores. Together, these changes clear the path for validators to vote the gas limit from the current 60 million toward a 200 million target — roughly tripling Layer 1 capacity.
Gas fees on Ethereum mainnet currently average 0.41 gwei (approximately $0.01 per simple transfer), down from ~72 gwei in early 2024. Glamsterdam does not directly lower fees further but addresses structural constraints — builder centralization, sequential execution, and relay dependency — that would otherwise limit the network's ability to absorb demand growth without reverting to congestion-driven fee spikes.
Glamsterdam's development follows a structured sequence. The Soldøgn interop devnet, which tested cross-client compatibility for the initial EIP set, concluded on May 2, 2026. Core developers then advanced to glamsterdam-devnet-5 (launched around June 4) and devnet-6 (mid-June), running the full slate of ten EIPs across all major Ethereum client implementations.
EIP-7773, the meta-specification authored by Tim Beiko, Alex Stokes, and Ansgar Dietrichs, remains in Draft status as of June 17. This is standard procedure — the meta EIP typically advances to Review only after public testnet milestones are met.
The original target was mainnet activation in June 2026. That window closed. Everstake's June 2026 review estimates end-of-August 2026 as the current best case. Historical precedent from prior forks (Shapella, Dencun, Fusaka) suggests two to four months of public testnet seasoning after final devnets, placing mainnet activation between September and December 2026. The predecessor fork, Fusaka, activated on December 3, 2025, at epoch 411,392 (block 23,935,694).
Since the Merge in September 2022, Ethereum has relied on MEV-Boost, an out-of-protocol system developed by Flashbots, to separate block proposing from block building. Proposers (validators selected to add the next block) outsource block construction to specialized builders who compete to assemble the most valuable transaction bundle.
This system works but creates structural risks. According to RelayScan data as of June 18, 2026, the top four builders — Titan (53.46%), Quasar (26.24%), Eureka (8.39%), and BuilderNet (8.16%) — control approximately 96% of block production. A single entity, Titan, builds more than half of all Ethereum blocks. On the relay side, Ultrasound (28.80%), Titan Relay (20.28%), and two BloXroute instances (19.29% and 18.40%) account for the vast majority of block delivery.
EIP-7732 eliminates the need for external relays by hardcoding the proposer-builder handoff into the consensus layer. Key mechanics include:
Vitalik Buterin outlined a multi-stage plan extending beyond Glamsterdam. Subsequent upgrades (targeted for the Hegotá fork in late 2026 or early 2027) would add FOCIL (Fork-Choice Inclusion Lists) — requiring 16 randomly selected attesters to nominate transaction sets that must appear in blocks — and eventually encrypted mempools to eliminate frontrunning at the cryptographic level.
Sequential transaction execution is Ethereum's primary throughput constraint. Today, every transaction in a block is processed in order because the EVM cannot guarantee that two transactions do not access the same state.
EIP-7928 addresses this by requiring blocks to carry a map of all accounts and storage slots they will touch before execution begins. If Transaction A and Transaction B touch completely different accounts, validators can process them simultaneously across multiple CPU cores.
This is the prerequisite for raising the gas limit. Without parallel execution, a 200 million gas limit would simply mean longer block processing times, increasing the risk of missed blocks and chain tip instability. With BALs, the computational load distributes across available hardware.
The practical throughput gain depends on workload characteristics. Theoretical models suggest up to 10,000 TPS-equivalent throughput under favorable conditions (many unrelated transactions). Real-world gains will vary. As CryptoBriefing noted in its June 17 coverage: "The gains will depend on client performance, validator hardware, gas repricing, and how much parallelism real blocks can actually support."
Glamsterdam ships ten EIPs tracked under EIP-7773. Beyond the two headliners:
| EIP | Function | |-----|----------| | EIP-7976 | Increases calldata floor cost, discouraging data-heavy transactions that disproportionately burden nodes | | EIP-7981 | Raises EIP-2930 access list cost, adjusting pricing to reflect actual node resource consumption | | EIP-8037 | Increases state creation gas cost, making contract deployment and state expansion more expensive to mitigate state bloat | | EIP-7954 | Raises contract size limit, allowing larger smart contracts to be deployed | | EIP-7778 | Removes gas refunds from block accounting, simplifying execution-layer gas calculations | | EIP-8024 | Introduces new stack-manipulation opcodes for EVM optimization | | EIP-7843 | Adds SLOTNUM opcode, enabling smart contracts to reference the current slot number | | EIP-7708 | Makes ETH transfers emit logs, improving indexing and accounting for native ETH movements |
Two notable exclusions: EIP-7782 (6-second slots), shelved due to insufficient maturity, and FOCIL (Fork-Choice Inclusion Lists), deferred to Hegotá to reduce the fork's complexity surface.
The concentration of block building in four entities is not merely a decentralization aesthetic concern. It has measurable economic consequences.
Builders extract MEV (Maximal Extractable Value) — profit from reordering, inserting, or censoring transactions within a block. When four builders control 96% of block production, they collectively determine transaction ordering for nearly all of Ethereum's economic activity. Some MEV-Boost relays filter OFAC-sanctioned transactions, creating protocol-level censorship outside of Ethereum's consensus rules.
According to MEV Watch data, the share of blocks produced through OFAC-compliant relays has fluctuated between 30% and 60% over the past year, meaning a meaningful portion of Ethereum's block space is subject to non-protocol censorship criteria imposed by relay operators.
ePBS does not eliminate MEV extraction. Builders will still compete to assemble the most valuable blocks. But it removes the relay layer — where censorship currently happens — and replaces it with a protocol-enforced, permissionless marketplace where any builder can submit a payload without relay approval. Future additions (FOCIL, encrypted mempools) aim to constrain builder behavior further.
Solo stakers and institutional validators must update both Consensus Layer and Execution Layer clients before activation. The new PTC duty — attesting to builder payload timeliness — requires software support that will be included in pre-fork client releases.
Node operators running validators on modest hardware face a new consideration: parallel execution under BALs increases storage I/O demands. Operators should audit disk IOPS capacity ahead of the fork. SSD-based setups (already recommended since the Merge) should handle the load; HDD-based nodes may experience degraded performance.
ETH holders who are not staking require no action.
Smart contract developers face no immediate compatibility breaks. Existing contracts remain functional. However, the gas repricing EIPs (7976, 7981, 8037) alter cost structures for state-creation-heavy and calldata-heavy operations. Protocols relying heavily on these patterns should model the cost impact before mainnet activation.
Fusaka's post-launch metrics provide context for what Glamsterdam-scale changes look like in practice. After Fusaka's blob parameter increases (BPO1 on December 9, 2025, raising blob targets to 10/max 15; BPO2 on January 7, 2026, to 14/max 21), median blobs per block fell from ~6 pre-BPO1 to ~4, while block miss rates rose from a 0.5% baseline to 1.79% at the 21-blob ceiling. Similar tuning dynamics are expected post-Glamsterdam.
Glamsterdam's impact on Layer 2 rollups is indirect but consequential. The extended propagation window introduced by ePBS (from 2 to ~9 seconds) creates headroom for future blob capacity increases, which directly reduce data availability costs for rollups posting transaction data to Layer 1.
Higher L1 gas limits also reduce congestion-driven base fee spikes. For rollups that settle proofs on mainnet, peak-hour settlement costs become more predictable. This aligns with Ethereum's explicit scaling architecture: Layer 1 as the settlement and data availability layer, Layer 2 for high-frequency execution.
The gas repricing EIPs have a secondary effect. By increasing state creation costs on L1, they create stronger economic incentives to keep execution on Layer 2, reinforcing the rollup-centric roadmap.
Three factors could delay mainnet activation:
ePBS implementation complexity. Enshrining proposer-builder separation into the consensus layer is architecturally novel. No other major proof-of-stake network has attempted protocol-level PBS. Edge cases in PTC attestation, builder payment enforcement, and payload delivery timing require extensive testing.
Cross-client parity. Ethereum maintains five consensus clients and five execution clients. All must implement the full EIP set with byte-level consensus. Historical forks have encountered client-specific bugs during testnet phases. Glamsterdam's scope — ten EIPs including two structural changes — increases the surface area for implementation divergence.
Gas repricing under mainnet-scale load. The cost adjustments in EIPs 7976, 7981, and 8037 alter economic incentives for state creation and calldata usage. Behavioral effects (developers restructuring contracts to minimize new costs) cannot be fully modeled in devnet environments with synthetic workloads.
Glamsterdam is structurally significant because it addresses the two constraints that Ethereum's rollup-centric roadmap has deferred: builder centralization and sequential execution. The current state — where one entity builds 53% of all blocks through an out-of-protocol relay system — is a known risk that ePBS is engineered to mitigate, not eliminate. BALs unlock the capacity headroom that makes a 200M gas limit viable without degrading block propagation.
The fork does not solve MEV extraction, transaction censorship, or validator centralization in a single upgrade. It is the first step in a multi-fork sequence (Glamsterdam → Hegotá → future forks) that progressively constrains builder behavior through inclusion lists, encrypted mempools, and network-layer privacy.
Market participants should monitor three signals: public testnet stability post-devnet-6, the validator gas-vote trajectory toward 200M after activation, and whether ePBS measurably reduces relay concentration. The data from those events will determine whether Glamsterdam delivers on its structural objectives or surfaces new bottlenecks.