Ethereum Glamsterdam Upgrade: Sepolia Fork Scheduled for 6 October

Ethereum developers have set a preliminary date for activating Glamsterdam on the Sepolia testnet. No mainnet launch date has been set — December remains the target.

In brief: Glamsterdam activation on the Sepolia testnet is preliminarily scheduled for 6 October 2026, 13:53 UTC. No date has been approved for the Ethereum mainnet launch: developers cite December as the target, but the timing depends on test results — on internal devnets the upgrade has not yet shown stable operation. A public testnet for checking smart contracts and applications is planned to open on 22 September.

When Glamsterdam ships: the calendar

Date	Stage	Status
1 September 2026	Devnet-9 launch	The network failed to finalize: too few validators correctly attested to block headers
14 September 2026	Devnet-11	Scheduled; replaced expectations previously built around Devnet-10
22 September 2026	Public testnet for projects and developers	Announced
6 October 2026, 13:53 UTC	Sepolia fork	Preliminary, subject to stable devnets
Tentatively December 2026	Mainnet	No date set

Historically, two to four months pass between a fork on public testnets and mainnet activation. That is exactly why December remains a working target rather than a promise: after Sepolia, a run on at least one more public network and completion of the external audit will be required.

What's in the upgrade

Glamsterdam bundles around ten Ethereum Improvement Proposals (EIPs) collected under the EIP-7773 meta-specification. Core developers call it the most significant protocol change since the transition to Proof-of-Stake. Two key components:

EIP-7732 — Enshrined Proposer-Builder Separation (ePBS), consensus layer. Today, the separation of the "block proposer" and "block builder" roles relies on out-of-protocol infrastructure — primarily MEV-Boost relays. ePBS moves this scheme inside the protocol. The practical meaning: less dependence on a small number of trusted intermediaries, lower risk of transaction censorship, and less burden on the validator, who no longer needs to trust an external relay.

EIP-7928 — Block-Level Access Lists (BAL), execution layer. A block receives a pre-built list of the addresses and storage slots its transactions access. Knowing this list before execution, a client can process unrelated transactions in parallel rather than strictly in sequence. This is the foundation for parallel execution — the basic engineering prerequisite for growing layer-1 throughput.

Beyond these, the package includes several EIPs repricing gas costs (EIP-7778, EIP-7976, EIP-7981, EIP-8037) and EIP-8061, which noticeably shortens the queue for validators exiting staking.

The 200 million gas limit: what it means in practice

The combination of ePBS, BAL and gas repricings is designed with one goal — to safely raise the network's target gas limit to roughly 200 million from the current roughly 60 million, that is, more than threefold. The gas limit is the upper bound on the computational work the network is prepared to perform in a single block. Raising it means more transactions per block and, other things being equal, cheaper fees during periods of load.

A caveat worth keeping in mind: the hard fork itself does not raise the limit. The final value is set by validators through voting on the gas limit parameter, and the protocol changes merely make high values safe — without excessive growth in node hardware requirements or the risk of longer block propagation times.

Why the timeline could slip again

The main reason for the developers' caution is the results of closed testing. Devnet-9, launched on 1 September, failed to reach finality: too few validators correctly attested to block headers — a direct consequence of the complexity of the new ePBS scheme. Testing also revealed bugs at the consensus and execution layers, including a problem in the EIP-8037 implementation.

ForkLog's wording as of 11 September is extremely careful: in internal trials the upgrade has not yet shown stable operation, and the discovery of new serious bugs could lead to a revision of the timeline. That is precisely why the 6 October date for Sepolia remains tentative.

For the industry this is normal dynamics: previous Ethereum upgrades also slipped repeatedly at the devnet stage, and developers consistently choose stability over the calendar.

What's next: Hegota

The hard fork following Glamsterdam is called Hegota. The Ethereum Foundation has already defined two proposals mandatory for inclusion:

FOCIL (EIP-7805) at the consensus layer — a forced transaction inclusion mechanism that strengthens censorship resistance;
Frame Transactions (EIP-8141) at the execution layer — a more flexible account authentication model.

At the same time, the foundation confirmed its long-term goal: making the Ethereum base layer resistant to quantum computer attacks by December 2029. Work on Hegota clients will begin after Glamsterdam goes live on mainnet.

What this means for ETH holders and stakers

Token holders on exchanges and in wallets need to do nothing: the hard fork requires no action from the end user, no rebranding and no token swap.
Node operators and validators will need to update clients to the announced versions by the fork date — first on Sepolia, then on mainnet. Missing the update means dropping off the canonical chain.
Projects and smart contract developers would do well to run their code on the public testnet from 22 September: changes in gas costs and the BAL model affect contracts with intensive storage access.
Stakers should note EIP-8061: a shorter exit queue simplifies managing the liquidity of a position.

The market context for the upgrade remains subdued so far: ether is trading around $2,500 and holding more steadily than bitcoin, while US spot ETH ETFs posted a fourth consecutive week of inflows — $197 million over 8–11 September with assets of $16.3 billion, the highest since January. More on flows in the article "Bitcoin ETFs lose $463 million", and on the market as a whole in the BTC price overview.