Cabinet
Back to Technology Insights
2026.08.20

Glamsterdam's Sepolia Fork Proposed at Epoch 351232 — But the Minutes Say the Decision Was Deferred

Glamsterdam's Sepolia Fork Proposed at Epoch 351232 — But the Minutes Say the Decision Was Deferred

What happened

ACDC (All Core Developers – Consensus) is the standing call where consensus client teams settle timing, bugs and testnet handling between them; minutes and chat transcripts are published in the project's planning repository. The minutes of the 185th call, held 2026-08-20, record under fork status a proposed Sepolia Glamsterdam fork at epoch 351232, slot 11239424, 28 September 2026, with no objections raised. The same line appears again in the target list of the document, there carrying a note that it is pending confirmation at the next ACDC.

The arithmetic can be checked independently. Ethereum's consensus layer runs 32 slots per epoch at 12 seconds per slot. 351,232 × 32 = 11,239,424, matching the quoted slot. Adding slot number × 12 seconds to Sepolia's beacon chain genesis (2022-06-20 22:00:00 UTC) lands exactly on 2026-09-28 14:44:48 UTC — 23:44:48 the same day in Japan. Epoch, slot and timestamp are mutually consistent, so the derivation itself is sound.

For Hoodi, epoch 132352 / slot 4235264 was given for 26 October, and 132,352 × 32 = 4,235,264 checks out as well. Applying the same method from Hoodi's genesis yields 2026-10-26 17:42:48 UTC, but only the date has been reported; the time here is this article's own derivation.

Mainnet still has no date. The target is Q4 2026, having slipped twice from the original first-half-of-2026 goal.

Why two public testnets are needed is worth understanding when reading the schedule. Sepolia runs a permissioned validator set and serves as a comparatively small, controllable environment for checking application and tooling compatibility. Hoodi is intended to resemble production more closely, with a larger validator configuration, and is where staking operations and client diversity get exercised. Because Glamsterdam's headliner, ePBS, involves proposers, builders and validators together, passing on Sepolia leaves part of the surface unverified. The two stages are not redundant; they test different things.

Work also remains ahead of the Sepolia fork. The Ethereum Foundation has said that after the Platåberget feedback period it expects to stand up a dedicated non-finality devnet, roughly a month later, to exercise consensus edge cases. How the network behaves while finality is stalled is hard to reproduce in ordinary testnet operation, and needs checking for a change that alters the proposal path. That devnet's results are the material on which the Sepolia date will be confirmed or moved.

What sits between "proposed" and "confirmed"

This distinction is where technical write-ups most often go wrong. In the ACD process a date is not settled in a single call. Propose, check for objections, confirm at the next call — that sequence exists to give absent teams, and teams without the material to judge on the spot, time to take the question back. "No objections" means nobody dissented in the room, not that everyone actively agreed.

There is a concrete reason the confirmation was held over. Several clients are reported to have stalled or slowed immediately after new builder functionality was activated on Platåberget, which doubles as Glamsterdam devnet-8. ePBS separates, inside the protocol, the party that proposes a block from the party that actually assembles it; the network was reported stable before the activation. The failures therefore appear tied to the ePBS activation itself. The decision to insert an additional devnet before moving to public testnets follows from that observation.

The reading to take away is that 28 September is not a deadline Ethereum will hit at any cost. It is a target that survives only if the next round of testing surfaces nothing worse. From an implementer's standpoint this is the desirable behaviour: pushing unstable code onto a public testnet to protect a date is far more expensive.

Not mixing up the kinds of dates

The most frequent internal-comms error is circulating a testnet activation date as a mainnet activation date. As of 2 September, at least one widely shared calendar listed 28 September as an ETH upgrade date without noting that it is a Sepolia testnet fork.

Four dates need to be kept apart: the proposal date (20 August), the confirmation date (next ACDC, unscheduled), the testnet activation dates (Sepolia proposed 28 September, Hoodi proposed 26 October), and the mainnet activation date (none). Internal work deadlines should hang off the testnet dates. Teams that wait for a mainnet date before starting will not have a validation window.

Pitfalls to watch

First, if 28 September moves, the Hoodi date is not the only thing that moves with it. The Sepolia-to-Hoodi gap is currently designed at just under four weeks, but that gap can stretch depending on the non-finality devnet. A relative deadline like "complete internal work two weeks after Sepolia" ignores that the interval itself is variable.

Second, when epoch and slot are both quoted, the epoch boundary is what actually drives the fork; the slot number is derived. Monitoring scripts that hardcode the slot number multiply the places you have to edit when the schedule shifts. Hold the epoch as configuration and compute the slot.

Third, Sepolia runs a permissioned validator set, while Hoodi is intended to resemble production more closely. Passing on Sepolia does not mean ePBS behaviour has been validated against a large validator set. For staking providers, the meaningful validation is on the Hoodi side.

Fourth, minutes place decisions and discussions side by side in the same document. When quoting, check whether the specific line carries a pending-confirmation note. The Sepolia line here does.

[Technical Insights & Actions]

  1. In the ACD process a date exists in three states — proposed, pending confirmation, confirmed — and from public coverage all three look like the same "date." Pulling dates from secondary articles instead of the minutes drops that state. This is not Ethereum-specific; any protocol with public governance produces the same class of error. [Tech leads / internal comms] When circulating fork schedules internally, tag every date as proposed, confirmed or activated, and link the primary source (the ethereum/pm minutes). Do not treat 28 September as confirmed until the next ACDC result is checked.
  2. That ePBS problems surfaced at the testnet stage indicates the block-proposal path is the most fragile part of cross-client agreement in this fork. Any in-house monitoring or MEV tooling resting on the same assumption — that proposer and builder are the same actor — is likely to break in the same place. [Node operators / staking providers] Without waiting for the Sepolia date to be confirmed, inventory internal block-proposal monitoring and MEV-path tooling during September and begin redesigning around a split proposer/builder model.
  3. Testnet dates are mutable, so hanging internal deadlines off published dates lets the schedule loosen for external reasons. Relative deadlines ("two weeks after Sepolia") also lose meaning once the interval between testnets moves. [Project management] While no mainnet date exists, fix the internal completion deadline as an absolute date (for example end of October 2026) so it is independent of testnet schedule drift.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.

Previous ArticleThree crates.io packages briefly poisoned — a plain cargo build was enough to run remote code, and Rust tooling across Solana and Ethereum sits in the blast radiusNext Article Glamsterdam Forks on the Platåberget Public Testnet — EIP-8037 Breaks the "Transfers Cost 21,000 Gas" Assumption