Quicknode

March 20, 2026 — 10 min read

Ethereum's next hard fork is Glamsterdam, a two-layer upgrade combining Gloas on the consensus side and Amsterdam on the execution side.

This fork introduces changes that affect how blocks are constructed, validated, and executed at the protocol level across Ethereum. Before we dive into specific upgrade items, we need to highlight that most forks usually adjust gas costs, add/change opcodes, and perform similar low-impact and more-so hygiene checks.

That said, Glamsterdam is a more comprehensive upgrade that aims to improve how Ethereum builds and executes blocks at a structural level.

This piece will explain Glamsterdam, the 2 confirmed EIPs, the other EIPs being considered, and everything in and around this upgrade.

TL;DR of Glamsterdam Upgrade

1. Glamsterdam is Ethereum's next hard fork, scheduled for 2026, succeeding Fusaka.

2. Only two EIPs are confirmed: EIP-7732 (ePBS) and EIP-7928 (BALs).

3. ePBS or EIP-7732 moves the proposer-builder coordination from relays into the protocol.

4. EIP-7928 introduces Block-Level Access Lists (BALs), which declare block state access upfront

5. Together, ePBS and BALs remove blind spots in block construction and execution.

6. Glamsterdam lays the groundwork for parallel execution, proofs, and future scaling upgrades.

What's Actually Confirmed for the Glamsterdam Upgrade

Of everything being discussed around Glamsterdam, only two EIPs are formally scheduled for inclusion:

• EIP-7732 (Enshrined Proposer-Builder Separation), and

• EIP-7928 (Block-Level Access Lists)

There are a few other proposals being considered, but let's first understand these 2 confirmed upgrades.

EIP-7732: Enshrined Proposer-Builder Separation (ePBS)

EIP-7732 moves proposer-builder separation from offchain infrastructure into the Ethereum protocol itself.

Problem: Block-building is running on external trust

Today, most validators outsource block construction to specialized builders, which build and deliver blocks via external relays (most commonly via MEV-Boost).

This validator-builder relationship is facilitated by a third-party ‘relay’ external to Ethereum on a ‘trust me’ basis and carries no cryptographic guarantee.

ePBS removes that trust dependency. The proposer-builder deal moves into the protocol itself by enabling builder bids and payload commitments live onchain.

How ePBS Actually Works

ePBS makes Ethereum the referee for the entire block production process and enforces a commit–reveal pipeline throughout.

Here's how:

1. Builder bids and payload commitment

Builders construct candidate blocks and publish bids on a new gossip topic. Each bid includes:

• the value offered to the proposer

• a payload commitment (hash of the execution payload)

• the builder’s signature

At this point, the network knows which payload is promised, but not its contents. And the proposer’s payment from the builder is settled by the protocol.

Validators can now attest to the beacon block immediately, without executing transactions.

2. Builder reveals the execution payload

After the beacon block is accepted, the winning builder broadcasts the full execution payload that matches the earlier commitment.

A subset of validators called the Payload Timeliness Committee (PTC) performs basic checks:

• The builder’s signature is valid

• The revealed payload hash matches the commitment

• Blob data referenced by the block is available

PTC members do not execute the block. They only verify that the payload arrived on time and matches the commitment.

3. Execution validation across the network

Once the payload is revealed, nodes execute the transactions and verify that the resulting state transition matches the block.

Because the payload was committed earlier, the builder cannot modify the block contents after winning the bid.

In case the builder fails to reveal the payload or fails to deliver it on time:

• The slot is recorded as Empty

• The proposer keeps the bid payment

• The builder loses the full value of the bid

In this, there is no relay or other third party involved. Ethereum as a protocol will enforce the outcome directly onchain.

Now, we have learnt that EIP-7732 or ePBS majorly addresses block production issues at the consensus level. The 2nd confirmed change in the Glamsterdam upgrade, i.e., EIP-7928, aims to fix what happens once the block is handed to the network to execute. Ethereum

EIP-7928 — Block-Level Access Lists (BALs)

EIP-7928 introduces Block-Level Access Lists (BALs), which are a record of the accounts and storage slots accessed during the execution of a block.

Problem: State access is handicapping Ethereum, nodes

Ethereum clients only discover which accounts and storage slots a block touches during execution.

Until then, nodes have no visibility into the block’s state access pattern.

Because Ethereum state lives on disk, execution must wait for random disk reads, making state access the primary bottleneck.

Although EVM can finish computation fast, it's waiting on each storage read to make a round trip across a database that is growing larger every day.

EIP-7928 solves this.

How BALs Actually Work

While constructing the block, the builder’s execution client records every state access performed by the transactions like:

• accounts touched

• storage slots read

• storage slots written

And this map is the Block-Level Access List.

Its hash, or the 'BAL root', is included in the block header. The full list travels with the block to every node on the network.

Simply put, each block now carries a verifiable map of the state it depends on.

What BALs Unlock for Ethereum

1. The entire working state is prefetched before execution begins, eliminating mid-execution storage round-trips.

2. BALs make parallel transaction execution strategies possible on Ethereum.

3. Knowing the state root computation.

4. BALs also state updates without re-executing every transaction, which is useful for ZK verification.

Now, we understand ePBS and BALs in depth,risk on what they are and what they aim to improve. But, together, do they help Ethereum?

What Glamsterdam Actually Changes in Ethereum

Individually, EIP-7732 and EIP-7928 solve very different problems.

But taken together, they do something deeper: they expose 2 parts of Ethereum that run on the ‘trust me’ model and embed their solutions onchain.

With ePBS, Ethereum Finally Knows Who Built the Block

Before ePBS, the builder was invisible to the protocol.

A block arrived, and Ethereum had no record of who constructed it, what they committed to, or whether they honored that commitment.

That information lived off-chain inside external relay infrastructure.

After ePBS, the builder is a first-class protocol participant: an actor with a registry identity, signed bids, and protocol-enforced accountability.

However, to be honest, this matters less for Glamsterdam itself than for what it enables next.

Mechanisms like FOCIL, encrypted mempools, MEV-routing changes, and future builder penalties all become easier to design in a world where the protocol can identify the builder and hold it to commitments.

BALs Help Ethereum Understand What State the Block Touches

Before BALs, Ethereum also had no visibility into what state a block would access.

After BALs, state access is declared upfront, committed in the block header, and verified against the actual execution trace.

This is the information layer that the next generation of Ethereum scaling techniques all depend on:

1. Parallel execution requires knowing transaction conflicts in advance.

2. ZK-proofs based execution benefits from an explicit record of state access.

3. More experimental designs like segmented state become much easier to reason about once a block declares its state footprint up front.

BALs make all of them structurally viable.

Ethereum Execution Can Now be Treated as a Dependency Graph

Sequential execution is a choice Ethereum made by necessity.

Without knowing in advance which state a transaction touches, two simultaneous transactions risk a grave conflict: one overwrites the state the other was reading.

Serialization was the only safe option.

BALs change that by turning block execution into something closer to a dependency graph. And graphs can be traversed simultaneously by multiple threads.

Transactions that touch independent states can be scheduled in parallel, and the required state can be prefetched before the EVM runs.

Together, these two EIPs remove two long-standing blind spots in Ethereum’s architecture.

Apart from these two confirmed EIPs, there's a broader set of proposals being evaluated for this upgrade. Here's the full picture.

EIPs Associated With the Glamsterdam Upgrade

Scheduled for Inclusion

Scheduled = confirmed in this fork.

Considered for Inclusion

Considered = under evaluation, not guaranteed.

Note: There are a few more EIPs in consideration for the Glamsterdam upgrade.

Declined for Glamsterdam

More than 30 proposals were explicitly excluded from the fork, including:

• FOCIL inclusion lists

• Reduced slot times

• Multidimensional gas metering

• Post-quantum signature verification

These are the proposals on the table for the Glamsterdam upgrade. But, what does this actually mean for builders/developers?

Practical Impact: What Glamsterdam Means for You

The impact of Glamsterdam shows up differently depending on where each of us sit in the stack.

Most dapp builders will barely notice it, but infra-first teams need to do some heavy-lifting. Let’s try to make sense of it:

Block Production Stack

Who are we talking to: validators, builders, relays, MEV infrastructure

The biggest operational change comes from ePBS.

All infrastructure built around relay behavior, builder APIs, or the current proposer-builder handshake needs to be re-evaluated against the new model.

• Builders become staked protocol participants with onchain identity.

• Validators gain new duties around payload timeliness: committee membership, new timing sensitivities, and new monitoring requirements.

• MEV infra players need to rethink private order flow arrangements, bundle submission mechanics, and timing assumptions

Data and Tooling Stack

Who are we talking to: RPC providers, indexers, block explorers, simulators

BALs introduce a new artifact: the block state access map. Any system that parses, indexes, stores, or serves block data, note that the schema is changing.

What to track:

• Block header gains a new field: block_access_list_root.

• Engine API is extended to carry BALs in the payload.

• eth/71 is a new wire protocol for serving BALs peer-to-peer.*

• EL clients must store BALs for at least 3,533 epochs. This means archival and storage cost assumptions change.

*Nodes that don't implement it won't be able to serve or request BALs from peers.

Dapp Layer

Who are we talking to: dapp teams, protocol teams, smart contract developers

Honestly, most app-layer teams don't need to act on Glamsterdam right now.

Again, Glamsterdam doesn’t immediately scale Ethereum. It removes the structural bottlenecks that prevented scaling techniques from being deployed safely.

But improvements in execution what comes next?

What’s Next for Ethereum: The Hegotá Upgrade

If Glamsterdam exposes the information layer of Ethereum — who builds blocks and what state they touch — the next step is to use that information to improve censorship resistance and block inclusion guarantees.

The first major candidate here is FOCIL (Fork-Choice Enforced Inclusion Lists).

Beyond FOCIL, the broader Ethereum roadmap is pointed in one direction: toward ZK-verified execution at scale.

Vitalik's scaling framework is explicit: ePBS and BALs deliver 10–30x improvements in execution in the short term. ZK-EVMs deliver 1000x in the long term.

Glamsterdam is the infrastructure layer that enables these paths.