Introduction: What Is Glamsterdam and Why It Matters
Ethereum has evolved through a series of systematic upgrades that have progressively enhanced its security, efficiency, and scalability. The Glamsterdam hard fork, scheduled for the first half of 2026 (with activation targeted around June), represents one of the most significant base-layer advancements since The Merge. It combines an execution-layer upgrade (Amsterdam) and a consensus-layer upgrade (Gloas), governed by meta-EIP-7773.
This upgrade directly resolves long-standing bottlenecks in block production, transaction execution, and state management. It introduces native parallel processing capabilities, enshrines proposer-builder separation at the protocol level, and implements sustainable gas repricing mechanisms. The result is a projected increase in base-layer throughput to over 10,000 transactions per second, substantial reductions in gas fees (with estimates exceeding 78 percent for many transaction types), and a safe expansion of the gas limit from 60 million to approximately 200 million units. These improvements maintain full decentralization and ensure that node hardware requirements remain accessible for individual operators.
Glamsterdam strengthens the entire ecosystem. Users benefit from lower costs and faster confirmations. Developers gain capacity for more complex applications. Validators receive improved fairness and operational efficiency. Node operators experience reduced synchronization and storage demands. Layer-2 networks obtain more reliable and economical data availability.
Historical Context and Proposal Process
Ethereum’s development follows a disciplined schedule of approximately two hard forks per year. Following the successful deployment of Pectra (May 2025) and Fusaka (December 2025), which focused on staking enhancements and data availability, core developers shifted attention to foundational Layer-1 constraints.
In late February 2026, Vitalik Buterin and the Ethereum Foundation outlined the Glamsterdam scope. Multiple devnets were completed between March and April 2026, leading to the formalization of meta-EIP-7773. The upgrade maintains a narrow, focused scope consisting of two primary EIPs supported by targeted auxiliary changes, ensuring timely and stable implementation.The proposal was driven by three critical challenges:
- Excessive reliance on off-protocol relays for block construction
- Sequential execution limits inherent to the current EVM design
- Unsustainable state growth that outpaced hardware improvements
Comparative Overview: Pre- and Post-Glamsterdam
The following table summarizes the core problems addressed and the corresponding solutions.
| Aspect | Pre-Glamsterdam State | Post-Glamsterdam State | Primary Benefit |
|---|---|---|---|
| Block Construction | Dependent on external relays and MEV-Boost | Fully enshrined, trustless proposer-builder separation | Enhanced decentralization and censorship resistance |
| Transaction Execution | Strictly sequential | Parallel execution enabled by block-level access lists | Significantly higher throughput |
| Gas Limit | Capped at approximately 60 million | Expanded to approximately 200 million | Lower fees and greater capacity |
| State Management | Growing without corresponding cost reflection | Dynamic gas repricing tied to real resource costs | Long-term sustainability for nodes |
| Propagation Window | 2–4 seconds | Extended to approximately 9 seconds | Support for larger, safer blocks |
Core Technical Change 1: Enshrined Proposer-Builder Separation (EIP-7732)
Enshrined Proposer-Builder Separation (ePBS) integrates block construction directly into the protocol, eliminating reliance on third-party relays. Builders become staked participants within the beacon chain, with a minimum stake of
ETH and no validator-style churn limits.In the new workflow:
- The proposer publishes a SignedExecutionPayloadBid containing commitments to the block hash, value, fee recipient, and blob details.
- A randomly selected Payload Timeliness Committee (approximately 512 validators) attests to timely payload delivery and data availability.
- Full execution validation is deferred, providing an extended propagation window.
- Payments are executed automatically by deducting from the builder’s staked balance and queuing a withdrawal to the proposer’s designated address.
This mechanism ensures unconditional payment to honest proposers while imposing penalties on non-compliant builders. The extended timing window enables substantially larger blocks without compromising liveness or safety.
Key Specification Elements
The beacon block body now includes a signed_execution_payload_bid and payload_attestations list. The ExecutionPayloadBid container defines parent hashes, block hash, value, and other fields, all secured by BLS signatures.
Core Technical Change 2: Block-Level Access Lists (EIP-7928)
Block-Level Access Lists (BALs) provide a complete pre-execution map of all state accesses within a block. This map records every account address, storage slot (reads and writes), balance changes, nonce updates, code modifications, and post-execution values.
The block header includes block_access_list_hash, computed as keccak256(rlp.encode(BlockAccessList)). The BlockAccessList itself is an RLP-encoded list of AccountChanges entries, each containing- Address
- Storage slot changes and pure reads
- Balance, nonce, and code modifications indexed by BlockAccessIndex (0 for pre-execution system operations, 1–n for transactions, n+1 for post-execution withdrawals)
This structure enables:
- Parallel disk prefetching of all required state
- Concurrent execution of non-overlapping transactions
- Executionless synchronization for new nodes, which apply final state diffs directly
A companion networking upgrade (EIP-8159, eth/71) facilitates efficient exchange of access lists among peers.Comparative Execution Model
| Execution Model Feature | Pre-Glamsterdam | Post-Glamsterdam (with BALs) | Resulting Advantage |
|---|---|---|---|
| Data Loading | Sequential | Parallel prefetch | Reduced I/O latency |
| Transaction Processing | One-by-one | Parallel for disjoint access sets | Higher effective TPS |
| State Root Computation | Sequential | Parallel Merkle updates | Faster block finalization |
| Node Synchronization | Full transaction replay | Direct application of final diffs | Dramatically faster sync times |
Supporting Changes and Gas Repricing (EIP-8007 and Related Proposals)To support the expanded capacity and maintain sustainability, Glamsterdam includes calibrated gas adjustments:
- Gas limit increase to approximately 200 million units
- Higher costs for new account creation and large contracts (EIP-8037) to reflect permanent storage burden
- Adjusted state access costs (EIP-8038) aligned with hardware realities
- Repricing of selected computation opcodes (EIP-7904)
- Reduced intrinsic transaction cost with new-account surcharges and calldata floors (EIP-2780 and EIP-7976)
Additional improvements encompass:
- Emission of logs for native ETH transfers (EIP-7708)
- Deterministic factory predeploy for consistent cross-chain addressing (EIP-7997)
- Enhanced validator exit and consolidation queues (EIP-8061)
- Updated networking protocols for partial receipts and sparse blob pools
These changes ensure that simple transfers become substantially cheaper while complex operations benefit from the overall increase in throughput.
Operational Impacts Across Stakeholder Groups
Users – Transactions on the base layer incur lower fees and achieve faster confirmations. No wallet or account modifications are required.
Developers– Larger contracts and more sophisticated decentralized applications become feasible. Parallel execution reduces contention between unrelated transactions. New deterministic addressing simplifies multi-chain deployments
Validators and Stakers– MEV distribution becomes more transparent and fair. Exit queues are streamlined, and dependence on external infrastructure is reduced.
Node Operators– Synchronization times decrease significantly due to execution less mode. Parallel I/O lowers CPU and storage pressure, supporting broader participation.
Layer-2 Networks and Broader Ecosystem– Improved data availability at the base layer lowers rollup costs and enhances finality guarantees, strengthening the entire scaling stack.
Implementation, Testing, and Activation Timeline
Development and testing followed Ethereum’s established process. Private devnets progressed rapidly in early 2026, followed by public testnets on Holešky and Sepolia. All major execution and consensus clients (Geth, Nethermind, Prysm, Lighthouse, and others) maintain dedicated Glamsterdam branches.The fork activation will occur at a predetermined epoch and slot, with the exact timestamp announced approximately two weeks in advance. Node operators and infrastructure providers are advised to update client software prior to the scheduled activation. Users and application developers require no immediate action, as the transition is backward-compatible for existing transactions and contracts.