Pyth Network: Fünfstündiger Ausfall lässt DeFi im Blindflug

Fluglotsen haben einen Grundsatz: Wenn das Radar ausfällt, landen keine Flugzeuge – man stapelt sie. DeFi hat diesen Luxus nicht. Wenn ein Oracle ausfällt, fliegen die Maschinen weiter, Liquidationen werden weiter ausgelöst, und Lending-Märkte bewerten Sicherheiten weiterhin anhand der letzten veralteten Zahl im Cache. Am Donnerstag fiel das Radar bei Pyth Network für mehr als fünf Stunden aus – und der Rest des Himmels wurde unruhig.

Was passiert ist

Pyth Network meldete am Donnerstag einen erheblichen Ausfall, der sowohl die Core Price Feeds als auch die Sponsored Feeds betraf, wie Coinpedia berichtete – die Unterbrechung dauerte über fünf Stunden. Der Vorfall traf zwei Infrastrukturschichten, die den meisten DeFi-Entwicklern bekannt sind, auch wenn sie sie nie direkt angefasst haben: Pythnet und Hermes. Das sind die Leitungen, über die Pyths Echtzeit-Preisdaten an konsumierende Protokolle auf mehreren Blockchains geliefert werden.

Pyth gab schließlich bekannt, die Ursache identifiziert zu haben, und dass die Validatoren einen Neustart koordinierten, der auf die Wiederherstellung der Core Feeds und Sponsored Feeds bis 12:30 Uhr UTC abzielte. Die Statusseite unter status.pyth.network wurde in Echtzeit aktualisiert – das Mindeste, was man von einem Oracle-Anbieter mitten in einem Ausfall erwartet. Ein vollständiger Vorfallsbericht wird erwartet, sobald der Dienst vollständig wiederhergestellt ist.

Zwei Dinge waren gleichzeitig ausgefallen: Price Feeds – die primäre Oracle-Datenschicht, die Protokolle für die Echtzeit-Preisfindung von Assets nutzen – und Sponsored Feeds, die sekundäre Infrastruktur für spezifische Protokollintegrationen. Alles, was an eines dieser Systeme angeschlossen war – Handelsausführung, Sicherheitenberechnung im Lending, Liquidationsauslöser – lief während des Ausfallzeitraums ohne verlässliche Preisreferenz.

Und das geschah nicht im Vakuum. Polymarket, der nach eigenen Angaben weltgrößte Vorhersagemarkt, erlitt am selben Tag einen aktiven Exploit, bei dem mehr als 660.000 $ aus seinem UMA CTF Adapter-Vertrag auf Polygon abgezogen wurden. Zwei voneinander unabhängige Vorfälle – ein schlechter Nachmittag für den Kontrollraum.

Technische Analyse

Um zu verstehen, warum eine fünfstündige Lücke so bedeutsam ist, muss man verstehen, was Pythnet eigentlich ist. Pythnet ist eine eigens entwickelte Appchain, die Preisbeiträge erster Hand von Börsen und Market Makern aggregiert, sie durch Pyths Aggregationslogik verarbeitet und signierte Preisaktualisierungen erzeugt. Hermes ist der Off-Chain-Webdienst, über den Konsumenten diese signierten Updates abrufen und auf der jeweiligen Ziel-Chain veröffentlichen können – ob Solana, ein EVM-Rollup oder etwas Exotischeres. Wenn eine der beiden Komponenten ausfällt, kommt das gesamte Pull-Oracle-Modell zum Stillstand.

Dieses Pull-Modell ist der Punkt, an dem bei einem solchen Ausfall alles zusammenbricht. Anders als bei einem kontinuierlich gepushten Feed, bei dem veraltete Daten einfach mit ihrem letzten Wert on-chain verbleiben, erwartet ein Pull Oracle, dass der konsumierende Vertrag oder ein Keeper ein frisches signiertes Update abruft und es als Teil der Transaktion einreicht. Kein frisches Update, keine Transaktion. Oder schlimmer: Je nachdem, wie das integrierende Protokoll seine Veraltungsprüfungen programmiert hat, wird eine Transaktion gegen einen Preis ausgeführt, der mittlerweile deutlich veraltet ist.

Wer schon einmal einen Oracle-Adapter geschrieben hat, kennt den langweiligen Teil: den maxAge-Parameter. Setzt man ihn zu eng, kommt das Protokoll zum Stillstand, sobald Feeds langsamer werden. Setzt man ihn zu weit, akzeptiert man Preise aus einem völlig anderen Marktumfeld. Während einer fünfstündigen Lücke bei einem volatilen Asset ist keine Einstellung komfortabel. Insbesondere Solana-seitige Integrationen neigen dazu, sich stark auf Pyth zu stützen, angesichts von Pyths Entstehungsgeschichte auf dieser Chain (Solana-Dokumentation erklärt, wie On-Chain-Konten Oracle-Daten cachen).

Der Kern der Sache ist, dass die Validatoren einen Neustart koordinieren mussten. Diese Formulierung ist wichtig. Sie impliziert eine Wiederherstellung auf Konsensebene statt eines Hot-Swaps eines einzelnen fehlerhaften Dienstes – was damit übereinstimmt, dass Pythnet eine eigene validierte Chain ist. Koordinierte Neustarts sind in der Appchain-Welt nicht ungewöhnlich, aber sie sind konstruktionsbedingt langsam und halten jedes nachgelagerte Protokoll an, während die Betreiber ihr Haus in Ordnung bringen.

Wer es zu spüren bekommt

Am stärksten gefährdet sind Teams, die automatisierte Systeme betreiben und dabei ein Oracle wie Strom behandeln – als selbstverständliche Versorgungsleistung, nicht als Abhängigkeit mit eigenem SLA. Perpetuals-Plattformen, die Positionen markieren und Liquidationen gegen Pyth-Preise auslösen, stehen an erster Stelle. Wenn das Protokoll während des Ausfalls neue Liquidationen pausiert hat, gut. Wenn es sie auch nur kurz auf Basis veralteter Preise weiter ausgelöst hat, kommen die Nutzerbeschwerden nächste Woche.

Lending-Märkte sind die zweite Kategorie. Sicherheitenquoten, die anhand veralteter Preise berechnet werden, sind bestenfalls konservativ falsch und schlimmstenfalls gefährlich falsch – je nachdem, in welche Richtung sich der Markt während des Ausfallzeitraums bewegt hat. Die meisten Lending-Designs pausieren neue Kredite, wenn das Oracle nicht gesund ist, aber wer diesen Code-Pfad schon einmal debuggt hat, weiß, dass die Veraltungsprüfung zu den Dingen gehört, die man einmal schreibt und nie wieder anschaut – bis sie einen beißt.

Strukturierte Produkte, Options-Vaults und alles, was automatisches Rebalancing durchführt, bilden die dritte Ebene. Diese Systeme laufen oft auf cron-artigen Keepern, die nicht wissen, wie sie bei fehlenden Preisen sauber zurückrudern sollen. Sie scheitern entweder lautstark – was in Ordnung ist – oder sie scheitern still und akkumulieren Schieflage, was der Punkt ist, an dem alles zusammenbricht.

Dann ist da noch Polymarket, das seinen eigenen schlechten Tag aus völlig unabhängigen Gründen hatte und mehr als 660.000 $ durch einen UMA CTF Adapter-Exploit auf Polygon verlor. Die beiden Ereignisse sind technisch nicht miteinander verknüpft. Aber das Zusammentreffen eines Oracle-Ausfalls und eines Vorhersagemarkt-Exploits in einem Nachrichtenzyklus unterstreicht einen Punkt, dem die Branche immer wieder auszuweichen versucht: DeFi-Infrastruktur ist auf eine Weise fragil, die in den Marketing-Unterlagen nicht eingestanden wird.

Maßnahmen für Crypto- und DeFi-Teams

Drei Dinge, die Sie diese Woche tun sollten, wenn Sie Code entwickeln, der ein Price Oracle berührt.

Erstens: Überprüfen Sie Ihre Veraltungsprüfungen. Öffnen Sie den Adapter-Vertrag, suchen Sie den maxAge-Parameter oder das Äquivalent, und fragen Sie sich, ob der Wert in einem ruhigen Markt sinnvoll war und ob er noch sinnvoll ist, wenn das zugrundeliegende Oracle einen fünfstündigen Ausfall hat. Dokumentieren Sie die Antwort. Wenn der Ausfallmodus Ihres Protokolls bei einem Oracle-Ausfall lautet „weiter mit dem letzten bekannten Preis arbeiten", ist das eine Designentscheidung, kein Standard – und sie sollte von jemandem genehmigt werden, der dafür verantwortlich gemacht werden kann.

Zweitens: Bauen Sie einen Fallback-Pfad ein. Multi-Oracle-Setups sind unbeliebt, weil sie operativ lästig sind, aber die Kosten für die Integration eines sekundären Feeds und einer vernünftigen Abstimmungsregel sind deutlich geringer als die Kosten eines einzigen schlechten Liquidations-Kaskadeneffekts. Chainlink, Redstone, API3 – was auch immer die zweite Quelle ist: Schreiben Sie den Adapter jetzt, solange nichts brennt.

Drittens: Behandeln Sie die Oracle-Statusseite wie eine Produktionsabhängigkeit. Verbinden Sie einen Slack- oder PagerDuty-Hook mit status.pyth.network und gleichwertigen Seiten. Wenn Ihr Protokoll neue Risikooperationen innerhalb von Minuten nach einer Oracle-Verschlechterung pausieren kann, haben Sie bereits gewonnen. Die meisten Teams erfahren es über Twitter – was zu spät ist. Leser mit Interesse an Standards können auch die Ethereum-Dokumentation zu Mustern für Circuit Breaker und pausierbare Verträge konsultieren, die diese Art von graceful Degradation ermöglichen.

Zurück zum Kontrollraum: Lotsen werden nicht dafür bestraft, dass sie während eines Ausfalls weniger Flugzeuge landen – sie werden dafür bestraft, dass sie so tun, als könnten sie sehen, wenn sie es nicht können. Die Protokolle, die aus dieser Situation seriös hervorgehen werden, sind diejenigen, die pausiert, ein klares Statusupdate veröffentlicht und mit Bedacht wieder aufgenommen haben. Diejenigen, die fünf Stunden lang veraltete Preisanomalien still absorbierten und hofften, dass niemand die Zahlen nachrechnet, sind die, die man im Auge behalten sollte.

Wichtigste Erkenntnisse

• Pyth Networks Pythnet- und Hermes-Schichten fielen für mehr als fünf Stunden aus und nahmen sowohl die Core Price Feeds als auch die Sponsored Feeds mit sich.
• Validatoren mussten einen Neustart koordinieren, mit einer angestrebten Wiederherstellungszeit von 12:30 Uhr UTC – ein vollständiger Vorfallsbericht steht noch aus.
• Polymarket verlor am selben Tag mehr als 660.000 $ durch einen separaten UMA CTF Adapter-Exploit auf Polygon und verdeutlicht damit, wie gering DeFis Sicherheitspuffer sind.
• Pull Oracles versagen anders als Push Oracles, und Ihr maxAge-Parameter ist die Grenze zwischen sicherem Pausieren und gefährlicher Veraltung.
• Die vertretbare Position für Protokoll-Teams ist Multi-Oracle-Fallback plus automatisches Pausieren gekoppelt an Anbieter-Statusseiten – nicht Twitter-Monitoring.