Ethereum's Glamsterdam Fork Explained: ePBS, Parallel Execution, and What It Means for ETH (2026)
The complete guide to Ethereum's biggest upgrade since The Merge — two confirmed EIPs targeting decentralized block building and parallel transaction execution, a 78% gas fee reduction, and what it means for validators, holders, and the L2 ecosystem.
Published 2026-04-03 · Deep Blue Alpha
In This Guide
- What Is Glamsterdam? The Name, the Structure, the Goal
- EIP-7732: Enshrined Proposer-Builder Separation (ePBS)
- EIP-7928: Block-Level Access Lists and Parallel Execution
- What Didn't Make It: EIP-7782 (6-Second Slots) Shelved
- The Full Candidate List: 25+ EIPs Under Consideration
- What Glamsterdam Means for Gas Fees
- Blobs, Rollups, and the L2 Impact
- What This Means for ETH Holders and Validators
- What Comes Next: Hegota and Verkle Trees
- Timeline, Devnet Status, and Risks
What Is Glamsterdam? The Name, the Structure, the Goal
Every Ethereum hard fork carries a combined name reflecting its two components: the consensus layer upgrade and the execution layer upgrade. Glamsterdam is no different. It combines Gloas (consensus) and Amsterdam (execution) into a single coordinated protocol upgrade — following the same pattern as Deneb+Cancun (Dencun), Electra+Prague (Pectra), and Fulu+Osaka (Fusaka) before it.
Glamsterdam follows a chain of increasingly ambitious upgrades. Dencun (March 2024) introduced proto-danksharding and slashed Layer 2 fees by 10–100x. Pectra (2025) brought staking improvements and expanded account abstraction. Fusaka extended blob capacity and EVM efficiency. Glamsterdam goes further still, targeting the two deepest structural challenges Ethereum has not yet solved at the protocol level: the centralization of block building and the sequential bottleneck of transaction execution.
These are not incremental improvements. They are architectural changes that determine whether Ethereum can scale its base layer to compete with high-throughput alternatives, while preserving the censorship resistance and decentralization that define the network's value proposition.
Key framing: Glamsterdam is two independent problems being solved simultaneously. ePBS (EIP-7732) is about who builds blocks and how — a decentralization and MEV question. BALs (EIP-7928) are about how fast blocks execute — a parallelization and throughput question. Both have been in research for years. Glamsterdam is when they ship.
EIP-7732: Enshrined Proposer-Builder Separation (ePBS)
To understand why EIP-7732 matters, you first need to understand the problem it solves: the quiet centralization of Ethereum block building that has occurred since The Merge.
The MEV-Boost Problem
When Ethereum moved to proof-of-stake in September 2022, validators began proposing blocks. But validators discovered they were leaving money on the table: sophisticated actors (“block builders”) could order transactions within a block to capture additional value through arbitrage, sandwich attacks, and other strategies collectively called Maximal Extractable Value (MEV).
MEV-Boost emerged as an off-protocol solution: validators connect to relays, which connect to builders, and the validator gets a larger share of block rewards by accepting a pre-built block instead of constructing their own. This worked, but at a structural cost. By 2026, over 90% of Ethereum blocks are built by a small number of entities connected via MEV-Boost relays. These relays are centralized, unaccountable, and capable of censoring transactions — they operate entirely outside Ethereum's protocol with no enforcement mechanism.
This is a direct contradiction of Ethereum's censorship-resistance guarantees. A relay can decline to include specific transactions without any protocol-level consequence.
What ePBS Does
Enshrined Proposer-Builder Separation (ePBS)
The core change: ePBS makes the builder a first-class protocol participant. Instead of an off-chain relay relationship, builders register on-chain, submit signed bids, and are held accountable by the protocol itself. The proposer selects the highest valid bid and signs it. If the winning builder fails to deliver, the protocol enforces consequences — not a relay operator making a discretionary decision.
How it eliminates relay dependence: Today's MEV-Boost flow is: validator → relay → builder. With ePBS, the flow is: validator → protocol → builder. The relay is replaced by a protocol-enforced mechanism. Builders who fail to deliver after winning a bid face protocol-level slashing, not just reputational damage.
What changes for MEV: MEV itself does not disappear with ePBS — sophisticated builders will still extract value from transaction ordering. What changes is accountability and transparency. Builders compete in a protocol-visible auction, their bids are signed and attributable, and censorship requires a builder to visibly decline to include specific transactions in a signed bid — a much more observable and attributable act than relay-level filtering.
Why this matters for censorship resistance: ePBS is often paired with FOCIL (Fork-Choice Enforced Inclusion Lists, EIP-7805) — a separate EIP that allows validator committees to force-include transactions that have been waiting too long. Together, ePBS + FOCIL create a two-layer defense: builders cannot censor without it being visible (ePBS), and validators can override censorship at the consensus level (FOCIL). FOCIL's Glamsterdam inclusion is still under discussion, as the Base team has warned that including it alongside ePBS could delay the fork significantly.
Block Production Centralization: Before and After ePBS
Builder share of Ethereum blocks via MEV-Boost (pre-ePBS) vs. projected distribution under enshrined builder competition.
EIP-7928: Block-Level Access Lists and Parallel Execution
If ePBS is Glamsterdam's answer to centralization, EIP-7928 is its answer to throughput. It targets the fundamental reason Ethereum's execution layer has been difficult to parallelize — and its solution has implications for the entire EVM ecosystem.
Why Ethereum Can't Currently Parallelize Transactions
Ethereum processes transactions sequentially, one after another, within each block. The reason is straightforward: until a transaction executes, you don't know which storage slots it will read or write. If two transactions touch the same storage slot in an unpredictable order, running them in parallel risks a race condition — one transaction might overwrite state that another depends on.
This single-threaded execution model is a bottleneck. Modern CPUs have 8, 16, or 32 cores sitting idle while Ethereum executes transactions one at a time on a single thread. The theoretical throughput available from parallelism is enormous — but only if you can safely identify which transactions don't conflict.
Block-Level Access Lists (BALs)
The core change: EIP-7928 requires that every block include a pre-declared list of every account address and storage slot the block's transactions will access — before execution begins. This list is the Block-Level Access List (BAL). It is committed to by the block builder as part of the block's structure.
How parallelization becomes possible: With the BAL declared upfront, an Ethereum client can inspect the access list before executing a single transaction. Any two transactions that touch completely non-overlapping state entries have no dependencies on each other and can be executed simultaneously on different CPU cores. Transactions that share state entries must still execute sequentially relative to each other — but the vast majority of transactions in a typical block have no overlapping state, enabling broad parallelism.
The secondary benefit — faster block validation: Currently, validating a block requires fully re-executing it. With BALs, validators can pre-fetch all required state from disk before execution begins, eliminating the latency of sequential cache misses. This reduces block validation time significantly, which matters for network health at higher gas limits.
Why this enables the gas limit increase: Ethereum's gas limit — which caps how much computation fits in one block — has been deliberately kept conservative because higher gas limits slow block validation. With BALs making validation faster through parallel pre-fetching, the gas limit can be raised more aggressively without degrading network performance. Post-Glamsterdam, the gas limit is projected to increase toward 200 million gas per block (up from approximately 60 million today) — a 3x+ increase in block capacity.
Ethereum Gas Limit History & Projection
Gas limit increases as validation efficiency improves.
Sequential vs. Parallel Execution Throughput
Theoretical TPS gain from BAL-enabled parallelism.
What Didn't Make It: EIP-7782 (6-Second Slots) Shelved
Six-Second Slot Times
What it proposed: EIP-7782 would have cut Ethereum's consensus slot time from 12 seconds to 6 seconds, effectively doubling how often new blocks are proposed. Faster slots would mean faster transaction finality for users and make Ethereum more competitive with faster chains like Solana (400ms) and NEAR (1s).
Why it was shelved: Halving the slot time doubles the frequency at which validators must attest, doubles the network traffic between peers, and dramatically increases the computational and bandwidth load on node operators. Core developers determined that the infrastructure burden on the existing validator set — which includes many home validators running on consumer hardware — was too significant to include alongside the already-complex ePBS and BAL changes.
Is it gone forever? No. EIP-7782 remains an active proposal and is likely to be reconsidered for Hegota or a later upgrade, once ePBS and BALs are deployed and the network can be observed at higher gas limits. The debate around it reflects a core Ethereum tension: faster user experience vs. accessible node operation.
The Full Candidate List: 25+ EIPs Under Consideration
Beyond the two confirmed headliners, Ethereum core developers are evaluating over 25 additional EIPs for potential Glamsterdam inclusion. Their inclusion depends on testnet performance and developer bandwidth once ePBS and BALs are proven stable. The candidates span execution optimization, gas repricing, censorship resistance, and long-term scalability infrastructure.
Glamsterdam EIP Candidate List (April 2026)
| EIP | Name | Status | What It Does |
|---|---|---|---|
| EIP-7732 | Enshrined PBS (ePBS) | Confirmed | Decentralizes block building, removes relay dependence |
| EIP-7928 | Block-Level Access Lists | Confirmed | Enables parallel transaction execution |
| EIP-7805 | FOCIL (Inclusion Lists) | Likely | Validators can force-include censored transactions |
| EIP-7904 | General Gas Repricing | Likely | Recalibrates opcode gas costs using client benchmarks |
| EIP-8011 | Multidimensional Gas Metering | Under review | Splits compute, storage, and bandwidth into separate meters |
| EIP-8032 | Size-Based Storage Gas Pricing | Under review | Scales storage costs with contract state size to combat bloat |
| EIP-7782 | 6-Second Slot Times | Shelved | Would halve slot time; too complex to include alongside ePBS |
Status reflects April 2026 developer discussions. Final inclusions are determined by ACD calls and testnet results closer to launch.
What Glamsterdam Means for Gas Fees
The most concrete impact of Glamsterdam for everyday ETH users is gas fees. The upgrade targets a ~78% reduction in gas costs for both simple transfers and complex smart contract interactions. This is not a soft estimate — it's derived from the combined effects of three mechanisms working in tandem.
Mechanism 1: Gas Limit Expansion (BALs)
Gas fees are a supply/demand market. When a block fills up (demand exceeds the gas limit), fees rise as users bid for space. By enabling parallel execution and faster block validation, EIP-7928 makes it safe to raise the gas limit significantly — increasing block supply and reducing fee pressure during periods of high demand.
The projected progression post-Glamsterdam is a gas limit increase toward 200 million gas per block in stages, compared to approximately 60 million today. More block space means lower average fees per transaction.
Mechanism 2: Opcode Repricing (EIP-7904)
Many Ethereum opcodes are priced based on benchmarks from years ago. Some operations are significantly cheaper to execute on modern hardware than their gas costs reflect, while others are more expensive. EIP-7904 recalibrates these costs using current client benchmarks — reducing gas costs for overpriced operations (which account for a large share of typical smart contract execution) and increasing costs for underpriced operations that have been attack vectors in the past.
Mechanism 3: MEV Fee Reduction (ePBS)
A significant but often overlooked component of Ethereum gas fees is MEV-driven fee inflation. Bots competing to exploit arbitrage opportunities bid up gas prices for everyone, since high gas bids get priority inclusion. ePBS, by making the block-building process more transparent and accountable, is expected to reduce wasteful MEV competition over time — indirectly benefiting regular users by reducing the floor that competitive MEV bots set for base fees.
Gas Fee Reduction Drivers: Glamsterdam Target Impact
Estimated contribution of each mechanism to the ~78% gas cost reduction target.
Blobs, Rollups, and the L2 Impact
Dencun (March 2024) introduced proto-danksharding with EIP-4844, launching blobs as a dedicated data channel for rollups. At launch, the network supported approximately 3 blobs per block (target) with a max of 6. Fusaka expanded this further. Glamsterdam is expected to continue this expansion, with the target moving toward 72+ blobs per block — a 24x increase from launch.
Each blob holds approximately 128 KB of compressed rollup data. More blobs per block means more room for Layer 2 networks to post transaction batches at lower cost. The practical effect for L2 users — already benefiting from sub-cent fees on most rollups — would be a further reduction in periods of high L2 congestion, when rollup sequencers compete for blob space and fees temporarily spike.
The combination of BAL-enabled base layer throughput expansion and continued blob capacity growth represents a two-track scaling strategy: the base layer scales for security-critical and high-value transactions, while L2s handle high-volume low-cost interactions with an expanding dedicated data channel.
For ETH whale trackers: Glamsterdam's fee reductions are likely to increase on-chain activity significantly — lower fees drive more smart contract interactions, DeFi volume, and NFT activity. Higher on-chain activity means more transactions for Deep Blue Alpha's whale transaction feed to surface, and a richer signal environment for on-chain analysis.
What This Means for ETH Holders and Validators
Protocol upgrades affect different Ethereum participants differently. Here's a structured look at the Glamsterdam impact by stakeholder group.
Glamsterdam Impact by Stakeholder
| Stakeholder | Key Change | Net Impact |
|---|---|---|
| ETH Holders | Higher on-chain activity drives more EIP-1559 fee burning (ETH is deflationary during high-use periods) | Lower gas fees; potentially more deflationary supply pressure |
| Validators (Solo) | ePBS removes the need to run MEV-Boost software; protocol handles builder selection natively | Simpler node operation; lower MEV-related complexity; no relay trust required |
| Validators (Staking Pools) | ePBS levels the playing field between sophisticated institutional stakers and solo validators; MEV extraction becomes protocol-visible | Reduced edge for MEV-optimized staking operations vs. vanilla validators |
| MEV Bots / Searchers | Builder role becomes protocol-registered and accountable; censorship becomes visible; FOCIL may allow forced inclusion | MEV extraction continues but faces more scrutiny; sandwich/censorship strategies become higher-risk |
| Rollup / L2 Users | More blobs per block; lower base layer fees reduce rollup settlement costs | Further fee reductions; reduced congestion spikes |
| DApp Developers | BALs require builders to declare access lists; smart contracts benefit from lower execution costs via gas repricing | More efficient smart contracts; lower deployment and interaction costs |
| Node Operators | Higher gas limit increases block validation load; BALs help offset via parallel pre-fetching; 6-second slots deferred | Mixed: more work per block, but BAL efficiency gains expected to compensate |
What Comes Next: Hegota and Verkle Trees
Ethereum's development team has committed to a biannual upgrade cadence, and Hegota is already in early planning as the upgrade that follows Glamsterdam in H2 2026. Initial discussions have centered heavily on one major change: Verkle Trees.
Why Verkle Trees Matter
Ethereum currently stores all state — account balances, contract code, storage variables — in a data structure called a Merkle Patricia Trie. This structure works, but it has a major scalability limitation: to prove that any piece of state is valid, a node must provide a "witness" that includes large chunks of the trie structure. These witnesses grow with the size of the state, and Ethereum's state is enormous and growing.
Verkle Trees are a newer cryptographic structure that produces much smaller proofs for the same state data. The practical implication is large: with Verkle Trees, an Ethereum node could verify blocks using only a small witness that is transmitted alongside the block itself — rather than requiring the node to store the entire state locally. This is the foundation of stateless clients: nodes that verify the chain without storing gigabytes of state, dramatically reducing hardware requirements for running an Ethereum node.
Lower hardware requirements — potentially down to consumer hardware with modest storage — means more people can run their own nodes, which means more decentralization. This is Ethereum's "The Verge" phase made tangible.
The roadmap picture: Glamsterdam decentralizes block building (ePBS) and parallelizes execution (BALs). Hegota decentralizes node operation (Verkle Trees / stateless clients). Together, these two upgrades represent Ethereum's most significant structural evolution since The Merge — and they're both targeted within the same calendar year.
Timeline, Devnet Status, and Risks
As of April 2026, Glamsterdam development has progressed through Devnet-4 and is moving to Devnet-5. The Ethereum Foundation's DevOps team has successfully tested EIP-7732 and EIP-7928 implementations from multiple client teams (Geth, Nethermind, Besu, Erigon on execution; Lighthouse, Prysm, Teku, Nimbus on consensus) on the devnet environment.
Glamsterdam Development Milestones
| Milestone | Status | Target Date |
|---|---|---|
| EIP-7732 spec finalized | Complete | Q4 2025 |
| EIP-7928 spec finalized | Complete | Q1 2026 |
| Devnet-4 (multi-client testing) | Complete | Q1 2026 |
| Devnet-5 (stress testing) | In progress | Q2 2026 |
| Public testnet (Sepolia/Holesky) | Pending Devnet-5 | May 2026 |
| Mainnet launch | Pending testnet | June 2026 (target) |
Timelines are subject to change based on testnet findings. All dates are estimates from core developer discussions as of April 2026.
Key Risks That Could Delay Glamsterdam
- FOCIL inclusion debate: The Base team has publicly warned that including EIP-7805 (FOCIL) alongside ePBS could push Glamsterdam beyond 2026. If FOCIL is added to the final spec, expect the timeline to slip toward Q3 or Q4.
- ePBS free-option risk: There is a known protocol design issue where builders who win a bid but fail to deliver create a timing asymmetry that can destabilize proposer revenue, particularly during volatile market conditions. Core developers are working on mitigations, but it remains an active design challenge.
- Gas limit increase pace: The path to 200 million gas per block will be staged, and client teams may disagree on the pace of increase. Moving too fast risks nodes dropping out of the network due to validation load; moving too slowly delays the fee reduction benefits.
- Multi-client readiness: Ethereum requires all major execution and consensus clients to implement and test each EIP. Any client team falling behind schedule delays the entire fork.
Track ETH Whale Activity Through the Glamsterdam Upgrade
Monitor how large ETH holders are positioning as the upgrade approaches. Live sentiment data updated every 4 hours.
View ETH Whale Sentiment →