Ethereum is preparing Glamsterdam for the fourth quarter of 2026. There is still no confirmed mainnet date, but the official roadmap now lists the Sepolia fork on October 6 as the next major public milestone.

The upgrade is already running across development networks and Platåberget, a temporary public testnet created specifically to give application developers, validator operators and infrastructure providers time to break their tooling before the same changes reach Ethereum's long-lived testnets.

That matters because Glamsterdam is not simply a collection of isolated EIPs. Several changes alter assumptions that Ethereum software has relied on for years.

Ethereum block production currently relies on plumbing outside the protocol

The first major change is ePBS: enshrined Proposer-Builder Separation.

Ethereum already separates two jobs in practice. The validator selected to propose a block can obtain that block from specialized builders competing to assemble the most valuable execution payload.

The complication is that this relationship currently depends partly on off-protocol infrastructure, including relays that connect builders and proposers.

Ethereum benefits from specialized block building, but an important part of that handoff sits in middleware the core consensus protocol cannot fully enforce.

EIP-7732 moves the relationship into the protocol itself.

Removing middlemen is only part of what ePBS changes

One of its biggest benefits is time.

In today's architecture, an important portion of transaction propagation and execution sits inside a tight window of roughly two seconds.

Glamsterdam restructures the slot by more explicitly separating the consensus block from the execution payload supplied by a builder.

Ethereum's roadmap says this expands the useful propagation window from around two seconds to roughly nine seconds.

That does not mean Ethereum slots suddenly become nine seconds longer.

It means more of the existing slot becomes available for distributing and validating large payloads.

That extra margin matters if Ethereum wants to increase L1 execution while simultaneously carrying more blob data for Layer 2 networks.

The builder becomes a participant the protocol can actually hold accountable

Enshrining proposer-builder separation also moves builder payments and delivery guarantees into Ethereum's own rules.

A proposer can select a builder's bid without relying solely on an external relay to guarantee that the promised payload arrives correctly.

Glamsterdam introduces protocol mechanisms including payload-timeliness checks to reason about that delivery.

This is considerably more complicated than replacing one middleware service.

Consensus clients now have to deal with cases in which the proposer and builder perform different parts of the block-production sequence and one side may fail or arrive late.

That complexity is one reason ePBS has required so much multi-client testing.

Block-Level Access Lists attack the other half of the scaling problem

ePBS changes how blocks are built and propagated. Block-Level Access Lists, or BALs, focus more directly on executing them.

A node currently discovers much of the state a transaction needs while executing that transaction.

That dynamic discovery encourages serial work: one operation runs, its state accesses become known, and subsequent processing follows.

EIP-7928 adds an enforced block-level record of the state locations that transactions access and the post-execution changes they produce.

The execution client therefore receives a much clearer map of the work in advance.

Knowing dependencies in advance is what makes parallel execution practical

Two independent transactions do not inherently need to wait for one another.

If a client knows that they touch different accounts and storage slots, it can preload data or process independent pieces of work across multiple CPU cores.

BALs do not magically turn the EVM into a fully parallel execution engine on fork day.

They provide the structured dependency information client developers need to exploit parallelism safely without discovering every dependency in real time.

That is an important distinction: Glamsterdam is building the foundation for parallel execution rather than claiming every transaction will immediately run simultaneously.

Nodes may also be able to follow state without replaying every transaction

Block-Level Access Lists enable another concept: executionless sync.

A conventional full node derives state changes by executing the transactions that caused them.

BALs also expose post-execution state changes.

That creates the possibility for some node roles to update state from verified outcomes instead of re-executing every individual operation.

This does not eliminate the need for nodes that independently verify execution.

It can, however, make certain synchronization and infrastructure workloads substantially cheaper.

The third problem is quieter: Ethereum's database keeps growing

A higher gas limit allows more operations into every block.

Those operations do not all impose the same long-term hardware cost.

A computation uses CPU time and then disappears. Creating an account, storage slot or deployed bytecode can enlarge the state database that nodes may have to retain and query for years.

Glamsterdam therefore changes how gas represents those costs.

EIP-8037 separates the cost of creating persistent state

EIP-8037 raises and harmonizes the price of operations that create new state, including accounts, storage slots and deployed bytecode.

More importantly, it meters that growth through a separate state-gas dimension.

A simple ETH transfer to an existing account can retain its familiar base cost, while an operation that creates additional persistent state can carry an extra state-related charge.

The goal is not merely to make selected transactions more expensive.

It is to prevent a large execution-capacity increase from automatically causing an equally dramatic expansion of the database every node has to manage.

EIP-8038 reprices reading that state too

Ethereum has not comprehensively recalibrated several state-access costs since the Berlin fork in 2021.

The database has grown significantly since then, while client performance measurements have become much better.

EIP-8038 increases costs for operations including SLOAD, SSTORE, cold account access and other state-heavy work so gas more accurately represents the actual hardware burden.

The reasoning is straightforward.

If the protocol underprices an expensive operation, increasing the overall gas limit allows too much of that expensive operation into a single block.

A high limit is sustainable only when one unit of gas is a reasonably accurate representation of the work it purchases.

That is where the 200-million-gas target comes from

During a protocol interoperability event earlier this year, Ethereum teams established a credible post-Glamsterdam target of roughly 200 million gas.

That figure is not an automatic mainnet setting scheduled to switch on with the fork.

It represents a capacity level developers consider technically defensible once ePBS, BAL-related optimizations and state repricing converge.

The distinction from a simple gas-limit increase is crucial.

Arbitrarily jumping to 200 million would simply demand more from nodes. Glamsterdam first attempts to make the workload more parallel, more predictable and more accurately priced.

The new gas schedule can break a small number of contracts

Changing gas costs inevitably affects software that assumed those costs would remain constant.

The Ethereum Foundation replayed historical mainnet transactions under the new schedule to identify incompatibilities.

The vast majority behave normally, but some smart contracts rely on hardcoded assumptions such as fixed gas stipends, presigned gas limits, branches based on gasleft(), or calls that forward a precise amount of gas.

Many affected transactions are fixed simply by allowing a higher gas limit.

A smaller category may require actual contract or application changes before Glamsterdam.

That is one of the reasons Platåberget exists well ahead of mainnet.

Some wallets and indexers have an even simpler problem

The new gas architecture also exposes a common tooling assumption: a single hardcoded maximum gas limit.

The Ethereum Foundation explicitly warns that wallets, indexers and gas estimators relying on that assumption can break and need testing.

There is nothing cryptographically exotic about this failure mode.

It demonstrates why protocol upgrades never affect validator clients alone. Thousands of external services have built shortcuts around historical Ethereum behavior.

Glamsterdam also makes contracts substantially larger

The upgrade increases maximum deployed contract size from 24 KiB to 64 KiB.

Maximum initcode size rises from 48 KiB to 128 KiB.

That provides more room for complex applications and smart-contract architectures that previously had to split logic more aggressively.

The increase arrives alongside stricter state-creation pricing, ensuring that larger persistent code is not treated as a free resource.

The name Glamsterdam actually describes two coordinated upgrades

Like several modern Ethereum forks, Glamsterdam combines a consensus-layer name and an execution-layer name.

Gloas identifies the consensus side and Amsterdam the execution side.

The former carries changes including ePBS, while the latter contains BALs and other EVM-facing work.

The combined name is therefore more informative than it initially appears: post-Merge Ethereum still consists of two major software layers that must evolve together.

Hegotá is already being scoped because some features are deliberately waiting

Ethereum now tries to keep a stricter upgrade cadence after previous forks became overloaded with too many competing features.

The next upgrade, Hegotá, is already being scoped for 2027.

FOCIL, a mechanism aimed at strengthening transaction-inclusion and censorship resistance, is among its central planned changes.

That means Glamsterdam is deliberately not attempting to solve the entire Ethereum roadmap in one release.

Its scope is considered frozen, although developers still warn that proposals can change before mainnet if testing uncovers serious problems.

October 6 matters more than any speculative mainnet date

For now, Ethereum's official schedule says only Q4 2026 for mainnet.

Sepolia is scheduled to fork on October 6.

Hoodi testing and final client validation must follow before the mainnet activation can be treated as settled.

Developers have deliberately avoided locking a mainnet block or timestamp too early.

ePBS changes a sufficiently fundamental portion of block production that a slightly longer testing window costs far less than rushing the fork.

ETH holders do not need to convert anything

As with other major hard forks, Ethereum's documentation emphasizes a point mainly intended to prevent scams.

Existing ETH does not become “Glamsterdam ETH,” and holders do not need to migrate, exchange or send their coins anywhere.

Balances remain part of the network state after the upgrade.

The technical preparation falls primarily on node operators, validators, infrastructure developers and the smaller subset of applications affected by the gas changes.

Glamsterdam is trying to move the limit before pushing against it

Ethereum wants more L1 capacity and more data throughput for rollups.

The easy way would be to ask every node to accept steadily heavier blocks.

Glamsterdam instead attempts to gain propagation time through ePBS, expose dependencies through BALs, parallelize more of the workload and correctly price operations that permanently expand state.

Only after that reorganization does a target around 200 million gas start to look reasonable.

The fork is therefore unlikely to make Ethereum four times faster on the morning it activates.

Its more important goal is architectural: make future capacity increases less tightly coupled to equivalent increases in the minimum machine required to verify the network.