Glamsterdam has a date for the first time. On September 28, 2026 at 14:44:48 UTC, the next major upgrade to Ethereum is due to activate on the Sepolia test network. The number comes from the
Glamsterdam has a date for the first time. On September 28, 2026 at 14:44:48 UTC, the next major upgrade to Ethereum is due to activate on the Sepolia test network. The number comes from the minutes of the developer call held on August 20, 2026, it is pinned down to the exact epoch and slot, and six client teams confirmed it in the session chat without dissent.
Two qualifications belong in the same breath, otherwise a schedule turns into a promise. First, the date is provisional: the minutes note explicitly that the decision was deferred to the next call. Second, it applies to a test network and nowhere near a main network. There is still no date for mainnet, and the figures circulating online for it have not added up since August 20.
This piece shows you where the date comes from, how to recalculate it yourself, what could still overturn it and what changes for you as an ETH holder. The background to the content itself, meaning which changes Glamsterdam actually contains and how the selection for the following upgrade works, sits in our piece Ethereum upgrade after Glamsterdam: what is actually decided in Hegotá. This one is about the calendar.
Ethereum's core developers coordinate their upgrades in public video conferences, the All Core Devs Calls. An ACDC call is the consensus layer version of these, meaning the round in which the consensus client teams settle timing, bugs and test networks between them. The calls are minuted, and both the minutes and the chat transcript are subsequently published in the project's planning repository.
The sentence at issue sits in the minutes of call ACDC #185 of August 20, 2026. Under the fork status heading, the note reads: Sepolia Glamsterdam fork proposed: epoch 351232, slot 11239424, Sep 28 2026 — no objections raised; decision deferred to next ACDC. The same line appears a second time in the target list of the same document, there with the addition pending confirmation at next ACDC.
The chat transcript lets you follow the moment minute by minute. At 27:50, Parithosh Jayanthi, who runs test network coordination at the Ethereum Foundation, writes the full values into the chat: Sepolia: epoch 351232, slot 11239424, unix (1790606688), Mon 28 Sep 2026, 14:44:48. Over the following 60 seconds, six participants acknowledge the message with a ship emoji, the customary sign of assent in these rounds: the representatives of Lodestar, ethrex, Lighthouse, Nethermind, Teku and Prysm. Shortly afterwards, Barnabas Busa records how that is to be read: also no objection = agreement.
That sets this number apart from the dates that otherwise travel through the coverage. It is not an observer's estimate and not one team's wish list, but a proposal from the coordination side that the client teams did not contradict on the record. That still does not make it binding.
A slot is the fixed twelve-second window in which exactly one block can be proposed on Ethereum. An epoch is a bundle of 32 such slots, so a window of six minutes and 24 seconds. Upgrades hang on the start of an epoch, not on a time in the calendar. That is why the minutes always carry three numbers side by side.
You can follow the arithmetic behind it in two steps. The slot number is the epoch number times 32: 351,232 times 32 gives 11,239,424, and that is exactly the figure in the minutes. The timestamp follows from the start of the Sepolia beacon chain plus twelve seconds per slot. The result is the Unix value 1,790,606,688, which corresponds to Monday, September 28, 2026 at 14:44:48 UTC. In German summer time that would be 16:44:48.
In practice this means one thing that headlines routinely lose: the clock time is a derived value, not an appointment. It only holds for as long as the network produces its blocks on schedule. If blocks fail to appear, the real activation slips later without anyone having changed the date.
A hard fork is a change to the protocol rules that is not backwards compatible: software that does not take the update no longer follows the chain afterwards. Because a mistake here would be expensive, every change is rolled out in stages. First on internal test networks, then on public test networks, last on the main network.
A test network is a chain of its own running the same software but with worthless tokens. Sepolia is the test network on which application developers check their contracts; Hoodi is the newer network, intended above all for validator and staking infrastructure. Both got their own line in the call.
For Hoodi, the same source gave epoch 132352, slot 4,235,264 and the Unix value 1,793,036,568, meaning Monday, October 26, 2026 at 17:42:48 UTC. That line stands on weaker ground than the Sepolia line, however: the minutes attach the qualifier contingent on stable DevNets, and in the chat the Lighthouse representative kingy_sigp replies with the sentence that date is fine with us provided we get a stable devnet ofc.
For mainnet, by contrast, the minutes contain not a single line. Neither the decisions nor the target list carries a date for the main network. Anyone reading a mainnet figure today is reading a projection with no decision behind it.
A DevNet is a short-lived test network that the developers set up specifically for one upgrade stage, often for only a few days. Six hours before the call of August 20, the Gloas stage was activated on DevNet 8, and something went wrong in the process.
The minutes record the event and its cause in one sentence: the activation triggered non-finality, finalisation had only just recovered by the time of the call, and the reason given is a caching bug affecting builder deposits at the fork transition. Three consensus clients were affected: Lighthouse, Prysm and Teku.
A client is the software with which a node takes part in the network. Ethereum is deliberately implemented in parallel by several independent teams so that a bug in one piece of software does not take the whole network with it. That is precisely the structure that worked here: the bug hit three implementations, the network came back, and countermeasures were already on the table during the call.
The minutes name two of them concretely. At Lodestar, an optimisation of deposit pre-processing cut the duration of the fork transition from around 20 seconds to roughly 500 milliseconds; the change is already in the main branch. At Prysm, the builder deposit cache was removed from the branch ahead of the fork, and an additional optimisation shortens recovery to a single slot even without the cache.
Finality describes the state in which a block counts as settled and could only be reversed at the cost of substantial stake. If it lapses, the chain does keep running and producing blocks, but none of it is closed out. For an exchange, a bridge or a staking protocol this is the single most awkward state there is, because there is no safe way to say which version holds.
The chat contains an argument about exactly this judgement, and the argument is worth reading because it separates two perspectives cleanly. Barnabas Busa argues from the protocol's point of view: we might have unfinality on mainnet too. Why would this be an issue? We had no consensus issues. Dima Gusakov from the staking provider Lido answers from the operator's point of view, saying his team could not check how its oracles and tools come through a hard fork precisely because finality was lost.
How seriously the condition is taken in principle shows in a remark from the same Barnabas Busa later in the call: I think its also safe to say if we have 4-5 months non finality its game over. The comment referred to an entirely different proposal on data retention, but it marks the order of magnitude in which people are thinking here.
Before the test network comes the test network's test network: only once the short-lived DevNets run through stably do the dates for Sepolia and Hoodi move closer. The date stands without formal objection, but not without conditions. Two operators registered requirements explicitly during the call, and both are minuted by name.
Lido, according to Dima Gusakov, needs at least one day and preferably two on a stable DevNet in order to check oracles and tools ahead of the Glamsterdam activation. Optimism, through Chris Berry, asked for a comparable window and spelled it out in the chat: We can do 1-2 days if we know. Added to that was a request to announce the DevNet fork a week in advance so that validators are online in time.
Gusakov gets more explicit on the date itself. Shortly after the Hoodi line he writes into the chat: I would rather have both dates a bit later. Like a week or so to have more room for the pending devnets testing. Two further participants, Miguel Tenorio and Chris Berry, marked that message with a sign of agreement. It is not a veto and it did not stop the proposal, but it is the one documented voice holding September 28 to be too early.
Anyone wanting to place the date now has both sides together. In favour of it are six approvals from the client teams and the finding in the minutes that no objection was raised. Against it is the fact that the network's largest staking operator would like more buffer and that the Hoodi line is expressly tied to stable DevNets.
The decisive wording in the minutes is the half-sentence decision deferred to next ACDC. That makes September 28 a target still to be voted on. The real question is therefore: when does this target become a decision?
These calls run on a two-week cycle. Call #184 took place on August 6, call #185 on August 20. The next one is therefore September 3, 2026. Until then the date remains a proposal with broad support; after that it is either confirmed, pushed back or split up.
For you as a reader this has a practical use. If you read somewhere between September 3 and September 5 that Glamsterdam now has a date, that is the confirmation of this proposal and not news. If a date other than September 28 appears there, something was moved in the call, and then it is worth looking into the minutes.
English-language schedule aggregators have been carrying three figures for Glamsterdam for weeks: Sepolia on September 21, Hoodi on October 5 and mainnet on November 4, 2026. On the pages in question these entries are mostly flagged as projections from earlier targets and carry no decision.
As of August 20, all three are out of date. The Sepolia figure has moved back by a week, the Hoodi figure by three weeks. And a mainnet fork on November 4 would fall only nine days after the Hoodi fork on October 26. On Ethereum, several weeks usually separate the second public test network from the main network, weeks in which the activation is observed and evaluated. Nine days would be unusually tight for that step.
The German-language reports from mid-August, for their part, still stand at the state of play from before the call. There, Glamsterdam is an upgrade pushed into the fourth quarter of 2026 and running behind. That was correct up to August 19 and has been incomplete since, because the test network lines are missing. If you find yourself lining up decisions against a date you picked out of a headline, it is worth checking against the source. Anyone comparing providers anyway will find the current terms in our comparison of the best crypto exchanges.
An EIP is an Ethereum Improvement Proposal, the formal proposal for a single technical change. Which EIPs make it into an upgrade is decided by the core developers in exactly these calls, and the list stays movable until shortly before activation.
In the call of August 20, a participant asked about the status of EIP-7610, which had dropped out of the Glamsterdam scope: whether it was postponed or cancelled outright. The answer from EIP editor Jochem Brouwer in the chat is unambiguous: To answer explicitly, cancelled. I will also ask authors to formally withdraw this EIP. The minutes carry the same point under the decisions and give the reason: EIP-7610 is superseded by EIP-8253, and that one targets Hegotá, the upgrade after Glamsterdam.
The difference between postponed and cancelled sounds academic but has consequences for the schedule. A postponed EIP shows up on the same list again in the next round. A cancelled one is done with, and another proposal with different content takes its place.
While Glamsterdam heads towards the test networks, the selection for the following upgrade began in the same call. According to the minutes, two proposals count as provisionally scheduled: EIP-833, which fixes an off-by-one error in the calculation of checkpoint roots and improves the accuracy of target votes, and EIP-8379, which is meant to make the consensus client the sole sync source and thereby cut duplicated block propagation.
A third proposal, EIP-12188 on shortening the retention window for consensus blocks, ended up neither on the list nor in the bin: it went back into research discussion. On this the minutes record that one participant questioned the motivation and another showed guarded openness.
More interesting for the schedule is the organisational decision alongside it. All client teams are to publish a first assessment of the Hegotá proposals by mid-September, in four tiers from S to D. Barnabas Busa defined the tiers in the chat: S stands for a strong recommendation to include, A for a recommendation once open points are settled, B for a stretch goal and D for a rejection. By DevCon this is meant to become a rough consensus on the scope.
A fork opens when a particular epoch is reached. The clock time in the reports is only the conversion of that epoch. The short answer: nothing. September 28 concerns Sepolia, and Sepolia is a test network. The ETH used there has no market value, it is handed out free through faucets and cannot be exchanged for real ETH. A fork on Sepolia touches neither your balance nor your addresses nor your tax position.
There is also no snapshot, no swap and no new token in this upgrade. Glamsterdam is a protocol upgrade of the existing chain, not a chain split and not a migration. Anyone telling you otherwise is selling you something.
That is exactly what the most common scam around fork dates aims at. After every date announcement, messages appear urging action: a supposed wallet migration, a form to unlock something, a deadline. The rule against it is simple and admits no exception: an Ethereum upgrade never asks you to enter your seed phrase, move funds or verify an account.
A hard fork creates a need to act in one place only, namely among those who run software themselves. The circle is manageable.
Then you have to update your client software to a version that knows the new rules before activation. For the test networks that applies from the respective date, for mainnet later. Anyone who misses it no longer follows the chain after the fork. The DevNet experience of August 20 also shows that it pays to take not the very first version but the one in which the transition bugs have already been fixed.
Then the provider handles the update, and that is precisely why Lido asked for a testing window in the call. What remains for you is to know in advance who your provider is and how it communicates. A provider that stays silent about upgrades will not be any more forthcoming at the next disruption.
Then nothing falls to you. The exchange updates its own nodes, wallets without a node of their own follow automatically. Experience shows that individual exchanges suspend deposits and withdrawals for a few hours around large mainnet forks. That is routine, it is announced in advance, and it does not affect test network forks in any case.
You are not dependent on any headline. The core developers' documents are public, and the route to them is the same one this piece took.
The session artefacts sit in the project's planning repository, sorted by date. For the call of August 20, 2026 that means two files: the summary with decisions and targets and the full chat transcript. In the first you find the lines on fork status, decisions and targets; in the second the timestamps, the numbers verbatim and the teams' reactions to them.
The conversion you do yourself. Multiply the epoch number by 32 and you have the slot. Multiply the slot by twelve seconds and add the start time of the chain in question, and you have the Unix timestamp. If your result matches the stated time, the number is internally consistent. If it deviates, someone copied it without doing the arithmetic.
For an overview of how individual proposals are rated, the project additionally runs a public ranking tool that was referred to explicitly in the call. From mid-September you can read there how the client teams classify the Hegotá proposals.
September 28, 2026 is the first solid Glamsterdam date there is. It applies to a test network, it stands subject to confirmation on September 3, and it says nothing yet about the main network. Keep that in mind and the coming weeks read a good deal more calmly than the market does.
(As of August 21, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
