On October 6, 2026, Ethereum takes its next major upgrade out of the lab. The Sepolia testnet forks to “Glamsterdam” at 13:53 UTC — the first public test of a change set that will eventually reach mainnet. It is the largest bundle of execution-layer and consensus-layer changes Ethereum has shipped in some time, and two of them do most of the work.
The first is enshrined proposer-builder separation (ePBS), which moves the block-building market inside the protocol and removes a trusted middleman. The second is block-level access lists (BALs), which let clients read and validate a block’s state in parallel instead of one storage slot at a time. Both target the same bottleneck: Ethereum’s largely sequential path from “propose” to “validate.”
This article explains what Glamsterdam is, how ePBS and BALs actually work, what changes for gas and for node operators, why the upgrade was delayed, and what to watch between the Sepolia fork and mainnet.
Key takeaways
- Glamsterdam combines the Amsterdam execution-layer upgrade with the Gloas consensus-layer upgrade (tracked by meta-EIP 7773) and follows the earlier Fusaka upgrade.
- Its two headline changes are ePBS (EIP-7732) and block-level access lists (EIP-7928).
- Sepolia forks on October 6, 2026 at 13:53 UTC. Hoodi is undated, and mainnet is targeted for Q4 2026 with no confirmed date.
- ePBS extends the payload propagation window from roughly 2 seconds to about 9 seconds; BALs can speed up block validation by up to about 5x on 6-core machines.
- The upgrade has slipped before, and some contracts that hardcode gas assumptions may need changes.
What Glamsterdam is
Glamsterdam is not a single feature but a bundle. It pairs Amsterdam, which carries the execution-layer EIPs, with Gloas, which carries the consensus-layer ones, and it is tracked end to end by a single meta-EIP (7773). It arrives after Fusaka in Ethereum’s roadmap, and it is the first upgrade in years to touch the execution and consensus layers at once.
The two headline components are ePBS and BALs, but the bundle is wider. It also includes gas-pricing changes, a slot-number opcode, ETH transfer logs, a higher maximum contract size, a deterministic factory contract (EIP-7997), and increased validator exit and consolidation churn. Individually these are modest; together they are the kind of change that forces every client team to coordinate.
The upgrade was originally expected in the first half of 2026, then pushed to the fourth quarter. Developers ran a long-lived public devnet — glam-devnet-8, nicknamed Platåberget — from August 17, 2026, to shake out problems before public testnets. The Sepolia date of October 6 replaced an earlier September 28 target and was itself described as provisional, which is the honest way to describe a date in an upgrade this large.
How Ethereum ships an upgrade
It helps to see why an upgrade like this takes a year. Ethereum does not deploy changes to a server it controls; it coordinates a network of thousands of independent node operators and half a dozen client teams, each with its own codebase, who must agree to activate the same changes on the same block.
The path runs through three stages:
- Devnets. A small, long-running test network where the changes are unstable and break often. This is where Glamsterdam spent most of 2026.
- Public testnets. Sepolia first, then Hoodi. These networks exist to be broken in public and to catch interaction bugs that devnets miss.
- Mainnet. Activated only after every client team is confident in the same change, at a specific epoch and slot. There is no partial rollout; the whole network switches at once.
That structure explains the delays. When a change touches both the execution layer and the consensus layer — as Glamsterdam does — a bug in either one stalls the whole upgrade. It also explains why the Ethereum Foundation is explicit that the September announcement “covers Sepolia” and does not schedule a mainnet upgrade: mainnet dates are set by client teams after the testnets hold, not announced in advance.
ePBS: moving block building into the protocol
Today, most Ethereum blocks are built by specialized builders and relayed to proposers through off-protocol middleware — mainly MEV-Boost and relays. That arrangement works, but it inserts a trusted party into a step the protocol does not control. A proposer effectively trusts a relay to hand it a valid, profitable block, and the relay is not part of consensus.
ePBS, defined in EIP-7732, moves that relationship inside the consensus protocol:
- A proposer includes a builder’s commitment to an execution payload in the block.
- The builder later reveals the payload, and the protocol handles payment from the builder to the proposer.
- No relay sits in the middle of a step the protocol now enforces directly.
The practical effect is a longer window for the payload to propagate. ePBS separates consensus validation from execution validation and extends the payload propagation window from roughly two seconds to roughly nine seconds. That extra time reduces the pressure that forces haste — and haste is where a large share of timing-based risk lives.
Failure handling is explicit rather than hoped for. A Payload Timeliness Committee (PTC) attests whether the payload, and its blob data, was revealed on time. If a builder fails to deliver, the slot is recorded as empty, the proposer keeps the bid payment, and the builder forfeits its bid. The design removes the relay’s discretion while keeping the auction that builders compete in — the market still exists, but it is now governed by the protocol instead of by middleware that consensus does not see.
Block-level access lists: parallel reads, parallel validation
The second headline change targets execution itself. In Ethereum today, clients largely discover which accounts and storage slots a transaction touches while they execute it. That is inherently sequential: you cannot validate transactions in parallel if you do not know, in advance, which state each one will read. On a busy block, this single-threaded discovery step is a real ceiling.
EIP-7928 changes it by mandating a block-level access list (BAL). Every block must include a complete record of the accounts and storage locations accessed during execution, plus the post-transaction state diffs. The list is committed through a hash in the block header (the block_access_list_hash), and the full list travels with the block. If the provided list does not match what execution actually touches, the block is invalid — so the optimization cannot be used to lie about what happened.
With the access set known up front, clients can do parallel disk reads, parallel transaction validation, and more efficient state-root computation. Early testing cites up to roughly 5x faster block validation on 6-core machines. Companion changes make it practical to share and sync this data across the network:
- eth/71, a peer-to-peer protocol update for distributing BALs between nodes.
- snap v2, for faster and simpler state synchronization.
- Retention rules — clients must keep BALs for at least the weak-subjectivity period of 3,533 epochs, so peers can request them after the fact.
Read together, ePBS and BALs attack the same problem from two directions. ePBS widens the time available to validate a block; BALs widen the parallelism available to do it. Neither adds a feature a user will see on screen. Both remove a structural ceiling that only shows up under load.
Gas pricing and state growth
Glamsterdam also reworks how gas is priced, in ways that matter more to developers than to end users. EIP-8037 raises the cost of creating state and meters it separately. EIP-8038 updates the cost of accessing state. EIP-2780 touches intrinsic transaction gas and could substantially cut the base cost of a simple ETH transfer. Calldata, access-list, and block gas-accounting rules change as well.
The migration risk is real but bounded. The Ethereum Foundation warns that contracts relying on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes, and testing found a small group of existing contracts could break. This is the kind of change that stays invisible until it does not, and it is why node operators and dapp teams are being asked to test on Sepolia rather than wait for mainnet.
What changes for node operators
For most ETH holders, nothing changes yet. For node operators, the Sepolia fork is a hard deadline to update both execution-layer and consensus-layer clients. The Foundation named Lodestar 1.49.0, Prysm 7.2.0, and Teku 26.9.1 among the confirmed consensus clients for Sepolia.
One detail is easy to miss: Prysm 7.2.0 defaults to a 60 million gas limit after activation. Operators who want to test the higher limits discussed for post-Glamsterdam — a credible 200 million floor, with 300 million as a realistic near-term target and 600 million in longer-term discussion — must set that explicitly through version 2 proposer settings or the key-manager API. The gas limit, ultimately, is chosen by validators, not by the upgrade itself. An upgrade can make a higher limit safe; it cannot make it happen.
There is also a security caveat worth flagging. Developers have pointed to a class of attack where fake builder accounts win auctions but withhold payloads, risking disruption on testnets. The design has a defined response — the slot is simply recorded as empty — but the edge cases are exactly what testnets exist to find. A bug bounty is active on the Glamsterdam specs and EIPs.
The bigger picture: Hegotá and the end of “normal” forks
Glamsterdam matters on its own terms, but it also marks a transition. In a September 27, 2026 essay, Vitalik Buterin described Ethereum’s destination as a “cryptographic world computer” and said the following upgrade, Hegotá (targeted for 2027), may be Ethereum’s last “normal” fork. After that, the roadmap shifts toward recursive STARKs, automated formal verification, a redesigned consensus, and quantum-resistant cryptography.
Read that way, Glamsterdam is one of the last upgrades that looks like the Ethereum of the past decade: a set of incremental EIPs, shipped on a familiar cadence, coordinated across client teams. Separately, a proposed issuance change — EIP-8363, a tapered issuance burn — was withdrawn from Hegotá consideration on October 2, 2026, with ETH monetary policy to be handled through a separate governance track. That split is a preview of how Ethereum’s hardest questions are being moved out of the technical-fork lane and into governance.
Why it matters beyond the technical details
None of this changes what a user sees on October 6. But the changes compound for everything built on top of Ethereum. A higher safe gas limit and faster block validation translate into more room for the data that layer-2 rollups post back to the base chain — the scarce resource those networks price their own fees against. And ePBS removes a class of trusted infrastructure from the critical path, which matters for the decentralization story that institutional adopters increasingly ask about.
For developers, the message is narrower and more concrete: test your gas assumptions. Contracts that hardcode limits, rely on a fixed stipend, or assume a specific amount of remaining gas are the ones most likely to break. Glamsterdam is not a fee cut, and it is not a throughput headline. It is the plumbing that makes later fee cuts and throughput gains possible.
For ETH holders, the near-term signal is simply execution risk. An upgrade this wide either lands cleanly or slips again; the price implication of a clean testnet is modest, but the operational implication for anyone running a node is not. Update clients, watch the gas-limit defaults, and treat “Q4 2026” as a target rather than a date.
What to watch
Three things will tell you whether Glamsterdam is on track:
- Testnet stability after October 6. A clean Sepolia fork that stays final is the signal that Hoodi and mainnet can be scheduled. Repeated reorgs or empty slots would push the date.
- Client readiness and gas-limit defaults. Whether consensus clients ship the versions needed and whether operators raise the gas limit toward the 200M target. The upgrade makes capacity possible; the limit is set by validators.
- The mainnet date. “Q4 2026” is a target, not a schedule. Watch for the Foundation and client teams naming an epoch and slot.
FAQ
Is Glamsterdam live on mainnet?
No. As of early October 2026, Glamsterdam has reached only testnets. Sepolia forks on October 6, 2026 at 13:53 UTC; Hoodi is undated; mainnet is targeted for the fourth quarter of 2026 with no confirmed date.
What do ePBS and BAL stand for?
ePBS is enshrined proposer-builder separation (EIP-7732). BAL is a block-level access list (EIP-7928). The first concerns who builds blocks and how they are paid; the second concerns how fast blocks can be read and validated.
Will Glamsterdam lower gas fees?
Not directly. The upgrade changes how gas is priced and how much creating state costs, and it opens the door to higher block gas limits, but it does not set fees. Fees depend on demand and on the gas limit validators choose.
Do I need to do anything as an ETH holder?
No. The upgrade requires no action from holders. Node operators must update clients before the Sepolia activation, and developers should test contracts that depend on hardcoded gas limits or fixed gas stipends.
How much faster will Ethereum be?
Faster in specific, measurable ways: block validation up to about 5x on 6-core machines, and a payload propagation window extended from roughly 2 seconds to about 9 seconds. Headline throughput gains still depend on the gas limit, which is set separately by validators.
What is Hegotá?
Hegotá is Ethereum’s planned 2027 upgrade. Vitalik Buterin has suggested it may be the network’s last “normal” fork, after which the roadmap turns to recursive STARKs, formal verification, and quantum-resistant cryptography.
Why has Glamsterdam been delayed?
It was originally expected in the first half of 2026 and moved to the fourth quarter. The Sepolia date itself replaced an earlier September 28 target and was described as provisional. The delays reflect the scale of the change: ePBS and BALs touch both the execution and consensus layers at once, so a bug in either layer stalls the whole upgrade.
Is Glamsterdam the same as Fusaka?
No. Fusaka is an earlier upgrade that precedes Glamsterdam in Ethereum’s roadmap. Glamsterdam combines the Amsterdam execution-layer changes with the Gloas consensus-layer changes and is the larger of the two. Where secondary coverage sometimes conflates the two, the primary sources are the Ethereum Foundation’s testnet announcement and the individual EIPs.
Bottom line
Glamsterdam is best understood as a scaling-maintenance upgrade. It adds no feature users will notice on the surface, but it removes two structural ceilings: a trusted middleman in block building, and a sequential execution path that cannot tell, in advance, what a block will touch. If Sepolia holds, mainnet follows in the fourth quarter, and Ethereum will have bought itself room for the more radical work that Hegotá previews. Watch the testnet, the client defaults, and the mainnet date — not the headlines.
Sources
- Ethereum Foundation Blog — Glamsterdam testnet announcement
- EIP-7928 — Block-level access lists
- thirdweb — Ethereum Glamsterdam upgrade: ePBS, BAL, and the 200M gas limit path
- Coinspeaker — Glamsterdam Sepolia test set for October 6
- Yahoo Tech — Ethereum sets Oct. 6 Glamsterdam upgrade as Vitalik signals end of ‘normal’ forks
