When Ethereum Glamsterdam Gloas-Amsterdam Update-Upgrade Countdown ETH Hard Fork Glamsterdam Date

The Glamsterdam upgrade is the next major step in Ethereum’s roadmap after Fusaka. It combines the Gloas star (for the consensus layer) with the city of Amsterdam (for the execution layer), continuing the tradition of naming upgrades after a star + city pair.

While Fusaka focused on scaling data availability and safely increasing throughput, Glamsterdam turns the spotlight on how blocks are built and executed:it brings enshrined Proposer-Builder Separation (ePBS) and Block-level Access Lists (BALs) to Ethereum’s base layer.

Activation

Network Name	Activation Epoch	Activation Timestamp
Sepolia
Holešky
Mainnet

1. Quick Overview

What is Glamsterdam?

Glamsterdam is a planned Ethereum hard fork that updates both the consensus layer (how blocks are proposed/finalized) and the execution layer (how transactions are processed). It is defined and tracked via the meta-proposal EIP-7773: Hardfork Meta – Glamsterdam.

Key ideas:

Move the current off-chain PBS setup (relays, builder markets) into the protocol as ePBS (EIP-7732).
Introduce Block-level Access Lists (BALs, EIP-7928) so nodes can execute non-conflicting transactions in parallel, instead of strictly one by one.
Explore additional EIPs around gas optimizations, Verkle trees, inclusion lists (FOCIL), and long-term L1 scalability.

Why “Glamsterdam”?

Ethereum upgrades often get two names:

a star name for the consensus layer,
a city name for the execution layer.

For this cycle:

Gloas — a G-type star — names the CL side,
Amsterdam — Devconnect host city — names the EL side.

Together they form Gloas–Amsterdam, shortened to “Glamsterdam”.

2. Glamsterdam Hard Fork: Key Facts

Note: Some values are still in flux and will be finalized closer to activation.

Parameter	Value / Status
Upgrade name	Glamsterdam (Gloas–Amsterdam)
Network	Ethereum Mainnet
Meta-EIP	EIP-7773: Hardfork Meta – Glamsterdam
Status	In planning / coordination phase
Target window (mainnet)	First half of 2026 (tentative, after Fusaka)
Consensus-layer headliner (CL)	EIP-7732 – Enshrined Proposer-Builder Separation (ePBS)
Execution-layer headliner (EL)	EIP-7928 – Block-level Access Lists (BALs)
Other notable candidates	EIP-7805 (FOCIL), Verkle-related EIPs, gas re-pricing, ZK cost optimizations

Sources indicate that core devs are targeting mid-2026 for mainnet, assuming Fusaka lands successfully and Glamsterdam devnets/testnets go smoothly.

Exact slot / block numbers and hard dates will be added once client teams agree on final parameters.

3. What Will Change With the Glamsterdam Upgrade?

At a high level, Glamsterdam aims to make Ethereum’s base layer more neutral, more efficient, and more parallel.

3.1 Before Glamsterdam

Today:

PBS is off-chain. Most blocks are assembled by external builders and relayed through trusted infrastructure (e.g. MEV-Boost relays).
This gives great efficiency, but also introduces:centralization pressure around a few large builders and relays,trust assumptions and potential censorship points.
L1 execution is largely sequential: clients execute transactions one after another, with only limited parallelism and no protocol-level description of which parts of state each tx touches.

3.2 After Glamsterdam (Target State)

Glamsterdam’s headliners push toward:

ePBS in protocolProposers no longer rely on external relays to get built blocks.The protocol itself defines how builders commit to payloads and how proposers include them.Goal: less trust, less censorship risk, more open competition among builders.
Block-level Access Lists (BALs)Builders must specify, for each block, which accounts / storage slots the block will touch.This enables clients to safely run non-overlapping transactions in parallel, using multi-core CPUs much more effectively.

In practice, users should see:

More reliable transaction inclusion in volatile times,
A base layer better able to keep up with demand,
And a block production pipeline that is less dependent on a small set of intermediaries.

4. Technical Overview of Glamsterdam

This section is for readers who are comfortable with Ethereum’s architecture and want to know what’s actually changing under the hood.

4.1 Enshrined Proposer-Builder Separation (EIP-7732, ePBS)

Problem today:

PBS is real but off-protocol — implemented by a patchwork of relays, builder markets, and custom software. This:

centralizes power in a few infrastructure providers,
increases censorship risk,
and complicates analysis of MEV and incentives.

What ePBS does:

Formally separates block proposing and block building inside the consensus protocol.
Builders submit commitments to blocks; proposers select among them via a protocol-defined mechanism.
The protocol enforces:which commitments are valid,timing windows,how rewards flow between builders and proposers.

Benefits:

Less reliance on trusted relays. The core chain logic handles the proposer↔builder handshake.
Stronger censorship resistance. It’s harder for a small set of off-chain entities to decide which transactions “exist”.
Clearer incentives for MEV markets. MEV flows through a protocolized auction rather than a fragmented off-chain ecosystem.

Research also tracks new challenges, such as the “free option” problem (builders having a short-dated option to withhold payloads in certain conditions), and explores mitigation strategies (penalties, shorter windows, etc.).

4.2 Block-Level Access Lists (BALs, EIP-7928)

Today’s situation:

When a node executes a block, it doesn’t know in advance which accounts or storage keys each transaction will touch.
Clients often must be conservative and process txs mostly sequentially, or rely on heuristics to parallelize without protocol guarantees.

With BALs:

For each block, the builder provides a block-level access list:a description of which parts of state the block will read/write.
The block is only valid if the actual execution stays within that declared access set.

This gives execution clients:

A safe blueprint for which transactions can run in parallel (non-overlapping access sets),
A way to plan disk/state access more efficiently,
A path to real multi-core scaling on L1.

Expected outcomes:

Higher effective throughput without simply cranking up gas limits blindly.
More predictable performance under load.
Better foundations for future optimizations (e.g. smarter schedulers, state sharding strategies).

4.3 Other EIPs and Scope Candidates

Glamsterdam is not only ePBS + BALs. The meta-EIP lists many proposals in different statuses (Scheduled / Considered / Proposed).

Examples being explored:

FOCIL – Fork-choice Enforced Inclusion Lists (EIP-7805)Enforced inclusion lists to strengthen censorship resistance: certain txs must be included within a defined horizon.
Verkle-related changesMoving from Merkle to Verkle trees to shrink proofs and improve state access.
Gas optimizations and metering rebaseAdjusting gas costs to reflect real resource usage, especially for ZK workloads and heavy opcodes (e.g. EIP-8059, 8057, 8058).

The final set of EIPs will be locked in after devnets and community review.

5. How Glamsterdam Affects Different Participants

5.1 Regular Users & Traders

For most end users:

No direct action is required.Holding ETH or ERC-20 tokens in a normal wallet or on an exchange will continue to work as usual.
The impact is indirect but important:More robust transaction inclusion in volatile periods (less risk that off-chain infra silently censors or misbehaves).Potentially smoother gas behavior and faster confirmations once ePBS and BALs unlock more efficient block production and execution.

Glamsterdam is mainly an infrastructure upgrade. It’s about making the network more trustworthy and performant, not about introducing a new coin.

5.2 Smart Contract Developers

For developers, Glamsterdam is a signal to:

Follow client and tooling updates (Hardhat, Foundry, node RPC changes) to ensure compatibility with ePBS and any updated gas rules.
Be aware that execution environments might parallelize more aggressively:This shouldn’t change contract semantics, but may impact gas-heavy patterns, especially those that rely on state layout or specific opcodes.

If gas repricing EIPs and Verkle-related changes are included, some contracts may see different gas profiles for the same logic — important for protocols with tight gas budgets or on-chain auctions.

5.3 Validators & Node Operators

Validators and node operators are the most directly affected:

They must upgrade their client software before Glamsterdam activates.
The proposer / builder workflow will change under ePBS:Validators might interact with new on-chain builder commitments instead of external PBS relays.MEV flows and reward accounting may shift as ePBS defines a standardized auction path.
Execution clients will gradually take advantage of BALs to:Parallelize execution,Optimize hardware usage (multi-core CPUs, storage),Improve block processing times.

For infrastructure providers, Glamsterdam is a big incentive to review their MEV / PBS stack, risk models, and monitoring.

6. Where Glamsterdam Fits in the Ethereum Roadmap

Glamsterdam is part of a long series of upgrades that gradually transform Ethereum from a simple smart-contract chain into a highly scalable, credibly neutral settlement layer.

A simplified timeline:

The Merge → PoW to PoS transition
Shanghai / Capella → withdrawals, staking QoL
Dencun → EIP-4844 blobs, cheaper data for rollups
Pectra → protocol and wallet improvements (Prague + Electra)
Fusaka → PeerDAS, safer scaling of blobspace and gas, DoS hardening :contentReference[oaicite:23]{index=23}
Glamsterdam (Gloas–Amsterdam) →ePBS: protocol-level PBS and MEV restructuring,BALs: parallel execution and better L1 performance.

In other words:

Fusaka focuses on how much data and computation Ethereum can safely handle.
Glamsterdam focuses on how blocks are built and executed, and who controls that process.

Together, they push Ethereum toward higher throughput, better decentralization, and stronger censorship resistance at the base layer.

7. Ethereum Glamsterdam Upgrade FAQ

Q1: When will the Ethereum Glamsterdam hard fork happen?

A: There is no fixed mainnet date yet. Current plans place Glamsterdam after the Fusaka upgrade, with a tentative target in the first half of 2026, subject to devnet and testnet results. Exact activation epoch/slot will be finalized by client teams closer to launch.

Q2: Do I need to do anything with my ETH or tokens?

A: For most users, no action is required. If you:

hold ETH or tokens in a self-custody wallet, or
use a reputable exchange,

your balances will simply carry over. As always, beware of scams telling you to “upgrade” or “swap” your ETH for a new token — Glamsterdam does not create a new coin.

Q3: What is the main goal of the Glamsterdam upgrade?

A: Glamsterdam’s main goals are to:

bring PBS into the protocol via ePBS (EIP-7732), reducing reliance on trusted relays and making MEV markets more transparent and censorship-resistant;
enable Block-level Access Lists (BALs) so clients can safely parallelize transaction execution and improve L1 performance.

Q4: Will Glamsterdam lower gas fees?

A: Glamsterdam is not primarily a “gas-cutting” upgrade. Instead, it:

x improves the efficiency and fairness of block production (ePBS),
and helps clients get more performance out of existing hardware (BALs and parallel execution).

Over time this can contribute to cheaper and more predictable fees, especially in combination with rollups and future scaling work — but there is no guarantee of a direct, immediate drop in base fees.

Q5: How does Glamsterdam affect MEV and censorship?

A: Today much of the MEV pipeline runs through a few off-chain actors. Glamsterdam:

enshrines PBS so the proposer–builder relationship is handled onchain,
reduces dependence on trusted relays,
and complements efforts like FOCIL (inclusion lists) and encrypted mempools being explored by the research community.

The aim is a system where:

no single actor can easily censor transactions long-term,
MEV is extracted in more transparent, competitive markets,
and validators can participate without relying on opaque external infrastructure.

8. Official Resources and Further Reading

EIP-7773 – Hardfork Meta: Glamsterdam
Ethereum Magicians Meta Thread – Glamsterdam
EIP-7732 – Enshrined Proposer-Builder Separation (ePBS)(see ecosystem articles and spec drafts)
Glamsterdam upgrade overviews and explainers
IQ.wiki: Ethereum Glamsterdam Upgrade
GetBlock blog: Ethereum Glamsterdam – What We Know So Far
Shutter blog: Shutter’s Perspective on Glamsterdam and ePBS

Disclaimer: This page is for informational purposes only. It summarizes public information about the planned Ethereum Glamsterdam upgrade and should not be treated as financial, investment, or staking advice.