RWA Oracle Attack: Wenn der Price Feed lügt

Wie ein RWA-Oracle-Angriff tatsächlich aussieht

Ein RWA, also ein Real-World-Asset-Token, repräsentiert etwas Off-Chain: einen US-Treasury-Bill, einen Anteil am Eigenkapital einer Gewerbeimmobilie, eine private Kreditposition, einen Anteil an einem Geldmarktfonds. Um diesen Token als Sicherheit zu nutzen, gegen ihn eine Stablecoin zu prägen oder einen Kreditnehmer zu liquidieren, braucht ein DeFi-Protokoll einen Preis. Dieser Preis muss irgendwoher kommen, und dieses Irgendwo nennen wir ein Oracle.

Ein Oracle-Angriff im engeren Sinne ist jeder Vorfall, bei dem der Preis, den das Protokoll sieht, erheblich von dem Preis abweicht, zu dem der zugrunde liegende Vermögenswert tatsächlich gehandelt würde. Die Abweichung kann dadurch entstehen, dass ein Angreifer einen marktbasierten Feed beeinflusst, ein Emittent einen NAV-Feed pausiert, ein Node-Betreiber offline geht, eine Verwahrbank Rücknahmen einfriert oder während eines Wochenendes einfach ein langsames Update erfolgt. Das gemeinsame Merkmal ist, dass die On-Chain-Zahl lange genug nicht mehr der Realität entspricht, damit jemand aus der Lücke Wert abschöpfen kann.

Für RWA-Protokolle ist das auf eine Weise wichtig, die etwa für einen einfachen ETH/USDC-Pool nicht gilt. Der Pool kann sich selbst heilen, weil Arbitrageure die Lücke innerhalb weniger Blöcke schließen. Ein tokenisierter Immobilienfonds kann das nicht. Es gibt keinen globalen 24/7-Markt für ein Bürogebäude in Brooklyn. Wenn der On-Chain-NAV also das eine sagt und die zugrunde liegenden Bewertungen etwas anderes, bleibt das Protokoll bei dem hängen, was das Oracle zuletzt veröffentlicht hat.

Wie sich der Verlust ausweitet: ein Durchlauf durch ein Szenario mit einem tokenisierten REIT

Stellen Sie sich ein Protokoll namens BlockREIT vor, das einen tokenisierten Immobilienfonds, nennen wir ihn tREIT, als Sicherheit akzeptiert. Das Protokoll erlaubt Nutzern, gegen tREIT eine Stablecoin, sagen wir rUSD, mit einer Beleihungsquote von 70 Prozent zu prägen. Das Oracle ist ein NAV-basierter Feed, der vom tREIT-Emittenten betrieben wird, alle 24 Stunden On-Chain aktualisiert und von einer Multisig aus drei Verwahrern signiert wird. Die Smart Contracts sind auditiert. Das Marketing spricht von institutioneller Qualität.

Am Freitagabend gibt der zugrunde liegende REIT bekannt, dass einer seiner größten Mieter mit einem Mietvertrag über 40 Millionen Dollar in Verzug geraten ist und dass der Wirtschaftsprüfer des Fonds vier bis sechs Wochen benötigt, um die Vermögenswerte neu zu bewerten. Die Off-Chain-Welt geht nun davon aus, dass tREIT ungefähr 0,78 Dollar pro Token wert ist. Das On-Chain-Oracle zeigt weiterhin 1,00 Dollar an, weil die nächste Aktualisierung erst am Samstagmittag erfolgt und die Governance-Richtlinie des Emittenten Updates mitten im Zyklus verbietet.

Jeder, der die Off-Chain-Nachrichten verfolgt, kann die Lücke nun erkennen. Ein Kreditnehmer mit einer Beleihungsposition von 0,95 Dollar ist dem Namen nach tatsächlich überbesichert und faktisch unterbesichert. Das Protokoll kann nicht liquidieren, weil das Oracle weiterhin anzeigt, dass der Kreditnehmer sicher ist. Der Kreditnehmer, der genau aufgepasst hat, zieht die tREIT-Sicherheit auf eine neue Wallet ab, tauscht sie auf einem DEX mit dünner tREIT-Liquidität gegen einen liquideren Token und geht davon. Das Protokoll bleibt mit einer Stablecoin-Verbindlichkeit zurück, die durch Sicherheiten gedeckt ist, die nun weniger wert sind als der Kredit.

Der interessante Teil ist, was als Nächstes passiert. Das Oracle aktualisiert schließlich am Samstagmittag und schreibt 0,78 Dollar. Liquidationen werden automatisch bei jeder Position oberhalb der LTV-Linie von 70 Prozent ausgelöst. Doch die DEX-Liquidität für tREIT ist inzwischen erschöpft, und die Liquidator-Bots können nur noch zu 0,55 Dollar ausführen, weil sie in einen einseitigen Markt verkaufen. Im Protokoll entstehen faule Schulden. rUSD verliert seine Bindung. Inhaber lösen rUSD über das Protokoll zum Nennwert ein und leeren dabei den Rest der Treasury. Der Verlust weitet sich in etwa zwölf Stunden von einem einzigen veralteten NAV zu einem Stablecoin-Ausfall aus.

Jeder Schritt in diesem Szenario ist grundsätzlich vermeidbar, und fast jede Prävention bringt Reibung, Latenz oder Governance-Komplexität mit sich, die ein RWA-Emittent lieber nicht hätte.

Die zwei Arten von RWA-Orakeln: marktbasiert versus NAV-basiert

RWA-Protokolle haben im Grunde zwei Möglichkeiten, Preise zu beziehen, und diese Wahl ist folgenreicher als der Markenname des Oracle-Anbieters.

Marktbasierte Orakel

Ein marktbasiertes Oracle aggregiert Preise von Handelsplätzen, an denen der Vermögenswert tatsächlich gehandelt wird. Chainlink ist hier das etablierteste Netzwerk und nutzt ein Netzwerk unabhängiger Node-Betreiber, die Preise von mehreren zentralisierten und dezentralisierten Börsen abrufen, sie off-chain aggregieren und einen Medianwert oder volumengewichteten Wert on-chain übertragen. Pyth verfolgt einen anderen Ansatz, bezieht Preise direkt von Market Makern und Börsen auf Opt-in-Basis und veröffentlicht sie mit Latenzen unter einer Sekunde auf Solana und anderen Chains.

Für eine tokenisierte T-Bill wie BUIDL, die an einigen wenigen whitelisted Handelsplätzen gehandelt wird, kann ein marktbasiertes Oracle funktionieren, aber das Volumen an diesen Handelsplätzen ist der Engpass. Wenn ein Manipulator während einer asiatischen Nachtsitzung BUIDL im Wert von 5 Millionen Dollar an einem einzigen Handelsplatz verkauft, kann sich der Oracle-Median bewegen, bevor Arbitrage die Lücke schließt. Das Design von Pyth schützt teilweise davor, indem Publisher gewichtet und Mindestzahlen an Publishern verlangt werden, aber der Schutz ist statistisch, nicht absolut.

Die klassische Fallstudie hierzu ist Mango Markets im Jahr 2022, als ein Angreifer den Preis von MNGO-PERP an einer einzigen Börse aufblähte, den erhöhten Preis als Sicherheit nutzte, um die gesamte Treasury leerzuleihen, und rund 114 Millionen Dollar abzog. Der Preisfeed funktionierte technisch. Er las nur einen einzigen Handelsplatz aus, dessen Volumen der Angreifer kontrollierte.

NAV-basierte Orakel

Ein NAV-basiertes Oracle betrachtet dagegen keine Trades. Es veröffentlicht den eigenen Nettoinventarwert des Emittenten, der meist aus Bewertungen, Berichten des Fondsadministrators oder Mark-to-Model-Bilanzierung berechnet wird. Für einen illiquiden Vermögenswert wie einen tokenisierten Immobilienfonds oder eine Private-Credit-Note ist der NAV oft die einzige ehrliche Antwort, weil es keinen kontinuierlichen Markt gibt, aus dem man lesen könnte.

Der Preis dafür ist, dass NAV-Aktualisierungen langsam erfolgen. Eine wöchentliche oder tägliche Aktualisierung bedeutet, dass der on-chain Preis im besten Fall 24 Stunden alt ist. In diesem Zeitfenster ist jeder off-chain Informationsvorsprung ausnutzbar. Der Synthetix sUSD-Vorfall von 2019, auch wenn er der meisten RWA-Infrastruktur vorausging, ist anschaulich: Ein Oracle-Feed für den koreanischen Won lieferte einen marktfernen Kurs, und Trader leerten das System, bevor der Feed korrigiert wurde. Die Architektur hat sich verbessert, aber das grundlegende Problem bleibt bestehen, dass ein einzelner vertrauenswürdiger Publisher zu einem Single Point of Failure wird.

NAV-basierte Feeds versagen auch auf Arten, wie Marktfeeds es nicht tun. Der Publisher kann pausieren. Der Publisher kann der Emittent selbst sein, was offensichtliche Fragen zu Interessenkonflikten aufwirft. Der Signaturschlüssel des Publishers kann kompromittiert werden. Der Fondsadministrator kann ein Rücknahmefenster verpassen. Nichts davon ist im technischen Sinne Preismanipulation, aber für das Protokoll sieht alles gleich aus: Das Oracle hört auf, sich zu aktualisieren, oder aktualisiert auf eine Zahl, an die niemand glaubt.

Historische Fälle von Oracle-Manipulation, mit RWA-Kontext

Die Geschichte der Oracle-Manipulation in der Kryptoindustrie liest sich wie ein Katalog wiederholter Lektionen. bZx wurde 2020 zweimal durch Oracle-Manipulation bei geringer Liquidität ausgenutzt, wodurch über beide Vorfälle hinweg rund eine Million Dollar abgezogen wurden. Harvest Finance verlor im Oktober 2020 24 Millionen Dollar durch eine Stablecoin-Curve-Arbitrage, die durch Oracle-Timing angetrieben wurde. Cream Finance verlor im Oktober 2021 130 Millionen Dollar durch eine Preis-Oracle-Manipulation, die ein Sicherheitstoken mit einer überhöhten Referenz bewertete.

Der Mango Markets-Exploit im Jahr 2022 war die klarste Demonstration des Musters: ein Preisfeed von einem einzigen Handelsplatz, ein Manipulator mit Kapital und ein Lending-Protokoll, das dem Feed vertraute, ohne das Volumen zu prüfen. Avraham Eisenbergs Verteidigung vor Gericht lautete, er habe gehandelt, nicht gehackt. Die Jury sah das anders. Die 114 Millionen Dollar waren real.

Im RWA-spezifischen Bereich brachte 2024 stillere, aber lehrreiche Fälle. Ein tokenisiertes Private-Credit-Protokoll erlitt ein teilweises Bad-Debt-Ereignis, als sein NAV-Oracle Positionen weiterhin zum Nennwert bewertete, obwohl der zugrunde liegende Emittent bereits eine Restrukturierung beantragt hatte. Ein tokenisierter Geldmarktfonds erlebte eine vorübergehende Entkopplung, als seine Verwahrbank Rücknahmen für eine AML-Prüfung pausierte, wodurch der on-chain Preis unverändert blieb, während off-chain Inhaber auf Ausstiege warteten. Keines der Ereignisse war im rechtlichen Sinne ein Hack. Beide führten zu realen Verlusten für Protokollnutzer.

Die Lehre ist nicht, dass Oracles einzigartig schlecht sind. Die Lehre ist, dass Oracle-Manipulation eine Angriffskategorie ist, kein einzelner Bug, und dass RWA-Protokolle jede Variante dieser Kategorie erben, plus einige neue, die mit Verwahrung und Emittenten-Governance verbunden sind.

Warum ein Oracle mit 1 Basispunkt trotzdem Geld verliert

Marketingtexte für institutionelle RWA-Produkte rühmen sich oft mit der Präzision von Oracles. Der on-chain Preis wird auf den nächsten Basispunkt aktualisiert, also 0,01 Prozent, in manchen Fällen genauer als der Anleihemarkt selbst. Das ist real, beantwortet aber die falsche Frage.

Eine tokenisierte T-Bill mit einem perfekt genauen Oracle verliert trotzdem Geld, wenn der Verwahrer, der die zugrunde liegenden Treasuries hält, ausfällt. Das klassische Beispiel ist der Vorfall im Oktober 2023, bei dem ein kleiner institutioneller Krypto-Verwahrer Auszahlungen pausierte. Tokenisierte T-Bill-Produkte mit diesem Verwahrer als einzigem Unterverwahrer sahen, wie ihr NAV stagnierte, weil die zugrunde liegenden Vermögenswerte nicht zurückgegeben werden konnten. Oracle-Präzision spielte keine Rolle, weil die Präzision auf eine Zahl angewendet wurde, die niemand unabhängig verifizieren konnte.

Dieselbe Logik gilt für tokenisierte Immobilien, tokenisierte Private Credit und tokenisierte Rohstoffe. Das Oracle sagt dir, was der Vermögenswert wert ist. Es sagt dir nicht, ob der Vermögenswert noch existiert, weiterhin dem Token-Inhaber gehört, auf Verlangen zurückgegeben werden kann oder einem Rechtsanspruch unterliegt. Das sind Verwahrungs- und Rechtsfragen, und sie liegen vollständig außerhalb des Smart Contract.

Für Risikoverantwortliche bedeutet das, dass eine Oracle-Prüfung notwendig, aber nicht ausreichend ist. Die vollständige Prüfung lautet Verwahrung, dann Oracle, dann Governance, dann rechtliche Durchsetzbarkeit des Tokens gegenüber dem zugrunde liegenden Vermögenswert, ungefähr in dieser Reihenfolge.

Wie Hashgraph-Konsens und das Canton Network das Problem angehen

Die meisten RWA-Oracle-Designs behandeln den Preisfeed als Datenproblem: Wer übermittelt die Zahl, wie oft, und wie vertrauen wir ihnen. Hashgraph-Konsens und das Canton Network behandeln ihn stattdessen als Koordinationsproblem. Der Unterschied ist architektonisch, nicht nur Branding.

Hashgraph-Konsens, das zugrunde liegende Protokoll für das Hedera-Netzwerk und eine Grundlage für das HASH-Ökosystem, ist ein byzantinisch fehlertolerantes Gossip-Protokoll mit asynchroner Byzantine Fault Tolerance und Finalität in Sekunden. Für RWA-Anwendungsfälle ist die relevante Eigenschaft nicht rohe Geschwindigkeit, sondern deterministische Finalität mit verifizierbaren Zeitstempeln. Ein Oracle-Feed, der auf einem hashgraph-basierten Netzwerk veröffentlicht wird, trägt einen Konsens-Zeitstempel, dem alle Teilnehmer zustimmen, was es im Nachhinein erschwert zu behaupten, ein Preis sei zu einem bestimmten Zeitpunkt nicht der Konsenspreis gewesen.

Das Canton Network verfolgt einen radikaleren Ansatz. Anstelle einer einzigen globalen Chain mit einem einzigen Preisfeed ist Canton ein Netzwerk interoperabler Subnetze, von denen jedes ein permissioned Ledger sein kann, das von regulierten Institutionen betrieben wird. Die Synchronizer-Komponente koordiniert atomare Transaktionen über Subnetze hinweg, ohne sie zu zwingen, eine einzige Ausführungsumgebung zu teilen. Für ein RWA-Oracle bedeutet das, dass der Preisfeed überhaupt nicht auf einer öffentlichen Chain veröffentlicht werden muss. Die Bank, die die zugrunde liegenden Treasuries hält, der Fondsadministrator, der den NAV berechnet, der Verwahrer und das DeFi-Protokoll, das den Preis nutzt, können alle ihre eigenen Subnetze betreiben und den Synchronizer verwenden, um sich atomar auf einen Preis zusammen mit einer verwandten Transaktion zu einigen, etwa einem Token-Mint oder einer Sicherheitenprüfung.

Der praktische Effekt besteht darin, das Oracle-Problem vollständig von der öffentlichen Chain weg in eine private Koordinationsschicht zu verlagern, in der jeder Teilnehmer identifiziert ist und der Rechtsweg intakt bleibt. Das ist keine universelle Lösung. Sie erfordert institutionelle Zusammenarbeit und die Bereitschaft, innerhalb eines permissioned Frameworks zu arbeiten. Aber für große RWA-Deployments, bei denen der Vermögenswert ein reguliertes Wertpapier ist und die Teilnehmer bekannte Einheiten sind, entfernt sie mehrere Kategorien von Oracle-Angriffen, indem sie die Preisoberfläche der öffentlichen Chain beseitigt.

Was Risk Officers tatsächlich tun sollten

Für jemanden, der eine RWA-Integration bewertet, sind die Fragen nicht abstrakt. Sie sind konkret, und die meisten von ihnen haben unbequeme Antworten.

Fragen Sie zuerst, welche Art von Oracle das Protokoll verwendet und ob der Vermögenswert tatsächlich kontinuierlich an den Handelsplätzen gehandelt wird, die das Oracle ausliest. Wenn die Antwort NAV-basiert ist, fragen Sie, wer ihn veröffentlicht, wie oft und welche Richtlinie für außerplanmäßige Aktualisierungen gilt. Wenn die Antwort ausbleibt, gehen Sie vom Schlimmsten aus.

Fragen Sie zweitens, was bei einem Oracle-Ausfall passiert. Pausiert das Protokoll? Greift es auf einen konservativen Preis zurück, etwa das letzte Update abzüglich eines Abschlags? Erlaubt es neue Kreditaufnahmen gegen den veralteten Preis? Die Exploits von Mango und bZx funktionierten beide, weil das Protokoll während der Manipulation weiterlief. Ein gut konzipiertes Protokoll sollte ein veraltetes Oracle als Notfall behandeln.

Fragen Sie drittens nach der Verwahrung. Wer hält den zugrunde liegenden Vermögenswert? Ist der Verwahrer segregiert? Gibt es eine insolvenzferne Struktur? Hat der Verwahrer jemals Auszahlungen pausiert? Ein 1-Basispunkt-Oracle auf einer Verwahrstruktur, die Rücknahmen einfrieren kann, ist kein 1-Basispunkt-System.

Fragen Sie viertens nach der Governance. Wer kann die Oracle-Quelle ändern? Wer kann den Feed pausieren? Wer kann den Preis manuell aktualisieren? In einer permissioned RWA-Bereitstellung ist Governance das Oracle, und die Antworten bestimmen, welcher Art von Angriff das Protokoll ausgesetzt ist.

Bemessen Sie schließlich das Engagement entsprechend. Selbst ein gut konzipiertes RWA-Protokoll kann auf Arten scheitern, die keine Oracle-Prüfung vorhersagen würde. Die Grenzfälle von 2024 betrafen alle Emittenten, Verwahrer oder Gegenparteien, die unerwartete Dinge taten. Diversifikation über RWA-Emittenten und Oracle-Typen hinweg verringert die Wahrscheinlichkeit, dass ein einzelner Ausfall durch ein Portfolio kaskadiert.

Bleiben Sie RWA-Oracle-Risiken mit strukturierten Signalen einen Schritt voraus

RWA-Oracle-Manipulationen bewegen sich schneller, als ein einzelner Analyst sie verfolgen kann. Neue Exploits, neue Pausen bei Verwahrern, neue NAV-Streitigkeiten und neue Governance-Vorschläge erscheinen wöchentlich, und die meisten davon sind in Governance-Foren, Gerichtsunterlagen oder Post-Mortems verborgen, die in sozialen Medien nicht zum Trend werden. Zippfeed zeigt RWA-Schlagzeilen mit Sentiment-Bewertung an und kennzeichnet jede Meldung als bullish, neutral oder bearish, je nachdem, ob die Nachricht auf ein gesünderes oder schwächeres zugrunde liegendes Protokoll hindeutet, sowie mit einer Wichtigkeitsbewertung, die die Meldungen hervorhebt, die am ehesten Preise bewegen oder Liquidationen auslösen. Diese Kombination ermöglicht es Risk Officers und fortgeschrittenen Tradern, frühe Signale eines Oracle- oder Verwahrproblems zu erkennen, bevor der On-Chain-Preis es widerspiegelt.