RWA-Orakel-Ausfälle: Wenn Off-Chain-Preise lügen

Was ein RWA-Oracle tatsächlich tut und warum es der einzige Ausfallpunkt ist

Einen realen Vermögenswert zu tokenisieren bedeutet, eine On-Chain-Darstellung von etwas zu schaffen, das streng genommen nicht On-Chain existiert: einen Pool privater Kreditdarlehen, einen Korb kurz laufender US-Schatzwechsel, einen Anteil an tokenisierten Geldmarktfondsanteilen oder einen immobilienbesicherten Schein. Der Smart Contract benötigt eine Zahl, um Besicherungsregeln durchzusetzen, Positionen mark-to-market zu bewerten und Liquidationen auszulösen. Diese Zahl stammt von einem Oracle.

Für krypto-native Vermögenswerte sind Oracles weitgehend ein gelöstes Engineering-Problem. Chainlink bezieht Spotpreise von Dutzenden Börsen, aggregiert sie über einen volumensgewichteten Median und überträgt alle paar Minuten oder immer dann Aktualisierungen, wenn die Preise einen Schwellenwert überschreiten. Pyth macht etwas Ähnliches, nutzt jedoch ein Pull-basiertes Design, bei dem der Preis Off-Chain von Market Makern signiert und nur dann On-Chain übertragen wird, wenn ein DeFi-Protokoll danach fragt. Beide Architekturen setzen kontinuierliche, liquide Märkte mit Tausenden unabhängiger Preisnehmer voraus.

Reale Vermögenswerte durchbrechen diese Annahmen. Der NAV eines Private-Credit-Pools wird wöchentlich von einem Fondsadministrator auf Basis von Daten auf Kreditebene berechnet, die nur langsam eintreffen. Der NAV eines tokenisierten Treasury-Produkts bewegt sich mit Anleihekursen, die nach Vereinbarung gehandelt werden, nicht sekündlich. Das Oracle meldet keinen Marktpreis mehr, sondern eine Berechnung, oft aus einer einzigen Quelle, in verzögertem Rhythmus.

Hier beginnen NAV-Oracles und Preis-Oracles, sich auf eine für das Risiko relevante Weise auseinanderzuentwickeln. Ein Preis-Oracle meldet, was der Markt jetzt zahlen würde. Ein NAV-Oracle meldet, was der Fondsadministrator glaubt, dass die Vermögenswerte wert sind, häufig mit Glättung, Abgrenzungen und einer Meldeverzögerung. Wenn ein Kreditereignis einen Private-Credit-Pool trifft, kann das Preis-Oracle (falls es überhaupt existiert) sofort einbrechen, während das NAV-Oracle tagelang die letzte plausible Zahl weiter meldet, weil der Administrator die Position noch nicht abgewertet hat.

Wie NAV-Oracles und Preis-Oracles bei einem Kreditereignis auseinanderlaufen

In einem gesunden Markt ist der Unterschied unsichtbar. Beide Feeds sagen im Großen und Ganzen das Gleiche, und ein Smart Contract, der einen von beiden nutzt, trifft sinnvolle Entscheidungen. Die Abweichung entsteht in dem Moment, in dem ein Kreditnehmer in einem Private-Credit-Pool eine Zahlung verpasst, herabgestuft oder im schlimmsten Fall ausfällt.

Betrachten Sie, was mit einem Senior-Pool im Goldfinch-Stil passiert, wenn eines seiner zugrunde liegenden Darlehen ausfällt. Der On-Chain-Pool-Token beansprucht weiterhin einen NAV auf Basis der letzten Administrator-Aktualisierung, die davon ausging, dass das Darlehen vollständig zurückgezahlt wird. Der Off-Chain-Marktwert der Ansprüche gegen diesen Pool, also der Preis, den ein Sekundärkäufer tatsächlich zahlen würde, sinkt sofort, sobald die Nachricht vom Ausfall die Kreditabteilungen erreicht. Stunden oder Tage lang können das On-Chain-Oracle und das Oracle in den Köpfen der Händler um Dutzende Prozentpunkte auseinanderliegen.

Diese Lücke ist die gesamte Angriffsfläche. Ein Kreditnehmer, der die Abweichung bemerkt, kann den Pool-Token anderswo On-Chain als Sicherheit hinterlegen, Stablecoins gegen den künstlich hohen NAV leihen und verschwinden, bevor das NAV-Oracle die Realität einholt. Bis der Administrator einen neuen NAV veröffentlicht, der den Ausfall berücksichtigt, wurde die Position bereits abgezogen. Dies ist kein hypothetisches Szenario. Es ist die strukturelle Form jedes Private-Credit-RWA-Exploits der letzten zwei Jahre.

Preis-Oracles verhalten sich anders. Ein marktgesteuertes Preis-Oracle, wie es Pyth oder Chainlink aus aktiven Märkten aggregiert, spiegelt das Kreditereignis innerhalb von Minuten wider, da Händler den Pool-Token sofort neu bewerten. Das Risiko dort ist das gegenteilige: Das Oracle kann genau dann manipulierbar werden, wenn der Sekundärmarkt dünn ist, und wenige große Geschäfte können den gemeldeten Preis so weit bewegen, dass ungerechtfertigte Liquidationen ausgelöst werden.

Stale-Price-Exploits: der häufigste Fehlermodus bei tokenisiertem Kredit

Ein Stale-Price-Exploit ist kein Hack im klassischen Sinne. Es wird nichts geknackt, keine privaten Schlüssel werden gestohlen, keine Governance-Abstimmung wird gekapert. Der Oracle arbeitet weiter wie vorgesehen. Er aktualisiert nur einfach nicht mehr oder meldet weiterhin den letzten bekannten Preis, lange nachdem dieser Preis aufgehört hat, wahr zu sein.

In RWA-Märkten passiert das routinemäßig aus langweiligen operativen Gründen. Der Fondsverwalter macht am Wochenende dicht. Der Datenfeed, der die cashflows auf Kreditebene liefert, fällt aus. Die Wirtschaftsprüfungsfirma, die den NAV-Bericht unterzeichnet, verpasst ihre Frist. Keines dieser Ereignisse verhindert, dass die zugrunde liegenden Kredite ausfallen. Sie sorgen nur dafür, dass die On-Chain-Zahl dies nicht mehr widerspiegelt.

DeFi-Kreditmärkte, die auf diesen Token aufgebaut sind, und es gibt mittlerweile einige hundert Millionen Dollar davon, behandeln den Oracle als absolute Wahrheit. Wenn der Oracle zuletzt vor zwei Tagen einen NAV von 1,02 $ gemeldet hat und ein Kreditnehmer 150 % Sicherheiten gestellt hat, glaubt das Kreditprotokoll, die Position sei sicher. Wenn der tatsächliche realisierbare Wert auf 0,80 $ gefallen ist, weiß das Protokoll das nicht. Es lässt den Kreditnehmer weiter abheben, da die Sicherheitenquote weiterhin gut aussieht.

Die Kreditereignisse von Maple Finance im Jahr 2023 veranschaulichen das deutlich. Als mehrere große Kreditnehmerpositionen in Maples Cashpools sauer wurden, handelten die Pool-Token in Sekundärmärkten fast sofort mit deutlichen Abschlägen. Der On-Chain-NAV, der über Maples Oracle-Infrastruktur mit Verwalterdaten aktualisiert wird, holte tagelang nicht auf. Während dieses Fensters wirkten Positionen, die Off-Chain bereits tief im Minus waren, On-Chain weiterhin sicher besichert, und mehrere DeFi-Integrationen mussten pausieren oder Positionen manuell abwerten.

Der Goldfinch-Fall folgte einem ähnlichen Drehbuch. Die NAVs des Senior Pools hingen berichteten Kreditereignissen um Tage oder Wochen hinterher, und jedes Protokoll, das den Senior-Pool-Token ohne eigene Sekundärmarkt-Preisprüfung als Sicherheit einband, vertraute am Ende einer Zahl, der kein Off-Chain-Teilnehmer zugestimmt hätte.

Chainlink- und Pyth-Architekturen und das Fehlermuster, das jede von ihnen verbirgt

Die Architektur von Chainlink ist auf Aggregation und Redundanz ausgelegt. Daten werden von vielen unabhängigen Node-Betreibern bezogen, die jeweils mehrere Börsen oder Datenanbieter abgreifen, und dann On-Chain aggregiert. Der Vorteil ist die Resistenz gegen eine einzelne fehlerhafte oder bösartige Quelle. Der Nachteil ist, dass Aggregation nur dann funktioniert, wenn es einen echten, liquiden Markt gibt, aus dem aggregiert werden kann. Wenn der zugrunde liegende Markt dünn ist, kann ein Chainlink-Feed zu einem Konsens aus einer kleinen Zahl träger Quellen werden, was nicht dasselbe ist wie ein echter Marktpreis.

Für hochvolumige Krypto-Paare ist das in Ordnung. Für tokenisierten Kredit, Immobilien oder Private Funds werden Chainlink-Feeds häufig so konfiguriert, dass sie nach einem Heartbeat-Zeitplan (etwa alle paar Stunden) oder beim Überschreiten einer Abweichungsschwelle aktualisieren. Wenn keiner dieser Auslöser greift, aktualisiert sich der Preis schlicht nicht. Es gibt keine eingebaute Frischeprüfung, die sagt: „Dieser Preis ist drei Tage alt, irgendwas stimmt wahrscheinlich nicht.“ Diese Verantwortung liegt beim konsumierenden Protokoll, und viele RWA-Integrationen setzen das schlicht nicht um.

Pyth geht einen anderen Weg. Preise werden von einem Panel aus Market Makern und Publishern signiert und dann über ein Pull-Modell On-Chain bereitgestellt. Der Konsument zahlt jedes Mal, wenn er einen Preis braucht, für einen frischen Preis, was bedeutet, dass es einen stale Pyth-Preis im technischen Sinne gar nicht gibt: jeder Read ist per Definition frisch. Das Risiko verlagert sich auf Konfidenzintervalle. Pyth veröffentlicht zu jedem Preis einen Konfidenzwert, und ein dünner Markt erzeugt ein breites Konfidenzband. Wenn das konsumierende Protokoll den Konfidenzwert ignoriert und den Medianpreis als Wahrheit behandelt, kann es genauso ausnutzbar sein wie ein staler Chainlink-Feed.

Die praktische Erkenntnis für jeden, der eine RWA-Integration bewertet: Ein Chainlink-Feed ohne Frischeprüfung ist ein Kandidat für Stale-Price-Exploits; ein Pyth-Feed ohne Konfidenzprüfung ist ein Kandidat für Thin-Market-Exploits. Beide kommen häufig vor.

Warum On-Chain-Liquidationslogik den Daten von gestern vertraut

Liquidations-Engines in DeFi sind darauf ausgelegt, adversar zu sein. Sie gehen davon aus, dass jede Position jederzeit unsicher werden kann und dass ein externer Liquidator sie bei einem Auslöser mit Gewinn schließt. Für krypto-native Sicherheiten funktioniert das hervorragend, weil der Preis-Oracle nahezu in Echtzeit aktualisiert und der Liquidator dieselbe Zahl sieht wie das Protokoll.

Bei RWA-Sicherheiten läuft dieselbe Liquidationslogik gegen eine Zahl, die Stunden oder Tage stale sein kann. Das Protokoll kann nicht unterscheiden zwischen „der Preis hat sich nicht bewegt“ und „der Preis-Feed aktualisiert nicht mehr“. Beides sieht On-Chain identisch aus. Aus Sicht des Protokolls ist ein Kreditnehmer, der vor zwei Tagen einen Private-Credit-Token mit 150 % Besicherung eingebracht hat, auch heute noch bei 150 %, und die Position ist sicher.

Genau deshalb ist Oracle-Risiko bei RWA so anders als Oracle-Risiko in reinem DeFi. Ein staler ETH-Preis-Feed wird innerhalb von Sekunden durch professionelle Searcher mit Keeper-Bots arbediert. Ein staler NAV-Feed für einen tokenisierten Private-Credit-Pool ist nicht auf dieselbe Weise arbitrierbar. Die Position ist illiquide, der NAV stammt aus einem menschengetriebenen Prozess, und es gibt keinen On-Chain-Mechanismus, der ein Update erzwingt. Die Liquidations-Engine versagt nicht; sie setzt lediglich Regeln loyal durch, die für eine andere Art von Vermögenswert geschrieben wurden.

Das Ergebnis ist eine stille Art von Insolvenz. Die Bücher des Protokolls sind weiterhin ausgeglichen. Die Sicherheitenquote liest sich weiterhin korrekt. Der Kreditnehmer kann weiter abheben. Und währenddessen ist der tatsächliche realisierbare Wert der zugrunde liegenden Kredite um die Hälfte gesunken.

Praktische Implikationen für jeden, der tokenisiertem Kredit ausgesetzt ist

Wenn Sie einen RWA-Token direkt halten, lautet die Frage, ob der NAV-Oracle des Emittenten in Stressphasen der Realität hinterherhinken kann. Die ehrliche Antwort lautet: ja, und zwar by design. NAVs für Private Credit und Immobilien werden mit Verzögerung gemeldet, weil die zugrunde liegenden Vermögenswerte nicht durchgehend gehandelt werden. Den Token zu halten bedeutet zu akzeptieren, dass Ihr ausgewiesener Wert und Ihr Liquidationswert während eines Kreditereignisses stark auseinanderlaufen können.

Wenn Sie einem DeFi-Protokoll Liquidität bereitstellen, das RWA-Token als Sicherheiten akzeptiert, ist die Frage schwieriger. Sie sind nun sowohl dem NAV-Oracle des Emittenten als auch der eigenen Preisprüfungslogik des Protokolls ausgesetzt. Viele Protokolle implementieren eine Sekundärmarkt-Preisprüfung, einen Uniswap-artigen Pool, ein Pyth-Aggregat, eine Chainlink-Referenz, um Divergenzen zwischen dem NAV des Emittenten und dem Live-Markt zu erkennen. Manche tun das nicht. Der Unterschied ist in der Dokumentation des Protokolls oft nicht erkennbar.

Ein paar konkrete Punkte, auf die zu achten ist: eine Frischeprüfung bei jedem Oracle-Read, idealerweise mit einer harten Obergrenze, ab der die Position pausiert wird; ein expliziter Vergleich zwischen dem NAV des Emittenten und mindestens einer unabhängigen Preisquelle; sowie eine dokumentierte Richtlinie dafür, was geschieht, wenn die beiden auseinanderlaufen. Wenn diese Antworten nicht öffentlich sind, wettet das Protokoll implizit darauf, dass sie nie gebraucht werden.

So behältst du RWA-Orakel-Risiken clever im Blick

RWA-Orakel-Risiken zeigen sich oft leise, lange bevor eine Schlagzeile erscheint. Ein Kreditereignis in einem Private-Credit-Pool braucht mitunter Tage, bis es im offiziellen NAV des Emittenten sichtbar wird, und Signale aus dem Sekundärmarkt übersieht man leicht, wenn man nicht weiß, auf welchen Plattformen der Token tatsächlich gehandelt wird. Das manuell zu verfolgen ist aussichtslos. Zippfeed bündelt RWA-Schlagzeilen, orakelbezogene Protokoll-Updates und On-Chain-Governance-Diskussionen der wichtigsten Emittenten, bewertet sie nach Sentiment (bullisch, neutral oder bearish) und versieht sie mit einer Wichtigkeitsstufe. So erkennst du die Lücke zwischen dem gemeldeten NAV eines Emittenten und der tatsächlichen Markteinschätzung des zugrunde liegenden Kredits, bevor diese Lücke zu einem realisierten Verlust wird.