Ethereum-Upgrade nach Glamsterdam: Was in Hegotá wirklich beschlossen ist

Ethereums nächstes großes Netzwerk-Upgrade heißt Glamsterdam, das darauf folgende trägt den Namen Hegotá. Seit dem 16. August 2026 läuft eine Zahl durch die Fachmedien: 66 Vorschläge stünden für Hegotá zur Debatte. Wer daraus liest, das Upgrade bringe 66 Neuerungen, hat die Zahl falsch verstanden. Im offiziellen Planungsdokument der Ethereum-Entwickler steht an diesem Tag genau ein einziger Vorschlag, der fest eingeplant ist.

Dieser Beitrag zeigt dir, woher die Differenz kommt, wie du das Planungsdokument selbst liest und woran du erkennst, ob eine angekündigte Funktion tatsächlich im Netzwerk landet. Diese Fähigkeit nützt dir weit über den heutigen Tag hinaus. Bis Hegotá im angepeilten Jahr 2027 aktiviert wird, wirst du Dutzende Meldungen über angebliche Ethereum-Funktionen lesen, von denen ein erheblicher Teil nie aktiv wird. Sämtliche Zahlen in diesem Text stammen aus einer eigenen Auszählung der amtlichen EIP-Dokumente am 16. August 2026.

Was Hegotá ist und wo das Upgrade im Ethereum-Fahrplan steht

Ein Ethereum-Upgrade ist technisch eine Hardfork: eine Änderung der Protokollregeln, die alle Knoten im Netzwerk zum selben Zeitpunkt übernehmen müssen. Wer nicht mitzieht, landet auf einer Kette, der die anderen nicht mehr folgen. Deshalb wird jede solche Änderung über Monate abgestimmt, in Testnetzen erprobt und erst dann mit einem festen Aktivierungszeitpunkt versehen. Wenn du dir den Unterbau dahinter noch einmal in Ruhe ansehen willst, hilft dir unsere Grundlagenerklärung zur Funktionsweise von Ethereum.

Die Upgrades tragen Namen ohne inhaltliche Bedeutung, was das Mitlesen erschwert. Aktuell arbeiten die Kernentwickler an Glamsterdam, dessen Maskottchen laut Planungsdokument ein Eisbär ist. Parallel läuft die Vorbereitung für das darauffolgende Upgrade Hegotá. Beide Vorhaben haben je ein eigenes Steuerungsdokument, in dem festgehalten wird, welche Einzeländerung in welchem Zustand ist. Für Glamsterdam ist das EIP-7773, angelegt am 26. September 2024. Für Hegotá ist es EIP-8081, angelegt am 11. November 2025. Beide tragen bis heute den Bearbeitungsstand „Draft“.

Was in Glamsterdam steckt und warum dieses Upgrade als besonders folgenreich gilt, haben wir in unserem Beitrag zu Glamsterdam und dem Ethereum-Kurs vom 5. April 2026 aufgeschrieben. Hegotá ist dessen Nachfolger und steht heute an dem Punkt, an dem Glamsterdam vor rund zwei Jahren stand.

Warum dich als ETH-Halter die Auswahlphase konkret betrifft

Es wäre bequem, die Sache als Entwicklerthema abzutun. Das trägt nur nicht weit, weil eine Hardfork Rechengebühren, Transaktionsarten und die Pflichten von Validatoren gleichzeitig für alle ändert. Zwei Beispiele aus der bereits fest eingeplanten Liste für Glamsterdam machen das greifbar: EIP-8037 und EIP-8038 erhöhen die Gaskosten für das Anlegen und das Lesen von Zustandsdaten, EIP-7981 verteuert Zugriffslisten. Wer viel mit Smart Contracts arbeitet, zahlt danach andere Gebühren als heute.

Auch das Abstecken von ETH ist betroffen. EIP-8061 in der Glamsterdam-Liste erhöht die Obergrenze, wie viele Validatoren pro Zeiteinheit austreten oder zusammengelegt werden können. Das entscheidet mit darüber, wie lange du auf dein Guthaben wartest, wenn du eine Position auflöst. Wenn du deine Rewards über einen Anbieter beziehst und wissen willst, welche Konditionen dort gerade gelten, findest du die Gegenüberstellung in unserem Vergleich der Staking-Plattformen; die Auszahlungsfristen der Anbieter und die Protokollregeln sind zwei verschiedene Bremsen, die unabhängig voneinander wirken.

Für dich als Halter, der ETH schlicht kauft und liegen lässt, gilt eine schlichtere Rechnung: Deine Handelsplattform muss ihre Knoten rechtzeitig aktualisieren, sonst stehen Ein- und Auszahlungen rund um den Aktivierungstermin still. Genau das ist der Grund, warum Börsen vor jeder Hardfork Wartungsfenster ankündigen. Wer wissen will, wie stabil die eigene Plattform bei solchen Umstellungen arbeitet und welche Gebühren dabei anfallen, findet die Übersicht im Vergleich der Krypto-Börsen.

Das Hardfork-Meta-Dokument EIP-8081 ist die einzige verbindliche Liste

Für jedes Upgrade legen die Kernentwickler ein sogenanntes Meta-EIP an. Es enthält keine Technik, sondern nur eine Bestandsaufnahme: welche Einzelvorschläge zur Debatte stehen, welche geprüft werden, welche fest eingeplant sind und welche verworfen wurden. Als Autoren von EIP-8081 sind Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo und Parithosh Jayanthi eingetragen, also dieselbe Gruppe, die auch die Meta-Dokumente der vorherigen Upgrades verantwortet.

Dieses Dokument ist deshalb wichtig, weil es die einzige Stelle ist, an der eine Zuordnung verbindlich festgehalten wird. Ein Beitrag in einem Diskussionsforum, ein Vortrag auf einer Konferenz oder ein Post in einem sozialen Netzwerk sagt nichts darüber aus, ob eine Änderung tatsächlich kommt. Erst wenn jemand eine Änderung am Meta-Dokument einreicht und diese übernommen wird, hat der Vorschlag einen offiziellen Zustand. Das komplette Dokument kannst du dir jederzeit selbst ansehen: EIP-8081, Hardfork Meta Hegotá.

Auszählung vom 16. August 2026: ein eingeplantes EIP, 37 Vorschläge

Wir haben das Rohdokument aus dem Quellverzeichnis der Ethereum-Entwickler abgerufen und die Einträge je Abschnitt ausgezählt. Der Abruf lieferte den Code 200, die Auszählung ergibt folgendes Bild.

Die aussagekräftigste Zahl in dieser Aufstellung ist die Null. Solange kein einziger Vorschlag abgelehnt wurde, hat die Auswahl noch nicht begonnen. Das deckt sich mit der Beschreibung in den Fachmedien, wonach die Kernentwickler in den kommenden Sitzungen mit dem Streichen anfangen wollen. Für dich heißt das: Von den 37 eingereichten Vorschlägen wird der überwiegende Teil in diesem Upgrade nicht landen, und heute weiß niemand verlässlich, welche es sein werden.

Die vier Stufen nach EIP-7723 und was sie tatsächlich zusagen

Die Begriffe im Meta-Dokument sind keine Redewendungen, sondern definierte Zustände. Festgelegt sind sie in einem eigenen Dokument, EIP-7723 mit dem Titel „Network Upgrade Inclusion Stages“, angelegt im Juni 2024 und inzwischen im Stand „Last Call“. Wer diese vier Begriffe auseinanderhalten kann, liest jede künftige Upgrade-Meldung zuverlässiger als die meisten Schlagzeilen sie wiedergeben. Nachlesen kannst du die Definitionen hier: EIP-7723, Network Upgrade Inclusion Stages.

Proposed for Inclusion ist nur ein Antrag

Um einen Vorschlag auf diese Stufe zu heben, genügt es, eine Änderung am Meta-Dokument einzureichen, die den Eintrag hinzufügt. Es braucht keine Zustimmung der Kernentwickler, keine fertige Umsetzung und keine Tests. Das Dokument hält lediglich fest, dass jemand die Änderung für dieses Upgrade vorschlägt und als Ansprechpartner bereitsteht. Alle 37 Einträge, die derzeit bei Hegotá unter diesem Punkt stehen, haben also bislang nichts weiter durchlaufen als eine Einreichung.

Considered for Inclusion ist eine Absichtserklärung, keine Zusage

Diese Stufe erreicht ein Vorschlag, nachdem die Entwicklerteams ihn angesehen haben und die Absicht äußern, ihn in einem Testnetz auszuprobieren. EIP-7723 vergleicht den Zustand ausdrücklich mit einem „concept ACK“ aus anderen Open-Source-Projekten und schreibt im selben Absatz, dieser Zustand reiche für einen Einsatz im Hauptnetz nicht aus. Ein Vorschlag kann von hier aus jederzeit wieder in die Ablehnung wandern, falls die Teams sich dagegen entscheiden.

Scheduled for Inclusion setzt gemessene Reife voraus

Erst diese Stufe bedeutet, dass ein Vorschlag auf dem Weg ins Hauptnetz ist. EIP-7723 nennt dafür vier Prüfkriterien: Der Vorschlag lief in einem Testnetz, das über mindestens eine Woche stabil arbeitete und keine kritischen Fehler zeigte. Die Spezifikation enthält keine Platzhalter und keine offenen Entwurfsfragen mehr. Wechselwirkungen mit anderen Vorschlägen sind entweder gering oder im selben Testnetz mitgeprüft worden. Und die Testabdeckung reicht aus, ohne dass die Software verschiedener Anbieter voneinander abweicht. Selbst danach gilt die Zuordnung nur „vorbehaltlich unvorhergesehener Probleme“, und auch von hier aus ist eine Streichung möglich.

Ein praktischer Nebeneffekt der Regeln lohnt sich zu merken: Sobald das Meta-Dokument vom Stand „Draft“ in den Stand „Review“ wechselt, werden die Listen der Vorschläge und der Ablehnungen daraus entfernt. Beim Wechsel in den Stand „Last Call“ verschwindet auch die Liste der geprüften Kandidaten. Das Dokument wird auf dem Weg zur Fertigstellung also kürzer, nicht länger. Wenn du es in einigen Monaten wieder aufrufst und plötzlich nur noch eine kurze Liste findest, ist das ein Fortschrittszeichen und kein Fehler.

FOCIL (EIP-7805) ist bei Hegotá der einzige feste Bestandteil

Der eine Vorschlag, der bei Hegotá bereits fest eingeplant ist, trägt die Nummer EIP-7805 und das Kürzel FOCIL, ausgeschrieben „Fork-choice enforced Inclusion Lists“. Angelegt wurde er am 1. November 2024, als Autoren sind Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann und Jihoon Song eingetragen.

Das Problem, das FOCIL angeht, beschreibt die Spezifikation selbst deutlich: Das Recht, Blöcke zu bauen, wird heute an spezialisierte Anbieter versteigert. In der Folge beherrschen wenige dieser Bauunternehmen die Blockproduktion, und die Widerstandsfähigkeit des Netzwerks gegen Zensur hat darunter gelitten. Praktisch heißt das, dass ein Blockbauer eine Transaktion aussortieren kann, etwa weil sie eine sanktionierte Adresse berührt, und du keinen Anspruch darauf hast, dass ein anderer sie aufnimmt.

Der Mechanismus arbeitet in vier Schritten. In jedem Zeitfenster wird eine Gruppe von Validatoren zum Ausschuss bestimmt; jedes Mitglied stellt aus seiner eigenen Sicht auf den Transaktionsspeicher eine Aufnahmeliste zusammen und verteilt sie im Netz. Der Vorschlagende des nächsten Blocks und alle Bezeugenden sammeln diese Listen und reichen sie weiter. Der Blockproduzent muss die Transaktionen aus allen eingesammelten Listen in seinen Block aufnehmen. Und die Bezeugenden stimmen nur dann für den Block, wenn er das auch getan hat. Aus einer Bitte wird damit eine Bedingung.

Für dich als Nutzer ist das der Unterschied zwischen „meine Transaktion wird wahrscheinlich aufgenommen“ und „meine Transaktion muss aufgenommen werden“. Für Validatoren wächst die Aufgabenliste, weil der Ausschussdienst zusätzlich zum bisherigen Betrieb anfällt. Wer sein ETH über einen Dienstleister abgesteckt hat, sollte im Vorfeld prüfen, wie dieser Anbieter mit neuen Protokollpflichten umgeht; die aktuellen Konditionen der Anbieter stehen in unserem Staking-Vergleich.

Frame Transaction (EIP-8141) trägt den Privatsphäre-Strang

Der zweite Eintrag mit einem eigenen Zustand ist EIP-8141 mit dem Namen „Frame Transaction“, angelegt am 29. Januar 2026. Die Autorenliste ist ungewöhnlich lang und enthält unter anderem Vitalik Buterin, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Stavros Vlachakis und Toni Wahrstätter. Der Vorschlag steht bei Hegotá auf der Stufe „Considered for Inclusion“ und ist dort derzeit der einzige Eintrag.

Inhaltlich führt er eine neue Transaktionsart ein, deren Gültigkeitsprüfung und deren Gebührenzahlung frei definierbar sind. Die Transaktion zerfällt dafür in einzelne Abschnitte, sogenannte Frames, die nacheinander die Prüfung, die Freigabe der Gebühr und die eigentliche Ausführung übernehmen. Die Spezifikation nennt dafür mehrere Gründe: einen Ausstieg aus dem heute verwendeten Verfahren mit elliptischen Kurven hin zu Verfahren, die auch gegen Quantenrechner bestehen; die Entkopplung eines Kontos von seinem Schlüssel, wodurch ein Schlüsselwechsel im Protokoll selbst möglich wird; einfachere und dadurch sicherere Smart-Contract-Konten mit eingebauter Stapelverarbeitung; sowie alternative Gebührenmodelle ohne zwischengeschaltete Dienstleister.

Der Punkt mit dem Schlüsselwechsel verdient Aufmerksamkeit, wenn du deine Bestände selbst verwahrst. Heute hängt ein Konto unlösbar an einem Schlüsselpaar; geht der Schlüssel verloren oder gerät er in falsche Hände, ist die Adresse verbrannt. Ein im Protokoll verankerter Schlüsselwechsel würde diese Logik lockern. Bis dahin bleibt die Aufbewahrung des Schlüssels das entscheidende Glied, und dafür ist eine Hardware-Lösung nach wie vor der solideste Weg; welche Geräte sich unterscheiden und woran, steht in unserem Hardware-Wallet-Vergleich.

Was „native Privatsphäre“ im Dokument tatsächlich bedeutet

Die Berichterstattung vom 16. August 2026 nennt drei Vorschläge, die gemeinsam Privatsphäre-Anwendungen ohne Mittelsmann ermöglichen sollen: die Frame Transaction sowie EIP-8250 („Keyed Nonces for Frame Transactions“) und EIP-8272 („Recent Roots for Frame Transactions“). Die Angabe geht auf einen Beitrag des Entwicklers Toni Wahrstätter zurück.

Im Meta-Dokument selbst sieht die Lage nüchterner aus. Von diesen drei Vorschlägen hat einer den Zustand „Considered for Inclusion“, die beiden anderen stehen unter „Proposed for Inclusion“ und haben damit noch keine Prüfung durchlaufen. Ein vierter Eintrag mit direktem Bezug zum Thema, EIP-8182 „Private ETH and ERC-20 Transfers“, steht ebenfalls nur unter den Vorschlägen. Das Paket, das in den Überschriften als Privatsphäre-Offensive erscheint, besteht im amtlichen Dokument aus einem geprüften und drei ungeprüften Einträgen.

Diese Unterscheidung ist keine Wortklauberei. Von ihr hängt ab, ob du in zwei Jahren mit einer Funktion rechnen kannst. Und sie lässt sich in dreißig Sekunden selbst nachsehen, weil das Dokument öffentlich ist.

66 Vorschläge in den Medien, 39 Einträge im Dokument

Bleibt die Frage, woher die Zahl 66 stammt, wenn im Dokument 39 Einträge stehen. Zwei Fachmedien haben am 16. August 2026 darüber berichtet, Cointelegraph und crypto.news, und beide beziehen sich auf denselben Beitrag des genannten Entwicklers in einem sozialen Netzwerk. Wir haben diesen Beitrag nicht selbst einsehen können und geben die Zahl deshalb ausdrücklich als Medienangabe wieder. Nachgeprüft und selbst ausgezählt sind allein die Werte aus dem Meta-Dokument.

Der wahrscheinlichste Grund für die Differenz liegt in dem, was jeweils gezählt wird. Das Meta-Dokument führt nur, was jemand förmlich eingereicht hat. In den Entwicklersitzungen und im Diskussionsforum kursieren darüber hinaus Vorschläge, die diesen Schritt noch nicht gegangen sind. Beide Zahlen können damit zutreffen und trotzdem Verschiedenes messen. Für dich als Leser folgt daraus eine einfache Prüfregel: Eine Zahl ohne die zugehörige Stufe sagt nichts aus. Frag bei jeder Upgrade-Meldung zuerst, wie viele Vorschläge fest eingeplant sind, und lies erst danach weiter.

Glamsterdam als Maßstab: 19 eingeplante und 41 abgelehnte EIPs

Wie stark die Auswahl am Ende ausdünnt, zeigt der Blick auf das Upgrade, das vor Hegotá liegt. Dieselbe Auszählung, angewendet auf das Glamsterdam-Dokument EIP-7773 am 16. August 2026, ergibt 19 fest eingeplante Vorschläge, sieben weitere Einträge in Nebenkategorien für Netzwerkprotokolle und Analysen sowie 41 ausdrücklich abgelehnte Vorschläge. Bei Glamsterdam wurde also mehr aussortiert als übernommen.

Unter den fest eingeplanten Glamsterdam-Vorschlägen finden sich Änderungen mit spürbarer Wirkung, etwa EIP-7732 zur festen Verankerung der Trennung von Vorschlagenden und Blockbauern, EIP-7928 zu Zugriffslisten auf Blockebene und EIP-7954, das die zulässige Größe eines Smart Contracts anhebt. Was davon am Ende wirklich aktiviert wird, steht auch hier erst mit der Aktivierung fest.

Besonders lehrreich ist ein Detail am Rand. Drei Vorschläge, die für Glamsterdam abgelehnt wurden, tauchen im Hegotá-Dokument erneut als Vorschlag auf: EIP-7668 zum Entfernen der Bloom-Filter, EIP-7819 zur SETDELEGATE-Anweisung und EIP-7979 zu neuen Aufruf- und Rücksprungbefehlen der virtuellen Maschine. Das ist ausdrücklich vorgesehen. EIP-7723 hält fest, dass eine Ablehnung immer nur für ein einzelnes Upgrade gilt und einen erneuten Anlauf beim nächsten Mal nicht verhindert. Eine Ablehnung ist damit kein endgültiges Urteil über eine Idee, sondern eine Entscheidung über einen Termin.

Der Zeitplan: Glamsterdam 2026, Hegotá 2027, beides ohne festes Datum

Zu den Terminen halten sich die Dokumente auffällig zurück, und das ist die ehrlichste Auskunft des ganzen Vorgangs. Beide Meta-EIPs enthalten eine Tabelle mit den Aktivierungszeitpunkten für die Testnetze und das Hauptnetz. In beiden Dokumenten sind sämtliche Felder dieser Tabelle leer. Darunter steht der Hinweis, die Zeilen würden ausgefüllt, sobald die Entwicklerteams die Zeitpunkte festgelegt haben.

Was es an Angaben gibt, stammt aus der Berichterstattung und aus dem öffentlichen Fahrplan des Projekts: Glamsterdam soll demnach in der zweiten Jahreshälfte 2026 auf das Hauptnetz kommen, Hegotá streben die Kernentwickler für das folgende Jahr an. Als nächsten Termin für eine Entwicklersitzung nennt Cointelegraph Montag, 14:00 UTC. Diesen Termin konnten wir an der Primärquelle nicht gegenprüfen und führen ihn deshalb als Medienangabe.

Für deine Planung heißt das: Es gibt derzeit kein Datum, auf das du dich stützen könntest, und jede Meldung, die eines nennt, sollte dich zum Nachsehen bewegen. Wie sich die Kursdiskussion rund um Ethereum davon unabhängig entwickelt hat, kannst du in unserer Ethereum-Analyse vom 27. Juni 2026 nachlesen; eine Aussage über künftige Kurse enthält der heutige Text bewusst nicht.

So verfolgst du die Auswahl selbst, ohne auf Schlagzeilen zu warten

Die gute Nachricht an diesem Thema ist, dass du dich auf niemanden verlassen musst. Das Dokument ist öffentlich, kurz und in wenigen Minuten überprüft. Ein Durchgang sieht so aus:

1. Ruf EIP-8081 auf und ignoriere zunächst den Fließtext. Interessant sind allein die Abschnittsüberschriften und die Anzahl der Einträge darunter.
2. Zähl die Einträge unter „Scheduled for Inclusion“. Diese Zahl ist der belastbare Kern jeder Upgrade-Meldung.
3. Sieh nach, ob unter „Declined for Inclusion“ etwas steht. Wächst diese Liste, hat die Auswahl begonnen. Bleibt sie leer, ist noch alles offen.
4. Wirf einen Blick in EIP-7773, um zu sehen, was zeitlich vor Hegotá liegt und in welchem Zustand es ist.
5. Prüf den Bearbeitungsstand des Dokuments oben im Kopfbereich. Ein Wechsel von „Draft“ auf „Review“ bedeutet, dass die Vorschlagsliste entfernt wurde und die Sache konkreter wird.
6. Sieh in der Aktivierungstabelle nach. Solange dort leere Felder stehen, existiert kein beschlossener Termin, unabhängig davon, was anderswo geschrieben wird.

Wer diesen Durchgang zweimal gemacht hat, braucht dafür beim dritten Mal kaum noch fünf Minuten. Der Gewinn ist beträchtlich: Du kannst jede Meldung über eine kommende Ethereum-Funktion binnen kurzer Zeit einordnen, statt sie glauben zu müssen.

Grenzen dieser Auszählung: Was das Meta-Dokument nicht beantwortet

Damit du weißt, wie weit die Zahlen dieses Textes tragen, hier die Einschränkungen im Klartext. Die Auszählung ist eine Momentaufnahme vom 16. August 2026. Jede angenommene Änderung am Dokument verschiebt die Werte, und in einer aktiven Auswahlphase geschieht das mehrmals pro Woche.

Das Dokument sagt außerdem nichts darüber, wie weit die Umsetzung in den einzelnen Softwareprodukten gediehen ist. Diese Information steckt in den Testnetzberichten und in den Protokollen der Entwicklersitzungen, nicht im Meta-EIP. Es sagt ebenso wenig, welcher der 37 eingereichten Vorschläge überhaupt Aussicht hat; wer das behauptet, deutet, statt zu berichten.

Die Zahl 66 haben wir, wie oben ausgeführt, nicht an der Ursprungsquelle geprüft. Und schließlich: Ein Netzwerk-Upgrade ist kein Kursereignis. Über den Wert von ETH sagt weder die Anzahl der Vorschläge noch deren Zustand etwas aus, und dieser Beitrag leitet daraus ausdrücklich keine Erwartung ab.

Ethereum-Upgrades einordnen: Was du daraus mitnimmst

1. Zähl die fest eingeplanten Vorschläge, nicht die diskutierten. Bei Hegotá steht diese Zahl heute bei eins, bei Glamsterdam bei 19. Alles darüber hinaus ist Absicht, nicht Beschluss. Wenn du die technische Entwicklung zum Anlass nimmst, deinen Bestand aufzubauen oder umzuschichten, vergleich vorher die Gebühren und die Handelspaare der Anbieter in unserem Börsenvergleich.
2. Prüf vor jeder Hardfork, was dein Anbieter damit macht. Wartungsfenster, ausgesetzte Auszahlungen und geänderte Austrittsfristen treffen dich in der Praxis früher als jede Protokolländerung. Besonders relevant wird das, wenn du Rewards beziehst; die Konditionen der Anbieter findest du im Staking-Vergleich.
3. Behalte die Verwahrung in der eigenen Hand. Solange ein Schlüsselwechsel im Protokoll nicht existiert, hängt alles an der sicheren Aufbewahrung deines Schlüssels. Welche Geräte sich wie unterscheiden, steht im Hardware-Wallet-Vergleich.

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