Cabinet
Back to Technology Insights
2026.09.03

Glamsterdam's Sepolia Target Moved to October 6 — But the Published Epoch and Timestamp Do Not Agree, So Check the Arithmetic Yourself

Glamsterdam's Sepolia Target Moved to October 6 — But the Published Epoch and Timestamp Do Not Agree, So Check the Arithmetic Yourself

What happened

Glamsterdam, headlined by ePBS (EIP-7732) and Block-Level Access Lists (EIP-7928), is Ethereum's largest upgrade since the Merge. Sepolia is the first public testnet to take it, and the schedule has been discussed in two rounds.

The minutes of All Core Developers Consensus (ACDC) #185 on 2026-08-20 record a proposed Sepolia activation at epoch 351232, slot 11,239,424, on 2026-09-28, with no objections raised and the decision deferred to the next call. At ACDC #186 on 2026-09-03, participants were reported to have settled on epoch 351232 as the proposed activation. The corresponding time given at that point, however, was 2026-10-06 13:53 UTC, reported via a summary from Ethereum protocol researcher Christine D. Kim.

As of 2026-09-10, Kim noted that the caveats around the date still hold and that attention has shifted to Glam-Devnet-11, launching 2026-09-14, rather than Devnet-10. Reporting puts Devnet-11 at roughly 84,000 validators with its Gloas fork planned two days after launch. No activation dates are confirmed for the Hoodi testnet or mainnet; a possible December mainnet activation has only been discussed.

Checking the published numbers

Sepolia's beacon chain genesis is UNIX time 1655733600, that is 2022-06-20 14:00:00 UTC. Slots are 12 seconds and an epoch is 32 slots, so epoch n begins at genesis plus 384n seconds.

Running epoch 351232 through that: the start slot is 351232 × 32 = 11,239,424, matching the slot number in the ACDC #185 minutes, and the start time is 2026-09-28 14:44:48 UTC, matching the originally proposed date and time exactly. The ACDC #185 record is internally consistent.

The problem is 2026-10-06 13:53 UTC. Inverting the same formula places that timestamp at epoch 353023.9 — not on an epoch boundary. Forks are not scheduled off epoch boundaries, so the pairing cannot hold as stated. The boundary at the same time of day is epoch 353032 (2026-10-06 14:44:48 UTC), exactly 1,800 epochs — eight days — after 351232.

So either the epoch number or the timestamp being reported is wrong. The most natural reading is that ACDC #186 pushed the epoch back by 1,800 (likely to 353032) and the reporting carried the epoch number forward from #185 unchanged. That cannot be asserted with confidence, but what can be asserted is that dropping both published numbers into a calendar risks an eight-day error. Anyone scheduling work should read the fork epoch from the Ethereum PM minutes and the client release notes, not from press coverage.

None of this is specialised work. It needs three constants for the network in question: beacon genesis time, slot duration and slots per epoch. Sepolia is 1655733600 / 12 seconds / 32 slots; Hoodi has a different genesis with the same slot structure, as does mainnet. Any team that handles fork schedules can keep those three values and a short script that turns an epoch number into a timestamp, and stop being exposed to transcription errors in coverage. Put the other way round: a team that does not run this check is betting its operations on the accuracy of somebody else's summary.

What is stuck on devnet

The reason the date keeps moving is straightforward: Glamsterdam has yet to activate stably on any private devnet. Reporting indicates that recent devnet testing surfaced bugs on both the consensus and execution layers, one of them an implementation issue connected with EIP-8037 code. EIP-8037 relates to Glamsterdam's gas model changes and touches the intrinsic gas cap. A change to execution-layer pricing hitting trouble on devnet is unsurprising in itself, but it means the precondition for moving to a public testnet has not been met.

The shift of attention from Devnet-10 to Devnet-11 is itself information. Devnet numbers advance either because the previous network did not demonstrate stability or because fixes were redirected to a fresh network. While the answer to "what are we watching" remains "the next devnet," the Sepolia date is a candidate and nothing more.

Pitfalls to watch

First, a source that quotes both an epoch and a timestamp is not necessarily quoting a consistent pair. The epoch often comes from minutes and the time from a summary, transcribed separately. When distributing fork schedules internally, treat the epoch number as the primary datum and compute the time yourself: genesis + 384 × epoch, with Sepolia genesis at 1655733600.

Second, a Sepolia date does not produce a mainnet date. Past forks have taken two to four months from public testnet to mainnet. A December mainnet activation has been discussed, but that is not a decision, and the caveat that results will determine it is explicit.

Third, Sepolia is a validation environment, not a copy of mainnet. Validator counts and composition differ, and Devnet-11's roughly 84,000 validators is small next to mainnet. No problems on Sepolia does not imply no problems on mainnet.

Fourth, build for the date moving. Teams that reserved internal capacity around 2026-09-28 have already absorbed one change. Anchoring fork work to the confirmation of an epoch number and to client releases, rather than to a calendar date, survives that kind of change.

[Technical Insights & Actions]

  1. A fork schedule exists in two representations — epoch number and wall-clock time — and only one of them may get updated as information propagates. The epoch is the specification-level value; the time is derived. Treating the derived value as primary introduces errors measured in days. [Node operators / integrators] From this week, distribute fork schedules by transcribing only the epoch number from primary sources and attaching a timestamp you computed yourself as genesis + 384 × epoch.
  2. Glamsterdam has not run stably on a private devnet, so the public testnet date is a target rather than a commitment. With a gas-pricing change like EIP-8037 still causing trouble, rescoping — dropping EIPs — remains on the table. [Product / technical planning] Keep internal plans that depend on Glamsterdam features free of firm dates until the Sepolia activation resolves, and name Devnet-11's outcome as the next checkpoint.
  3. Success on a testnet is success at a different scale. Validator counts, client distribution and load characteristics all differ from mainnet, so testnet results bound expectations rather than guarantee them. [Validator operations] Rewrite the policy of completing client upgrades two weeks before mainnet activation so that the countdown starts from epoch confirmation rather than from a calendar date.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice. The observation about epoch/timestamp consistency is computed here from Sepolia beacon genesis 1655733600, 12-second slots and 32 slots per epoch.

Previous ArticleThe Ethereum Foundation Graded All 62 Hegotá EIPs in a Single Tier List, With FOCIL (EIP-7805) the Only Unanimous SNext Article Base plans native account abstraction in Cobalt — EIP-8130 drops bundlers and EntryPoint, cutting USDC transfer gas 63.2% against ERC-4337