One Date, Two Blanks: The Chain of Custody of Ethereum’s Next Hardfork

One Number, and Everywhere It Was Written Down

A release schedule is a production artifact, not a press release. The artifact everyone is reading this week is a three-row markdown table inside a governance document called EIP-7773, and the whole story reduces to one integer: 1791294816. That is a Unix timestamp, the second at which the Sepolia test network switches on Ethereum’s next upgrade, Glamsterdam. I have seen many roadmaps announced with a flourish, but this one is a date, and a date is something you can check.

Let me follow that integer through every public artifact where it was written down, in the order the artifacts were made, recording who opened each one and what each document says about the networks that do not have the number. This is the chain of custody of one timestamp, and it is a reading of history, not of the future.

The document that closes this chain is 3,217 characters long, and I read it twice the same day; both times the Hoodi and mainnet cells were empty. I will not take the arithmetic on faith, so I recomputed it. I multiplied 353024 by 32 and got 11296768, exactly the first slot of the claimed epoch. I added 11296768 times 12 to the genesis constant 1655733600 and got 1791294816. I converted that second myself and got Tuesday, 06 October 2026, 13:53:36 UTC. The date is arithmetically correct, and that is the least interesting property a date can have.

The scope behind that date is not small: 18 EIPs scheduled for inclusion, 5 networking EIPs, 2 informational, with headliners like enshrined proposer-builder separation and block-level access lists. In the middle of that, a client team is effectively replacing a consensus layer in place while the chain keeps producing blocks. That is where a schedule stops being marketing and becomes maintenance.

The proposal’s own words say where a date travels. It goes to one testnet repository, then the other, then the meta-EIP. Three hops. Sepolia completed the trip. Hoodi did not begin it.

The Row That Says TBD

The proposal is ethereum/pm#2205, opened on 2026-08-28 by the account parithosh, one of the people listed as an author of the meta-EIP itself. That pairing matters more than it looks: the person who proposes the date also owns the document that has to carry it. Its body lays out the Sepolia arithmetic and then, for Hoodi, writes a row of four cells that all say the same placeholder. It closes with this:

Hoodi and mainnet timings are left TBD. Once agreed, the timings get scheduled in eth-clients/sepolia and eth-clients/hoodi and filled into the EIP-7773 activation table.

ethereum/pm#2205, opened 2026-08-28

Two comments, both dated 2026-09-03, are where the tone changes. One person proposed a later time for Sepolia. The reply is worth quoting in full:

If we move Sepolia, I suggest moving Hoodi as well. Just to have more time for testing and ensure we do not nuke Hoodi like we did with Holesky…

comment on ethereum/pm#2205, 2026-09-03

That sentence is scar tissue. It is not a personality, it is the record of a network broken hard enough that an operator now asks, in public, for more room before the next one is pushed. I cannot claim the comment caused anything; the record never says Hoodi was held back because of a network that was damaged. What it shows is weaker and still worth stating: an experienced operator asked for more testing time on a named network, and that network still has no date. I have unaccented that earlier network’s name everywhere, including inside quotes, for encoding reasons.

The issue stayed open about seventeen and a half days and was merged and closed on 2026-09-15. It went on collecting references after it closed: nineteen referenced events from eight distinct accounts, several of them repeatedly, the last one dated the morning I read it. An interface people keep reaching through is one still being defended, and if nobody owns an interface, nobody defends it. I have written before about how a spec arriving instead of a law moves accountability somewhere the author cannot see.

105 Minutes to Fill a Cell

The document change was fast. ethereum/EIPs#12355, titled to set the Sepolia activation time, opened at 2026-09-17T20:03:18Z and merged at 2026-09-17T21:48:28Z: 105 minutes from open to merged, to fill one row and swap a stale row for Hoodi.

Then compare the other speed. The machine-readable change, eth-clients/sepolia#126, opened the same day and did not land until 2026-09-22, about five days later. Filling a cell in a document took under two hours; changing the constant a client reads at startup took days of review. That ordering is correct. A wrong sentence in a meta-EIP is an erratum. A wrong constant in a config file is a chain that forks at the wrong second. Review time is proportional to blast radius.

One detail there deserves its own essay. The pull request body records the validation: the author states he verified the epoch-to-slot and genesis-to-timestamp arithmetic and the UTC conversion. The proof of the check shipped inside the change. It is not a claim that you should trust him; it is a description of a check you can repeat yourself, which is the only kind of claim worth measuring.

And then, in the same body, the same author writes that Hoodi and mainnet activation times remain undecided. The document that records a date also records the absence of two dates, and neither statement weakens the other. That is not a contradiction; that is a boundary doing its job.

What a Blank Cell Costs

Now the maintenance argument. Eighty percent of the cost of a system is the maintenance that follows it, and a schedule with a hole in it exports that cost downstream. Because there is no mainnet timestamp, every operator has to invent one. The news article everyone is passing around reports a mainnet launch expected in the fourth quarter of 2026, with no official date yet. A quarter is not a timestamp; it is a mood. I found no artifact containing a mainnet second.

Contrast Sepolia, which has two independent records of the same moment: the readable row in the meta-EIP, and the machine-readable constant in the network’s config file, GLOAS_FORK_VERSION 0x90000076 and GLOAS_FORK_EPOCH 353024. When the software boots, it reads the constant, not the EIP. A date in a document is a promise; a date in a config file is a fact. The mainnet metadata repository holds genesis constants and a validator count, with no fork schedule at all. That describes a file; it is not proof that mainnet has no process.

This is where the anti-corruption layer earns its name. The meta-EIP is the boundary between what client teams discussed and what software will act on. A blank cell at that boundary is not a planning failure; it is a boundary not yet crossed, which is the correct behaviour for a boundary. A table that filled itself would be one nobody could trust, because a number that appears without a decision behind it is worse than no number. The note under the table is not a hedge; it is a design statement:

rows in the table above will be filled as activation times are decided by client teams.

EIP-7773 activation table, read 2026-09-29

Read it literally and it specifies the process: the table is completed as a consequence of a decision, not a cause of one. That is the opposite of a press release, which fills the table first and hopes the decision follows. The unit economics of a yield machine only work when the promise and the settlement line up; here they are kept apart until the settlement exists. A claim you cannot measure is a wish, and a blank cell is honesty about an unmeasured thing.

7 Days, 741 Days, and a Polar Bear

Line up the time scales. Sepolia is about 7 days from its fork on the day I read these records. The document carrying that date was created on 2024-09-26, which is 741 days before the activation it describes. On Sepolia, the gap from Pectra to Fusaka was about 223 days, while Fusaka to Glamsterdam is about 357 days. The gaps are lengthening, and I will not pretend that is automatically bad. The alternative to a slow date is a wrong one.

Remember the surface area. Eighteen scheduled EIPs, five networking, two informational is not a patch; it is a small platform release, integrated and cross-tested across client teams that do not share a release train. On the first gate, does it work, this is manageable; on the second gate, does it hold under load, it is most of the work; the third gate, does it behave well on its own, is barely open. A schedule that drifts longer under that load is doing arithmetic, not failing.

Then there is the polar bear. The same meta-EIP lists a mascot, assigned through an informational proposal that sets a community process for choosing one per upgrade. I find it completely reasonable and slightly moving. A mascot costs nothing and buys morale; a date costs everything and buys certainty. The mascot is settled, with a process, an owner, and a file; the mainnet date has none of those. Some things are easy to agree on because they carry no risk, and some are hard because they carry all of it.

The Schedule Is a Production Artifact

So here is my standard. Treat a schedule like any other production artifact: it needs an owner, a review, a machine-readable copy, and a public place where absence is visible. Judge it as you judge a service, on who defends the interface and whether the current state is honest about itself. By that standard, the record I traced does one thing well. It puts a blank cell in a public table, in the same file, beside the date that does exist. A blank cell is more honest than a confident quarter in a press release, because the blank is auditable and the quarter is not. Anyone can look at an empty row. Nobody can look at a mood.

What I would have asked for is modest: the same three-hop path Sepolia’s number travelled, made explicit for mainnet, and an issue opened for it rather than silence. An open issue is a state; an unopened issue is not. I would not ask for a guessed date, because a guessed date is exactly the failure the blank avoids. Public repositories show what was merged, not what was agreed in calls, and the same repository carries the meeting calendar for that decision: ACDC #188 on October 1, 2026 and ACDE #247 on October 8, 2026, both of which I did not read. A date could be agreed in one of those rooms before it appears in any file. This is a one-day snapshot: any of these files can be edited by anyone with write access, so blank means blank when I looked.

That is why an empty cell is not an absence of intent; it is an absence of a merged artifact. The two are different, and conflating them is how people write press releases instead of schedules. I am describing a release process, not predicting a date. I recomputed the arithmetic rather than trust it, and it checked out. What did not exist was a second and a third place to put it.

The number that exists is trustworthy precisely because the two that do not are on the same page, in the same table, in the same file. A date nobody can execute is not a date, and a blank cell beside a real one is how a system tells the truth.