Ethereums Veröffentlichungszeitplan hat sich verkürzt. Fusaka ging im Dezember 2025 live, Glamsterdam erreichte Mitte 2026 die finale devnet-Testphase, und die Core-Entwickler haben das darauf folgende Fork bereits benannt: Hegota.

Diese Geschwindigkeit ist gewollt. Nach Jahren der Bündelung von Änderungen in einem großen jährlichen Release ist die Ethereum Foundation zu einem Rhythmus von zwei kleineren, eng gefassten Forks pro Jahr übergegangen. Hegota ist der zweite Slot im Jahr 2026.

Der Unterschied zum Vorgänger liegt im Ziel. Glamsterdam skaliert, wie Ethereum Blöcke erstellt und bepreist. Hegota widmet sich einem ruhigeren Problem, das das Kernversprechen des Netzwerks nach erlaubnisfreiem Zugriff berührt. Hier ist, was feststeht, was noch umstritten ist und was es für ETH bedeutet. 👇

Was ist das Ethereum-Hegota-Upgrade?

Hegota ist das nächste koordinierte Ethereum-Hard-Fork nach Glamsterdam, das Änderungen an beiden Hälften des Protokolls in einem Release bündelt. Dem Benennungsschema von Ethereum folgend, paart sich der Consensus-Layer-Stern Heze mit Bogotá, einem früheren Devcon-Austragungsort, auf der Execution-Seite zum kombinierten Titel, der manchmal als Hegotá geschrieben wird.

Sein Umfang wird durch EIP-8081 geregelt, das Meta-Dokument, das jeden in Betracht gezogenen Vorschlag verfolgt. Dieses Dokument befindet sich Mitte 2026 noch im Entwurfsstadium, und das ist von Bedeutung. Nur ein einziges Feature ist formal als Hauptpunkt festgelegt, während der Rest Kandidaten bleibt.

Dieser Hauptpunkt ist FOCIL oder Fork-Choice Enforced Inclusion Lists, definiert in EIP-7805. Es wurde für Glamsterdam ins Gespräch gebracht, dann zurückgestellt, um zu viele ungetestete Interaktionen in einem Fork zu vermeiden, und leitet nun die Consensus-Layer-Arbeit von Hegota.

Warum Hegota wichtig ist: Zensurresistenz wird zur Protokollregel

Um den Sinn von Hegota zu verstehen, muss man sich ansehen, wer heute Ethereums Blöcke erstellt. Die meisten Validatoren stellen ihre Blöcke nicht selbst zusammen. Sie lagern die Aufgabe über protokollfremde Relays an eine kleine Gruppe spezialisierter Builder aus, eine Struktur, die entwickelt wurde, um die MEV-Handhabung effizient zu halten.

Der Nebeneffekt ist Konzentration. Eine Handvoll Builder dominieren die Blockproduktion, und ein Builder, der eine bestimmte Transaktion ablehnt, kann sie aus der Chain heraushalten. Nach den Sanktionen gegen Tornado Cash wurde dieses Risiko Realität, da compliance-orientierte Relays begannen, bestimmte Transaktionen zu filtern.

Vitalik Buterins Roadmap ordnet dies unter „The Scourge“ ein, dem Teil von Ethereums langfristiger Planung, der darauf abzielt, die durch MEV angetriebene Zentralisierung zu neutralisieren und die glaubwürdige Neutralität zu schützen. Die Protokollprioritäten für 2026 der Foundation tendieren in dieselbe Richtung und behandeln die Zensur bei der Blockproduktion eher als strukturelle Bedrohung denn als Randphänomen.

FOCIL ist die erste harte Antwort darauf. Es zerschlägt nicht den Builder-Markt und greift nicht in die Transaktionsreihenfolge ein. Es entzieht dem Builder das Recht, die Aufnahme zu verweigern, und verwandelt eine Garantie, die bisher von gutem Willen abhing, in eine Regel, die das Protokoll erzwingt.

Hegotas Hauptpunkt: FOCIL (EIP-7805)

FOCIL ist das tragende Feature des Upgrades und sein einzig bestätigter Hauptpunkt, der einzige Vorschlag, der im Hegota-Meta-Dokument als Scheduled for Inclusion markiert ist. Thomas Thiery (@soispoke) ist sein Hauptautor, und FOCIL erreichte diesen Status Anfang 2026 nach jahrelanger Forschung zu Inclusion Lists.

Wie FOCIL funktioniert

Für jeden Slot wählt das Protokoll pseudozufällig ein Komitee aus 16 Validatoren als Inclusion-List-Mitglieder aus. Jedes Mitglied scannt den öffentlichen Mempool und erstellt eine kurze Liste ausstehender Transaktionen, die seiner Meinung nach in den nächsten Block gehören, und sendet diese über das Netzwerk.

Der Proposer des nächsten Slots oder der Builder, der seinen Block konstruiert, muss die Transaktionen aus jeder gesammelten Liste einbeziehen. Attester stimmen nur für einen Block ab, der diese Listen berücksichtigt. Ein Block, der gültige Inclusion-List-Transaktionen weglässt, die hineingepasst hätten, erhält nicht genügend Stimmen und kann nicht kanonisch werden.

Der Ausdruck „fork-choice enforced“ bringt es auf den Punkt. Die Inklusion ist keine soziale Norm mehr, sondern wird Teil der Konsensregeln. Um eine Transaktion zu zensieren, müsste ein Angreifer in jedem Slot eine neue, zufällig ausgeloste Gruppe von 16 Validatoren neutralisieren oder darauf hoffen, dass diese sie nicht auflistet. Das Design geht lediglich von einem ehrlichen Komitee-Mitglied von sechzehn aus, damit es funktioniert.

Warum FOCIL jetzt wichtig ist

Glamsterdam verlagert den Blockbau bereits durch enshrined proposer-builder separation in das Protokoll, was das Relay-Vertrauen verringert, aber allein nicht verhindert, dass ein entschlossener Builder Transaktionen ausschließt. FOCIL schließt diese Lücke, weshalb die beiden Forks nacheinander und nicht gemeinsam veröffentlicht werden.

Es lässt sich zudem natürlich mit Account Abstraction kombinieren. Buterin hat auf eine Synergie hingewiesen zwischen FOCIL und dem Frame-Transaction-Vorschlag, bei dem Transaktionen von Smart Accounts und Datenschutzprotokollen, die über den öffentlichen Mempool gesendet werden, erzwungen inkludiert werden könnten, selbst wenn ein Proposer versuchen sollte, sie zu ignorieren. Zusammen würden sie den Nutzern einen protokollbasierten Weg zur Inklusion bieten, den kein einzelner Vermittler kontrolliert.

Account Abstraction und Verkle Trees in Hegota

Über FOCIL hinaus haben die am häufigsten diskutierten Hegota-Kandidaten echtes Gewicht, aber keine feste Zusage. Beide werden als „considered for inclusion“ geführt, ein Status, der eine ernsthafte Prüfung statt einer Freigabe signalisiert.

Native Account Abstraction (EIP-8141)

EIP-8141, bekannt als Frame Transactions, würde Account Abstraction nativ in das Protokoll integrieren anstatt als Zusatzebene, die ERC-4337 und Pectras EIP-7702 heute bieten. Es führt einen Transaktionstyp ein, der die Verifizierung von der Ausführung trennt, sodass jedes Konto flexible Signaturregeln nutzen, Batch-Operationen durchführen, gas in Stablecoins bezahlen oder Social Recovery ohne einen separaten Bundler einführen kann.

Buterin schlug es im Februar 2026 vor und unterstützte es auf dem All-Core-Devs-Call im März, teilweise wegen seines Aspekts der Quantensicherheit. Konten den Wechsel zu quantensicheren Signaturen vor jeder netzwerkweiten Migration zu ermöglichen, ist umso wichtiger, seit die Forschung von Google Quantum AI die geschätzte Anzahl an Qubits reduziert hat, die erforderlich sind, um die elliptischen Kurvensignaturen von Ethereum zu knacken.

Client-Teams leisteten Widerstand. Nethermind und Besu argumentierten, dass es zu schwer für den Status als Aushängeschild sei, was bedeutet hätte, dass Hegota ohne es nicht hätte veröffentlicht werden können, wodurch das Zeitplanrisiko gestiegen wäre. Der Kompromiss war der Status „Considered for Inclusion“, der es am Leben hält, ohne die Fork zu blockieren. Es konkurriert nun mit konkurrierenden Account-Abstraction-Designs vom Base-Team von Coinbase und Paradigm um einen zukünftigen Platz.

Verkle Trees und Statelessness

Verkle Trees stehen seit Jahren auf der Wunschliste von Ethereum als die Datenstruktur, die den heutigen Merkle-Patricia Trie ersetzen soll. Der Reiz liegt in der Statelessness. Viel kleinere kryptografische Proofs könnten es Nodes ermöglichen, die Chain zu validieren, ohne den vollständigen State zu speichern, wodurch die Hardwarebelastung für Betreiber verringert und der Kreis derer, die eine Node betreiben können, erweitert wird.

In der Roadmap von Ethereum sind Verkle Trees für Hegota als in Betracht gezogen gelistet, nicht als bestätigt. Der Übergang ist komplex, da er jedes Konto und jeden Contract durch eine State-Migration berührt, und Entwickler haben ihn gegen Ansätze abgewogen, die besser für Zero-Knowledge-Proving geeignet sind. Behandeln Sie jede Behauptung, dass sie fest für Hegota eingeplant sind, mit Vorsicht, da die Faktenlage dies noch nicht stützt.

Wie der Umfang von Hegota festgelegt wird

Hegota bietet einen nützlichen Einblick in die Art und Weise, wie Ethereum Forks inzwischen plant, und erklärt, warum so vieles offen bleibt. Im Rahmen des Headliner-Prozesses werden wichtige Features zuerst über einen strukturierten Zeitplan ausgewählt, anstatt alles auf einmal zusammenzustellen.

Headliner-Vorschläge wurden im Januar 2026 im Ethereum-Magicians-Forum eröffnet, mit einer Frist im Februar und mehreren All-Core-Devs-Calls zur Beratung dazwischen. Jedes benötigt einen namentlich genannten Champion, der es betreut. Erst wenn ein Headliner ausgewählt ist, öffnet sich ein 30-tägiges Zeitfenster für kleinere, nicht zum Headliner gehörende Ergänzungen.

Diese Disziplin ist gewollt. Indem sie ein Anker-Feature benennen und alles andere seinen Platz rechtfertigen lassen, vermeiden die Entwickler die aufgeblähten, verzögerungsanfälligen Releases früherer Jahre. Das öffentliche Bild ändert sich zudem im Laufe der Calls, sodass der Live-Status auf Forkcast und dem Meta-Thread der einzige verlässliche Umfang ist und kein einzelner Schnappschuss.

Release-Datum von Ethereum Hegota

Hegota ist für die zweite Hälfte des Jahres 2026 anvisiert, normalerweise ein Zeitfenster im späten Q3 oder Q4. Dieser Zeitplan bleibt aus einem Grund vorläufig. Er steht in der Warteschlange hinter Glamsterdam, und Glamsterdam hat ein eigenes, verschiebbares Datum.

Glamsterdam hat Mitte 2026 die letzten devnet-Tests erreicht und strebt eine H2-Aktivierung an, wobei sich interne Ziele um Q3 konzentrieren, nachdem sich der Zeitplan von einem früheren Ziel im ersten Halbjahr verschoben hat. Hegota beginnt seinen eigenen testnet-Pfad erst, wenn Glamsterdam veröffentlicht wird und sich als stabil erweist.

Die realistisch Einschätzung für Hegota:

• Festlegung des Umfangs (abgeschlossen und laufend): FOCIL als Headliner bestätigt, während Account Abstraction und andere Kandidaten geprüft werden, während EIP-8081 im Draft-Status verbleibt.
• Abhängig von Glamsterdam: Hegotas devnets und testnets folgen der mainnet-Aktivierung von Glamsterdam, sodass jede Verzögerung dort Hegota nach hinten verschiebt.
• Basisszenario (H2 2026): Eine Aktivierung im späten Jahr 2026, wenn Glamsterdam planmäßig im Q3 veröffentlicht wird.
• Verschiebungsrisiko (2027): Mehrere Analysten verweisen auf eine mögliche Verschiebung in den frühen Verlauf des Jahres 2027, insbesondere wenn ein schwerwiegendes Feature wie Account Abstraction hinzugefügt wird oder sich Glamsterdam verzögert.

Der Zeitplan-Beitrag der Ethereum Foundation und die Live-Tracker bleiben die maßgeblichen Quellen, sobald die Termine näher rücken.

Was Hegota für ETH-Inhaber und -Investoren bedeutet

Größere Ethereum-Upgrades folgen oft dem Rhythmus „Kauf das Gerücht, verkaufe die Nachricht“, wobei ETH im Vorfeld einer Hard Fork zulegt und nach der Aktivierung nachlässt. Das hat sich bei Pectra und Fusaka bestätigt, auch wenn die jüngeren Zyklen unruhiger waren als die klaren historischen Fälle.

Hegota bringt schwächere direkte Marktimpulse mit sich als Glamsterdam. Es erhöht weder das gas-Limit noch senkt es die Gebühren oder verändert die Angebotsmechanik von ETH. Die Gewinne sind eher struktureller als finanzieller Natur: Sie stärken die Zensurresistenz und ebnen, sofern die Kandidaten den Zuschlag erhalten, den Weg zu nativen Smart Accounts und lighter Nodes. Diese Eigenschaften sind für die langfristige Glaubwürdigkeit des Netzwerks wichtiger als eine kurzfristige Preisbewegung.

Das Marktumfeld ist verhalten. ETH verbrachte die erste Hälfte des Jahres 2026 mit einer schwachen Performance, bewegte sich in einer groben Spanne von 1.700 bis 2.100 USD und notierte im Juni nahe 1.750 USD, obwohl spot ETH ETFs starke Zuflüsse verzeichneten und über ein Drittel des gesamten ETH-Angebots im staking gebunden war. Diese Lücke zwischen gesunder Produktnachfrage und einem schwachen Preis treibt die Debatte über den Wertzuwachs an, die über dem Asset schwebt, und Hegota trägt kaum dazu bei, diese zu klären.

Für Inhaber verbessert das Upgrade die Qualität des Netzwerks, das sie besitzen, statt einen offensichtlichen Katalysator zu bieten. Wer damit handelt, sollte zuerst den Fortschritt des testnet von Glamsterdam im Auge behalten, da Hegotas Kalender davon abhängt. Nichts davon ist eine Finanzberatung, und sowohl Zeitpläne als auch Märkte ändern sich schnell. Betreiben Sie daher eigene Recherchen, bevor Sie Kapital allozieren.

Hauptrisiken des Hegota-Upgrades

Hegotas Risiken teilen sich in die Funktion selbst und den breiteren Prozess darum herum auf.

• Zeitplanabhängigkeit: Hegota kann seinen testnet-Zyklus erst starten, wenn Glamsterdam veröffentlicht wird, sodass jede Verzögerung der größeren Fork auch Hegota verzögert.
• Unklarheit beim Umfang: Da sich EIP-8081 im Entwurfsstatus befindet und die Hauptkandidaten noch nicht feststehen, könnte das finale Funktionsset ganz anders aussehen als heute, was die Planung für Entwickler und Validatoren komplizierter macht.
• FOCIL-Koordination: Inclusion Lists bringen zusätzliche Netzwerk- und Timing-Pflichten für Validatoren mit sich, und Builder müssen eng mit Kommitteemitgliedern verbunden sein, um Listen rechtzeitig zu erhalten. Grenzfälle wie Duplikate und Ungültigkeitserklärungen erfordern sorgfältige Handhabung.
• Bandbreite und Ressourcen: Die Ausführung eines zusätzlichen Kommitteeprozesses in jedem Slot erhöht die Last, weshalb die Listengrößen begrenzt sind und das Design ein separates Anreizsystem vermeidet.
• Komplexität der Account-Abstraktion: Wenn EIP-8141 vorangetrieben wird, betrifft dies die Kern-Transaktionsverarbeitung über jeden Execution-Client hinweg, wodurch die Testoberfläche vergrößert wird und das Risiko steigt, dass Annahmen über smart-contracts brechen.
• Zu großer Umfang: Ethereums Zurückhaltung in letzter Zeit war eine Stärke. Hegota mit zu viel zu beladen, würde die Verzögerungen heraufbeschwören, die der neue Takt verhindern soll.

Fazit

Mit Hegota wendet sich Ethereums Roadmap von der Skalierung der Layer 1 hin zu deren Verteidigung. Glamsterdam beantwortet, wie viel das Netzwerk verarbeiten kann. Hegota beantwortet eine andere Frage: Ob jemand stillschweigend davon ausgeschlossen werden kann.

FOCIL ist der klarste Ausdruck dafür. Die Verknüpfung von Inklusion mit der Fork-Choice-Regel verwandelt die Zensurresistenz von einer Eigenschaft, bei der die Community darauf vertraut, dass Builder sie respektieren, in eine vom Protokoll garantierte Eigenschaft. Die Kandidaten rundherum, native Account-Abstraktion und Statelessness, würden dasselbe Thema hin zu einem nutzbareren, dezentraleren Netzwerk treiben, sofern und wenn sie die Hürde nehmen.

Im Moment ist Hegota nur halb definiert und zeitlich an die davor liegende Fork gebunden. Die Richtung ist vorgegeben und findet breite Unterstützung. Die Details und das Datum werden noch geschrieben.