Glamsterdam-Termin steht: Ethereum forkt Sepolia am 28. September 2026

Glamsterdam hat zum ersten Mal ein Datum. Am 28. September 2026 um 14:44:48 UTC soll das nächste große Upgrade von Ethereum auf dem Testnetz Sepolia aktiviert werden. Die Zahl stammt aus dem Protokoll des Entwicklertreffens vom 20. August 2026, sie ist auf Epoche und Slot genau festgelegt, und sechs Client-Teams haben sie im Sitzungschat ohne Gegenrede bestätigt.

Zwei Einschränkungen gehören im selben Atemzug dazu, sonst wird aus einem Fahrplan ein Versprechen. Erstens steht der Termin unter Vorbehalt: Das Protokoll vermerkt ausdrücklich, dass die Entscheidung auf den nächsten Call vertagt wurde. Zweitens betrifft er ein Testnetz und noch lange kein Hauptnetz. Für das Mainnet gibt es weiterhin kein Datum, und die Zahlen, die dazu im Netz kursieren, passen seit dem 20. August rechnerisch nicht mehr zusammen.

Dieser Text zeigt dir, woher der Termin kommt, wie du ihn selbst nachrechnest, was ihn noch kippen kann und was sich für dich als ETH-Halter dadurch ändert. Die inhaltliche Vorgeschichte, also welche Änderungen in Glamsterdam überhaupt stecken und wie die Auswahl für das darauffolgende Upgrade läuft, steht in unserem Text Ethereum-Upgrade nach Glamsterdam: Was in Hegotá wirklich beschlossen ist. Hier geht es um den Kalender.

Wann kommt Glamsterdam? Der erste Termin steht im Protokoll der Kernentwickler

Die Ethereum-Kernentwickler stimmen ihre Upgrades in öffentlichen Videokonferenzen ab, den All Core Devs Calls. Ein ACDC-Call ist die Consensus-Layer-Variante davon, also die Runde, in der sich die Teams der Konsens-Clients über Zeitplan, Fehler und Testnetze verständigen. Diese Calls werden protokolliert, und Protokoll wie Chatmitschrift landen anschließend öffentlich im Planungs-Repository des Projekts.

Im Protokoll des Calls ACDC #185 vom 20. August 2026 steht der Satz, um den es geht. Unter der Rubrik Fork-Status ist vermerkt: Sepolia Glamsterdam fork proposed: epoch 351232, slot 11239424, Sep 28 2026 — no objections raised; decision deferred to next ACDC. In der Zielliste desselben Dokuments taucht die Zeile ein zweites Mal auf, dort mit dem Zusatz pending confirmation at next ACDC.

In der Chatmitschrift lässt sich der Moment auf die Minute nachlesen. Bei Minute 27:50 schreibt Parithosh Jayanthi, der bei der Ethereum Foundation die Testnetz-Koordination verantwortet, die vollständigen Werte in den Chat: Sepolia: epoch 351232, slot 11239424, unix (1790606688), Mon 28 Sep 2026, 14:44:48. In den folgenden 60 Sekunden quittieren sechs Teilnehmer die Nachricht mit einem Schiffs-Emoji, dem in diesen Runden üblichen Zeichen für Zustimmung: die Vertreter von Lodestar, ethrex, Lighthouse, Nethermind, Teku und Prysm. Kurz darauf hält Barnabas Busa fest, wie das zu lesen ist: also no objection = agreement.

Damit unterscheidet sich diese Zahl von den Terminen, die sonst durch die Berichterstattung wandern. Es ist keine Schätzung eines Beobachters und kein Wunschdatum eines einzelnen Teams, sondern ein Vorschlag der Koordination, dem die Client-Teams im Protokoll nicht widersprochen haben. Verbindlich ist er deshalb trotzdem noch nicht.

Was Epoche, Slot und Unix-Zeitstempel über den Sepolia-Fork aussagen

Ein Slot ist das feste Zeitfenster von zwölf Sekunden, in dem auf Ethereum genau ein Block vorgeschlagen werden kann. Eine Epoche ist ein Paket aus 32 solchen Slots, also ein Fenster von sechs Minuten und 24 Sekunden. Upgrades hängen am Beginn einer Epoche, nicht an einer Uhrzeit im Kalender. Das ist der Grund, warum in den Protokollen immer drei Zahlen nebeneinanderstehen.

Die Rechnung dahinter kannst du in zwei Schritten nachvollziehen. Die Slot-Nummer ist die Epochennummer mal 32: 351.232 mal 32 ergibt 11.239.424, und genau diese Zahl steht im Protokoll. Der Zeitstempel ergibt sich aus dem Startzeitpunkt der Sepolia-Beacon-Chain plus zwölf Sekunden je Slot. Das Ergebnis ist der Unix-Wert 1.790.606.688, und der entspricht Montag, dem 28. September 2026, um 14:44:48 UTC. In deutscher Sommerzeit wären das 16:44:48 Uhr.

Praktisch bedeutet das eine Sache, die in Schlagzeilen regelmäßig untergeht: Die Uhrzeit ist ein abgeleiteter Wert und keine Verabredung. Der Zeitpunkt hält nur, solange das Netz seine Blöcke im Takt produziert. Bleiben Blöcke aus, verschiebt sich die reale Aktivierung nach hinten, ohne dass jemand den Termin geändert hätte.

Sepolia, Hoodi, Mainnet: Warum ein Hardfork dreimal stattfindet

Ein Hardfork ist eine Regeländerung am Protokoll, die nicht rückwärtskompatibel ist: Software, die das Update nicht mitmacht, folgt der Kette danach nicht mehr. Weil ein Fehler an dieser Stelle teuer wäre, wird jede Änderung gestaffelt ausgerollt. Zuerst auf internen Testnetzen, dann auf öffentlichen Testnetzen, zuletzt auf dem Hauptnetz.

Ein Testnetz ist eine eigenständige Kette mit derselben Software, aber wertlosen Token. Sepolia ist das Testnetz, auf dem Anwendungsentwickler ihre Verträge prüfen; Hoodi ist das jüngere Netz, das vor allem für Validator- und Staking-Infrastruktur gedacht ist. Beide haben im Call ihre Zeile bekommen.

Für Hoodi nannte dieselbe Quelle Epoche 132352, Slot 4.235.264 und den Unix-Wert 1.793.036.568, also Montag, den 26. Oktober 2026, um 17:42:48 UTC. Diese Zeile steht allerdings schwächer da als die Sepolia-Zeile: Das Protokoll versieht sie mit dem Zusatz contingent on stable DevNets, und im Chat antwortet der Lighthouse-Vertreter kingy_sigp darauf mit dem Satz that date is fine with us provided we get a stable devnet ofc.

Für das Mainnet enthält das Protokoll dagegen keine einzige Zeile. Weder in den Beschlüssen noch in der Zielliste taucht ein Datum für das Hauptnetz auf. Wer heute eine Mainnet-Zahl liest, liest eine Hochrechnung ohne Beschluss dahinter.

Der DevNet-8-Ausfall: Ein Caching-Fehler bei Builder-Deposits kippte die Finalität

Ein DevNet ist ein kurzlebiges Testnetz, das die Entwickler eigens für eine Upgrade-Stufe aufsetzen, oft nur für wenige Tage. Sechs Stunden vor dem Call vom 20. August wurde auf DevNet 8 die Gloas-Stufe aktiviert, und dabei ging etwas schief.

Das Protokoll hält Vorgang und Ursache in einem Satz fest: Die Aktivierung löste non-finality aus, die Finalisierung hatte sich zum Zeitpunkt des Calls gerade erst erholt, und als Grund ist ein Caching-Fehler bei Builder-Deposits am Fork-Übergang benannt. Betroffen waren drei Konsens-Clients: Lighthouse, Prysm und Teku.

Ein Client ist die Software, mit der ein Knoten am Netz teilnimmt. Ethereum wird bewusst von mehreren unabhängigen Teams parallel implementiert, damit ein Fehler in einer Software das ganze Netz nicht mitnimmt. Genau dieser Aufbau hat hier funktioniert: Der Fehler traf drei Implementierungen, das Netz kam zurück, und im Call standen bereits Gegenmaßnahmen auf dem Tisch.

Zwei davon nennt das Protokoll konkret. Bei Lodestar hat eine Optimierung der Deposit-Vorverarbeitung die Dauer des Fork-Übergangs von rund 20 Sekunden auf etwa 500 Millisekunden gedrückt; die Änderung liegt bereits im Hauptzweig. Bei Prysm wurde der Builder-Deposit-Cache vor dem Fork aus dem Zweig entfernt, und eine zusätzliche Optimierung verkürzt die Erholung selbst ohne Cache auf einen einzigen Slot.

Was Finalität bedeutet und warum ihr Ausfall den Fahrplan bremst

Finalität bezeichnet den Zustand, in dem ein Block als endgültig gilt und nur noch unter Verlust erheblicher Einsätze rückgängig gemacht werden könnte. Fällt sie aus, läuft die Kette zwar weiter und produziert Blöcke, aber nichts davon ist abgeschlossen. Für eine Börse, eine Brücke oder ein Staking-Protokoll ist das der unangenehmste Zustand überhaupt, weil sich nicht sicher sagen lässt, welcher Stand gilt.

Im Chat wird um genau diese Einschätzung gestritten, und der Streit ist lesenswert, weil er zwei Perspektiven sauber trennt. Barnabas Busa argumentiert aus Sicht des Protokolls: we might have unfinality on mainnet too. Why would this be an issue? We had no consensus issues. Dima Gusakov vom Staking-Anbieter Lido antwortet aus Sicht des Betreibers, dass sein Team wegen des Finalitätsverlusts eben nicht prüfen konnte, wie seine Oracles und Werkzeuge durch einen Hardfork kommen.

Wie ernst der Zustand grundsätzlich genommen wird, zeigt eine Bemerkung desselben Barnabas Busa später im Call: I think its also safe to say if we have 4-5 months non finality its game over. Die Aussage bezog sich auf einen ganz anderen Vorschlag zur Datenhaltung, sie markiert aber die Größenordnung, in der hier gedacht wird.

Lido und Optimism verlangen ein Testfenster, und das ist der einzige benannte Widerspruch

Der Termin steht ohne förmlichen Einspruch da, aber nicht ohne Vorbehalte. Zwei Betreiber haben im Call ausdrücklich Bedingungen angemeldet, und beide sind namentlich protokolliert.

Lido braucht nach Angaben von Dima Gusakov mindestens einen Tag, lieber zwei, auf einem stabilen DevNet, um Oracles und Werkzeuge vor der Glamsterdam-Aktivierung zu prüfen. Optimism hat durch Chris Berry ein vergleichbares Fenster angefragt und im Chat präzisiert: We can do 1-2 days if we know. Dazu kam die Bitte, den Fork auf dem DevNet mit einer Woche Vorlauf anzukündigen, damit Validatoren rechtzeitig online sind.

Deutlicher wird Gusakov beim Termin selbst. Kurz nach der Hoodi-Zeile schreibt er in den Chat: I would rather have both dates a bit later. Like a week or so to have more room for the pending devnets testing. Zwei weitere Teilnehmer, Miguel Tenorio und Chris Berry, haben diese Nachricht mit einem Zustimmungszeichen versehen. Das ist kein Veto und hat den Vorschlag auch nicht gestoppt, aber es ist die eine dokumentierte Stimme, die den 28. September für zu früh hält.

Wer den Termin einordnen will, hat damit beide Seiten beisammen. Für den Termin sprechen sechs Zustimmungen der Client-Teams und die Feststellung im Protokoll, dass kein Einwand erhoben wurde. Dagegen spricht, dass der größte Staking-Betreiber des Netzes mehr Puffer möchte und die Hoodi-Zeile ausdrücklich an stabile DevNets gekoppelt ist.

Der 3. September ist der Termin hinter dem Termin: ACDC-Call #186 entscheidet

Die entscheidende Formulierung im Protokoll ist der Halbsatz decision deferred to next ACDC. Der 28. September ist damit ein Ziel, über das noch abgestimmt werden muss. Die eigentliche Frage lautet deshalb: Wann wird aus diesem Ziel ein Beschluss?

Diese Calls laufen im Zwei-Wochen-Takt. Call #184 fand am 6. August statt, Call #185 am 20. August. Der nächste ist damit der 3. September 2026. Bis dahin bleibt der Termin ein Vorschlag mit breiter Zustimmung; danach ist er entweder bestätigt, nach hinten geschoben oder aufgeteilt.

Für dich als Leser hat das einen praktischen Nutzen. Wenn du zwischen dem 3. und dem 5. September irgendwo liest, Glamsterdam habe jetzt ein Datum, dann ist das die Bestätigung dieses Vorschlags und keine Neuigkeit. Steht dort dagegen ein anderes Datum als der 28. September, ist im Call etwas verschoben worden, und dann lohnt sich der Blick ins Protokoll.

Warum kursierende Mainnet-Termine wie der 4. November rechnerisch nicht mehr passen

Fahrplan-Aggregatoren im englischsprachigen Raum führen für Glamsterdam seit Wochen drei Zahlen: Sepolia am 21. September, Hoodi am 5. Oktober und das Mainnet am 4. November 2026. Diese Angaben sind auf den betreffenden Seiten meist als Projektion aus früheren Zielvorgaben gekennzeichnet und tragen keinen Beschluss.

Mit dem Stand vom 20. August sind alle drei überholt. Die Sepolia-Zahl hat sich um eine Woche nach hinten bewegt, die Hoodi-Zahl um drei Wochen. Und ein Mainnet-Fork am 4. November läge nur neun Tage nach dem Hoodi-Fork am 26. Oktober. Zwischen dem zweiten öffentlichen Testnetz und dem Hauptnetz liegen bei Ethereum üblicherweise mehrere Wochen, in denen die Aktivierung beobachtet und ausgewertet wird. Neun Tage wären für diesen Schritt ungewöhnlich knapp.

Die deutschsprachigen Meldungen von Mitte August stehen ihrerseits noch auf dem Stand von vor dem Call. Dort ist Glamsterdam ein Upgrade, das auf das vierte Quartal 2026 verschoben wurde und im Verzug ist. Das war bis zum 19. August korrekt und ist seither unvollständig, weil die Testnetz-Zeilen fehlen. Wenn du in dieser Lage Entscheidungen an einem Termin ausrichtest, den du in einer Schlagzeile gefunden hast, lohnt sich die Gegenprobe an der Quelle. Wer ohnehin gerade Anbieter vergleicht, findet die aktuellen Konditionen im Vergleich der besten Krypto-Börsen.

EIP-7610 ist aus Glamsterdam gestrichen, nicht verschoben

Ein EIP ist ein Ethereum Improvement Proposal, also der formale Vorschlag für eine einzelne technische Änderung. Welche EIPs in ein Upgrade wandern, entscheiden die Kernentwickler in genau diesen Calls, und die Liste bleibt bis kurz vor der Aktivierung beweglich.

Im Call vom 20. August fragte ein Teilnehmer nach dem Status von EIP-7610, das aus dem Glamsterdam-Umfang herausgefallen war: ob es verschoben oder ganz gestrichen sei. Die Antwort des EIP-Editors Jochem Brouwer im Chat ist eindeutig: To answer explicitly, cancelled. I will also ask authors to formally withdraw this EIP. Das Protokoll führt denselben Punkt unter den Beschlüssen und nennt den Grund: EIP-7610 wird durch EIP-8253 abgelöst, und dieses zielt auf Hegotá, also das Upgrade nach Glamsterdam.

Der Unterschied zwischen verschoben und gestrichen klingt akademisch, hat aber Folgen für den Fahrplan. Ein verschobenes EIP taucht in der nächsten Runde wieder auf derselben Liste auf. Ein gestrichenes ist erledigt, und an seine Stelle tritt ein anderer Vorschlag mit anderem Inhalt.

Hegotá bekommt seine erste Auswahlrunde: EIP-833 und EIP-8379

Während Glamsterdam auf die Testnetze zuläuft, hat im selben Call die Auswahl für das darauffolgende Upgrade begonnen. Als vorläufig eingeplant gelten nach dem Protokoll zwei Vorschläge: EIP-833, das einen Off-by-one-Fehler bei der Berechnung von Checkpoint-Roots behebt und die Genauigkeit der Target-Votes verbessert, sowie EIP-8379, das den Konsens-Client zur alleinigen Sync-Quelle machen soll und damit doppelte Block-Verbreitung reduziert.

Ein dritter Vorschlag, EIP-12188 zur Verkürzung des Aufbewahrungsfensters für Konsens-Blöcke, landete weder auf der Liste noch im Papierkorb: Er ging zurück in die Forschungsdiskussion. Das Protokoll hält dazu fest, dass ein Teilnehmer die Motivation hinterfragte und ein anderer sich verhalten offen zeigte.

Für den Zeitplan interessanter ist der organisatorische Beschluss daneben. Alle Client-Teams sollen bis Mitte September eine erste Bewertung der Hegotá-Vorschläge veröffentlichen, in vier Stufen von S bis D. Barnabas Busa hat die Stufen im Chat definiert: S steht für eine nachdrückliche Empfehlung zur Aufnahme, A für eine Empfehlung, sobald offene Punkte geklärt sind, B für ein Dehnungsziel und D für eine Ablehnung. Bis zur DevCon soll daraus ein grober Konsens über den Umfang werden.

Was sich für dich als ETH-Halter am 28. September ändert

Die kurze Antwort: nichts. Der 28. September betrifft Sepolia, und Sepolia ist ein Testnetz. Das dort verwendete ETH hat keinen Marktwert, es wird über Faucets kostenlos ausgegeben und lässt sich in echtes ETH nicht umtauschen. Ein Fork auf Sepolia berührt weder dein Guthaben noch deine Adressen noch deine Steuerlage.

Es gibt bei diesem Upgrade auch keinen Snapshot, keinen Umtausch und keinen neuen Token. Glamsterdam ist ein Protokoll-Upgrade der bestehenden Kette, kein Chain-Split und keine Migration. Wer dir etwas anderes erzählt, verkauft dir etwas.

Genau darauf zielt die häufigste Betrugsmasche rund um Fork-Termine. Nach jeder Terminmeldung tauchen Nachrichten auf, die zum Handeln auffordern: eine angebliche Wallet-Migration, ein Formular zur Freischaltung, eine Frist. Die Regel dagegen ist einfach und kennt keine Ausnahme: Ein Ethereum-Upgrade verlangt von dir nie, deine Seed-Phrase einzugeben, Guthaben zu verschieben oder ein Konto zu verifizieren.

Staking, eigener Node und Börsenguthaben: Wer bei einem Fork wirklich handeln muss

Handlungsbedarf entsteht bei einem Hardfork nur an einer Stelle, und zwar bei denen, die selbst Software betreiben. Der Kreis ist überschaubar.

Wenn du einen eigenen Node oder Validator betreibst

Dann musst du deine Client-Software vor der Aktivierung auf eine Version aktualisieren, die die neuen Regeln kennt. Für die Testnetze gilt das ab dem jeweiligen Termin, für das Mainnet später. Wer das versäumt, folgt der Kette nach dem Fork nicht mehr. Die DevNet-Erfahrung vom 20. August zeigt zudem, dass es sich lohnt, statt der allerersten Version diejenige zu nehmen, in der die Übergangsfehler bereits behoben sind.

Wenn du über einen Anbieter stakest

Dann übernimmt der Anbieter das Update, und genau deshalb hat Lido im Call ein Testfenster verlangt. Für dich bleibt die Aufgabe, im Vorfeld zu wissen, wer dein Anbieter ist und wie er kommuniziert. Ein Anbieter, der zu Upgrades schweigt, ist bei der nächsten Störung auch nicht auskunftsfreudiger.

Wenn dein ETH auf einer Börse oder in einer Wallet liegt

Dann fällt für dich nichts an. Die Börse aktualisiert ihre Knoten selbst, Wallets ohne eigenen Node folgen automatisch. Erfahrungsgemäß setzen einzelne Börsen rund um große Mainnet-Forks Ein- und Auszahlungen für wenige Stunden aus. Das ist Routine, wird vorher angekündigt und betrifft Testnetz-Forks ohnehin nicht.

So prüfst du den Glamsterdam-Termin in fünf Minuten selbst nach

Du bist auf keine Schlagzeile angewiesen. Die Unterlagen der Kernentwickler liegen öffentlich, und der Weg dorthin ist derselbe, den dieser Text gegangen ist.

Im Planungs-Repository des Projekts liegen die Sitzungsartefakte nach Datum sortiert. Für den Call vom 20. August 2026 sind das zwei Dateien: die Zusammenfassung mit Beschlüssen und Zielen und die vollständige Chatmitschrift. In der ersten findest du die Zeilen zu Fork-Status, Beschlüssen und Zielen; in der zweiten die Zeitstempel, die Zahlen im Wortlaut und die Reaktionen der Teams darauf.

Die Umrechnung machst du selbst. Multipliziere die Epochennummer mit 32, dann hast du den Slot. Multipliziere den Slot mit zwölf Sekunden und addiere den Startzeitpunkt der jeweiligen Kette, dann hast du den Unix-Zeitstempel. Stimmt dein Ergebnis mit der genannten Uhrzeit überein, ist die Zahl in sich schlüssig. Weicht sie ab, hat jemand abgeschrieben, ohne nachzurechnen.

Für den Überblick über die Bewertung einzelner Vorschläge betreibt das Projekt zusätzlich ein öffentliches Ranking-Werkzeug, auf das im Call ausdrücklich verwiesen wurde. Dort kannst du ab Mitte September nachlesen, wie die Client-Teams die Hegotá-Vorschläge einstufen.

Ethereum-Upgrade-Termine einordnen: Was du daraus mitnimmst

Der 28. September 2026 ist der erste belastbare Glamsterdam-Termin, den es gibt. Er gilt für ein Testnetz, er steht unter dem Vorbehalt einer Bestätigung am 3. September, und über das Hauptnetz sagt er noch nichts aus. Wer das im Kopf behält, liest die kommenden Wochen deutlich ruhiger als der Markt.

1. Setz dir den 3. September in den Kalender, nicht den 28. September. An diesem Tag entscheidet der nächste Call, ob der Termin hält. Bis dahin ist jede Meldung mit dem Wort „beschlossen" ungenau. Wenn du dabei ohnehin Konditionen prüfst, ist der Börsenvergleich der schnellste Einstieg.
2. Klär vorher, wer bei dir das Update macht. Bei eigenem Node bist du es selbst, bei einem Staking-Anbieter ist es der Anbieter. Wer seinen Anbieter noch wählt, sollte auf die Kommunikation rund um Upgrades achten; die Unterschiede stehen im Staking-Vergleich.
3. Behandle jede Aufforderung zum Handeln als Betrugsversuch. Ein Protokoll-Upgrade verlangt nie eine Migration deiner Guthaben. Wer seine Schlüssel selbst hält, ist gegen diese Masche am besten geschützt; die Geräte dafür stehen im Hardware-Wallet-Vergleich.

(Stand: 21. August 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)