Rund 90 Solana-Validatoren mit etwa 29 % des gestakten SOL verloren während des Vorfalls am 12. August die Konnektivität, und Blöcke brauchten bis zu etwa 30 Minuten zur Finalisierung statt der üblichen 13 Sekunden, wie Metrikas Analyse des Vorfalls zeigt.

Solana fiel dennoch nie aus. Es wurden weiter Blöcke produziert, und eine Uptime-Kurve hätte für den Tag einen ganz normalen Verlauf gezeigt. Am Mittwoch, den 21. Oktober, soll das Netzwerk Alpenglow aktivieren, ein Upgrade, das eine Finalisierung von rund 150 Millisekunden zum Ziel hat — doch nichts darin greift das Hosting-Problem hinter dem Beinahe-Unfall an. Ein am 16. Oktober veröffentlichter Forschungsbericht von Fidelitys FCAT-Einheit, The State of Solana: Network Health and Resilience, beziffert das größte Hosting-Netzwerk auf etwa 29 % des Stakes, nahe dem Anteil, den Metrika offline sah.

Was am 12. August geschah

Solana kann einen Block nur finalisieren — den Punkt, an dem eine Transaktion unumkehrbar wird —, solange mehr als zwei Drittel des gestakten SOL abstimmen, was normalerweise etwa 13 Sekunden dauert. Am 12. August blieb das Netzwerk mit rund 71 % des Stakes online knapp über dieser Linie. Metrika beziffert den Offline-Anteil auf 28,83 % gegenüber einem Wert von 33,34 %, bei dem die Finalisierung kettenweit zum Erliegen kommt.

Diagramm: Offline-Anteil des gestakten SOL am 12. August im Vergleich zur Finalisierungs-Haltelinie. Quelle: Metrika.

Laut Metrika wären vier bis fünf weitere Prozentpunkte des Stakes auf den betroffenen Routen mit einem kettenweiten Halt gleichbedeutend gewesen, der eine koordinierte Wiederherstellung erfordert hätte. Der Fehler begann in TeraSwitchs Einrichtung in Miami und breitete sich auf Validator-Infrastruktur in London, Amsterdam, Frankfurt, Singapur und Tokio aus; in den meisten Fällen schalteten sich die Backup-Systeme der betroffenen Validatoren nie ein.

TeraSwitch behob den Fehler etwa zehn Minuten nach der Diagnose, und der Verkehr floss ab 04:16 UTC wieder, 33 Minuten nach Beginn. Die Validatoren erholten sich in den folgenden 40 Minuten. In diesem Zeitraum sprang der Anteil der geplanten Slots ohne produzierten Block von unter 1 % auf über 32 %. Nicht-Abstimmungstransaktionen pro Sekunde fielen von rund 1.100–1.300 auf unter 300. Etwa eine halbe Stunde lang wurde überhaupt kein Block finalisiert; der Rückstand wurde dann in einer Welle abgebaut, die im Schnitt bei rund 1. Sekunden von Produktion bis Finalisierung lag.

Die einzige Zahl, die sich nicht bewegte, war die Uptime, die bei 100 % blieb, weil die Kette nie aufhörte, Blöcke zu produzieren. Etwa eine halbe Stunde lang konnte aber niemand sagen, wann eine Zahlung unumkehrbar würde. Metrika, ein Anbieter einer Risikomanagement-Plattform für digitale Assets, die hier eigene Indikatoren heranzieht, betrachtet die Finalisierungsverzögerung — nicht die Ausfallzeit — als das Ereignis, das für alle, die auf Solana Mittel abwickeln, zählt.

Was ein stillstehendes Netzwerk bedeuten würde — und was nicht

Das Risiko, das FCAT beschreibt, ist eine blockierte Finalisierung und mögliche Zensur. Eine Koalition mit mehr als einem Drittel des Stakes könnte verhindern, dass der Rest die für die Finalisierung nötigen zwei Drittel erreicht, so der Bericht — uneingeschränkte Kontrolle über Nutzer-Assets oder die Fähigkeit, finalisierte Transaktionen umzuschreiben, würde sie dadurch jedoch nicht erhalten. Ein Hosting-Fehler, der denselben Stake-Anteil ausfallen ließe, würde die Finalisierung ohne jeden Angriff anhalten.

Dieser Anteil ist nicht schwer zu erreichen. FCAT zählt rund 20 Validator-Identitäten (an anderer Stelle 18), die mehr als ein Drittel des Stakes halten, und sagt, dieses Drittel liege in zwei Ländern, auf zwei Hosting-Netzwerken und auf zwei Basis-Client-Implementierungen. Dabei handelt es sich um Vote-Accounts, nicht um unabhängige Organisationen: Figment betreibt beispielsweise zwei der fünf größten Validatoren dieser Gruppe. FCATs Gesamturteil fällt positiv aus, mit Verweis auf mehr als zwei Jahre ohne größeren Mainnet-Ausfall, eine durchschnittliche Abstimmungserfolgsquote von etwa 99,7 % im Jahr 2026 und einen langsam diversifizierenden Software-Stack. Die Konzentration listet es als das zu beobachtende Thema. FCAT ist Fidelitys Einheit für angewandte Technologieforschung und betreibt selbst einen kleinen Solana-Validator.

Zwei Monate später liegt der Anteil weiterhin bei etwa 29 %

FCATs Oktober-Schnappschuss beziffert das größte Hosting-Netzwerk auf etwa 29 % des Stakes. Die beiden Kennzahlen messen Unterschiedliches — den während eines Fehlers offline befindlichen Stake und den Anteil eines Netzwerks am Gesamtstake —, landen aber am selben Punkt. FCAT zufolge arbeitete die Solana Foundation bereits daran, TeraSwitchs Dominanz zu verringern. So verteilen sich ihre Zahlen, von den Betreibern der Validatoren bis zum Code, den sie ausführen:

• 18–20 Betreiber — Validator-Identitäten mit mehr als einem Drittel des Stakes. Dabei handelt es sich um Vote-Accounts, nicht um unabhängige Organisationen; Figment betreibt zwei der fünf größten der Gruppe.
• ~40 % Standort — Anteil des Stakes in Frankfurt und Amsterdam. Das ist eine IP-Geolokalisierungsschätzung, die FCAT als möglicherweise ungenau bezeichnet; etwa 59 % entfallen auf Deutschland, die Niederlande und die USA.
• ~29 % Netzwerkanbieter — Anteil des Stakes auf einem Hosting-Netzwerk laut Oktober-Schnappschuss. Validatoren in verschiedenen Städten können denselben Anbieter nutzen, und Validatoren in einer Stadt können unterschiedliche Anbieter verwenden.
• ~63 % Software — Anteil des Stakes, der im Q3 Jito-basierte Software betrieb; weitere 26 % liefen mit Harmonic. Die meisten Konfigurationen teilen darunter weiterhin den Agave-Code, sodass ein einziger Fehler dort alle gleichzeitig treffen könnte.

Quelle: FCAT, The State of Solana: Network Health and Resilience (Oktober 2026).

Validatoren ballen sich aus einem Grund. Latenz belohnt die Nähe zu anderen Knoten, so FCAT, und spezialisierte Hosts wie TeraSwitch und Latitude bauen Hardware für Solanas Workload. Betreiber haben durchaus Schutzmaßnahmen: Failover, Backup-Strom und private Netzwerke wie DoubleZero, die die Abhängigkeit vom öffentlichen Internet vern. Die Foundation richtete zudem Anfang 2026 ein Incident-Response-Netzwerk, SIRN, ein. Am 12. August schalteten sich jedoch die meisten Backups nie ein.

Die Grenze der Foundation erreicht nur etwa 4 % des Stakes

Das Delegationsprogramm der Solana Foundation setzt die wichtigste Regel. Seit dem 1. Mai 2026 müssen Validatoren, die Foundation-Stake erhalten wollen, auf einem Hosting-Netzwerk unter einer 25-%-Obergrenze und in einem Rechenzentrum unter 15 % sitzen. Ein Validator, der die Prüfung nicht besteht, verliert seine Foundation-Delegation, bis er sie erneut besteht.

Die Grenzen traten drei Monate vor dem August-Fehler in Kraft, und laut FCATs Oktober-Schnappschuss lag das größte Netzwerk weiterhin über der Obergrenze. Die Reichweite des Programms ist die andere Hälfte des Problems. Im Q3 delegierte es an etwa 51 % der Validatoren, doch diese Delegationen machten nur etwa 4 % des aktiven Stakes aus. Die Regel gibt Validatoren einen Anreiz zur Diversifizierung, erfasst aber den Rest des Stakes nicht.

FCATs Oktober-Daten beziffern das größte Hosting-Netzwerk auf etwa 29 % des Stakes — über der 25-%-Obergrenze der Foundation —, während das Programm der Foundation im Q3 etwa 4 % des aktiven Stakes delegiert hatte.

Was Alpenglow löst — und was nicht

Alpenglow geht im Epoch 1064 auf dem Mainnet live, den Solana auf etwa 15:00 UTC am Mittwoch, den 21. Oktober, datiert; Anza, das Team hinter dem Agave-Client, nannte etwa 14:50. Das alte Abstimmungssystem läuft für die ersten 5.000 Slots weiter, etwa 18 Minuten, und das neue übernimmt bei Slot 459.653.000. Die Finalisierung soll von etwa 12,8 Sekunden auf rund 150 Millisekunden sinken — eine Zahl, die Solana als Erwartung, nicht als Konstante beschreibt. Wallets und Apps funktionieren weiterhin wie heute.

Für das Hosting-Problem ändert das Upgrade nichts. Eine schnellere Abstimmung verkürzt die Dauer der Einigung, aber nichts auf Solanas Upgrade-Seite ändert, wo Validatoren betrieben werden oder welcher Anbieter sie verbindet.

Zunächst verringert es zudem die Software-Diversität. Validatoren müssen Agave, Jito-Solana oder Harmonic Salsa auf einem auf Agave 4.3.0 basierenden Release ausführen. Firedancer und Frankendancer werden während der Migration nicht unterstützt, und Solanas Seite nennt keinen Termin dafür. Firedancer ist die unabhängige Codebasis, die FCAT als Solanas bedeutendsten Schritt Richtung unabhängiger Client-Diversität bezeichnet. Validatoren müssen außerdem mindestens 0,8 SOL oberhalb des rent-exempt-Minimums in ihrem Vote-Account halten, sonst stimmen sie nicht und produzieren im nächsten Epoch keine Blöcke.

• Davor — jetzt bis etwa 14:50–15:00 UTC, 21. Oktober: Firedancer- und Frankendancer-Betreiber wechseln zu einem Agave-basierten Client, und jeder abstimmende Validator hält 0,8 SOL oberhalb des rent-exempt-Minimums in seinem Vote-Account.
• Beim Umschalten — Epoch 1064 beginnt: das alte Abstimmungssystem läuft für die ersten 5.000 Slots, etwa 18 Minuten, und Alpenglow übernimmt bei Slot 459.653.000.
• Danach — was sich für Daten ändert: Vote-Transaktionen verlassen die Blöcke, sodass die Transaktionszahlen sinken; confirmed und finalized werden derselbe Zustand; und die Partizipationsdaten wandern in Zertifikate im Block-Footer.

Auch das Monitoring ändert sich. Metrikas Analyse betrachtet die Stimmen pro Block als besten Indikator dafür, wie nah das Netzwerk der Finalisierungslinie ist, da Stimmen gewöhnliche Transaktionen in Blöcken sind. Alpenglow nimmt die Stimmen aus den Blöcken, und Solanas Migrationshinweise besagen, dass alles, was die Validator-Partizipation durch das Parsen von Vote-Transaktionen misst, eine neue Quelle braucht, weil diese Daten in Zertifikate im Block-Footer wandern. Die gemeldeten Transaktionszahlen werden zudem sinken, ohne dass die reale Aktivität abnimmt.

diese Woche zu prüfen ist

Wenn Sie SOL staken: Prüfen Sie vor der Delegation, wo Ihr Validator gehostet ist. Validators.app, die Quelle, die sowohl FCAT als auch die Foundation nutzen, verfolgt den Stake nach Hosting-Netzwerk und Rechenzentrum. Ein Validator im größten Netzwerk trägt dasselbe August-Risiko.

Wenn Sie auf Solana aufbauen: Rechnen Sie am Mittwoch mit sinkenden Transaktions- und TPS-Dashboards ohne Veränderung der realen Aktivität. Lesen Sie bis zum Livegang von Alpenglow confirmed und dann finalized, wie Solanas Migrationshinweise empfehlen. Vor der Aktivierung bedeutet finalized weiterhin eine Wartezeit von etwa 12,8 Sekunden. Prüfen Sie Timeouts oder Retry-Logiken, die auf diese Verzögerung abgestimmt sind, und verfolgen Sie die Finalisierungszeit neben der Uptime.

Wenn Sie einen Validator betreiben: Falls Sie Firedancer oder Frankendancer nutzen, wechseln Sie vor Epoch 1064 zu einem Agave-basierten Client und prüfen Sie, ob der Vote-Account die 0,8 SOL hält.

Nach dem Mittwoch lohnen zwei Zahlen die Beobachtung: ob der Anteil des größten Hosting-Netzwerks unter die 25-%-Obergrenze der Foundation fällt und wann Firedancer wieder unterstützt wird. Beides steht nicht auf dem Stundenplan des Mittwochs.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz- oder Anlageberatung dar.