Am 15. Juli 2026 verlor die Perp-DEX Ostium — eine dezentrale Börse für Perpetual-Futures auf Arbitrum — einen zweistelligen Millionenbetrag aus ihrem Liquiditäts-Topf. Erste On-Chain-Schätzungen reichen von rund 18 bis knapp 24 Millionen USDC; die genaue Zahl wird noch bestätigt. Das Bemerkenswerte daran: Kein Smart Contract war fehlerhaft. Die Kryptografie hielt. Das Protokoll wurde nicht überlistet, weil sein Code kaputt war, sondern weil es falschen Daten glaubte. Genau das ist Oracle-Manipulation, und sie ist einer der teuersten wiederkehrenden Fehler in DeFi.

Was ein Oracle ist — der Bote-Vergleich

Ein Smart Contract ist blind für die Außenwelt. Er weiß von sich aus nicht, was Gold, der Ölpreis oder ein Aktienindex gerade kosten. Ein Oracle ist der Bote, der ihm diese Zahl zuruft. Und ein Vertrag, der dem Boten blind glaubt, zahlt nach jeder Zahl aus, die der Bote nennt — auch nach einer erfundenen.

Der Angreifer bei Ostium hat nicht den Tresor geknackt. Er hat den Boten bestochen.

Was bei Ostium geschah

Laut der Sicherheitsfirma Blockaid, die den Vorfall zuerst meldete, lag die Ursache nicht in Ostiums Kern-Verträgen, sondern im Schlüssel, mit dem die Preise signiert werden. Wer diesen Schlüssel hat, kann dem Protokoll beliebige Preise als „echt" verkaufen.

Der Ablauf, vereinfacht: Der Angreifer besaß den Oracle-Signer-Schlüssel und einen automatisierten Baustein (einen „PriceUpKeep-Forwarder"), der Preis-Updates selbst einspielen kann. In einer einzigen Transaktion öffnete er eine Position zum echten Marktpreis, spielte dann eine zukunftsdatierte Preismeldung ein, die einen fetten Gewinn vortäuschte, und schloss die Position sofort wieder. Diese Schleife wiederholte er rund zehn- bis zwanzigmal und stapelte den erfundenen Gewinn Runde um Runde auf. Ausgezahlt wurde aus dem Vault, dem Liquiditäts-Topf, aus dem Ostium die Gewinne seiner Händler bedient — abgeflossen sind grob 28 bis 33 Prozent der rund 63 Millionen, die dort lagen.

Kein einziger dieser Trades hat je echtes Geld verdient. Das Protokoll hat für Gewinne bezahlt, die es nie gab.

Was Ostium richtig gemacht hat

Fairerweise gehört das dazu, sonst baut man eine Strohpuppe. Nach Angaben des Gründers dauerte der Angriff nur fünf Minuten (14:18 bis 14:23 UTC). Das Team bemerkte die ungewöhnliche Aktivität kurz danach und pausierte binnen einer Stunde den gesamten Handel. Es kommunizierte den Vorfall offen und arbeitet mit Sicherheitsfirmen und Behörden an der Aufklärung. Und: Es war kein Loch im Kern-Code — Ostium ist auditiert und von namhaften Kapitalgebern finanziert. Genau das ist der Punkt.

Der eigentliche Punkt: falsche Daten, nicht kaputte Kryptografie

Audits prüfen den Code der Verträge. Sie prüfen nicht den Schlüssel, mit dem draußen die Preise signiert werden, und nicht die Automatik, die diese Preise einspielt. Ein Protokoll kann fehlerfrei programmiert sein und trotzdem alles auszahlen — wenn die Daten, auf die es hört, falsch sind.

Und das ist kein Einzelfall, sondern ein Muster. Die häufigsten Arten, wie in DeFi mit Oracles und falschen Daten etwas schiefgeht:

Der gemeinsame Nenner: Die Maschinerie, die den Preis liefert, wird per Voreinstellung vertraut. Wer sie kontrolliert, lässt das Protokoll für Trades zahlen, die nie Geld verdient haben.

Warum das an zwei frühere Stücke anschließt

Wir haben diese Familie schon zweimal beschrieben. In Is Crypto Safe? Why Crypto Looks Less Secure Than It Is war der Kern: Es bricht fast nie die Kryptografie, sondern die Peripherie — Schlüssel, Oberflächen, Menschen. Ostium fügt dieser Landkarte eine Schicht hinzu: die Oracle-Schicht, die Daten-Zufuhr. Und sie bestätigt die These. Nicht der Vertrag brach, sondern der Schlüssel, der die Daten signiert.

Und in When a Lego Brick Falls: der KelpDAO-Hack und Konzentrationsrisiko ging es um den einen vertrauten Punkt, der alles mitreißt — dort ein Verifizierer, der auf 1-von-1 stand, wo eigentlich mehrere hätten zustimmen müssen. Ostiums Oracle-Signer ist derselbe Gedanke: ein einziger Schlüssel, dem das ganze System glaubt.

Der rote Faden: Datenintegrität

Wir verbringen unsere Tage damit, dafür zu sorgen, dass ein Backtest sich nicht von Daten täuschen lässt, die im Rückblick anders aussehen — look-ahead-frei, zeitpunktgenau. Ein Oracle-Hack ist dieselbe Lektion mit einem Gegner davor: Ein System, das falsche Daten frisst, produziert selbstbewusst ein katastrophales Ergebnis. Bei uns kostet das eine falsche Kennzahl. Bei Ostium kostet es den Topf.

Ehrlich bleibt: Einen gestohlenen Schlüssel kann kein Backtest verhindern. Aber die Marktfolgen solcher Schocks lassen sich prüfen. Wie sich eine Strategie durch die Stress-Phasen bewegt, die auf Hacks und Vertrauensbrüche folgen, ist testbar — auf echter Historie, über mehrere Marktregime. Miss die Angriffsfläche, nicht die Schlagzeile.

Häufige Fragen

War der Ostium-Hack ein Fehler im Smart Contract? Nein. Nach Angaben von Blockaid lag die Ursache nicht im Kern-Code, sondern in einem kompromittierten Oracle-Signer-Schlüssel plus einer Automatik, die zukunftsdatierte Preise einspielte.

Was ist Oracle-Manipulation? Ein Angreifer bringt ein Protokoll dazu, einen falschen Preis für echt zu halten — indem er den Schlüssel stiehlt, der Preise signiert, den Kurs an der Quelle bewegt oder das Datum der Meldung fälscht. Der Vertrag zahlt dann nach einer Zahl aus, die nie stimmte.

Schützt ein Audit davor? Nur begrenzt. Ein Audit prüft den Code der Verträge, nicht die Schlüssel und die Daten-Zufuhr außerhalb davon. Ostium war auditiert.

Dieser Beitrag ist eine Einordnung, keine Sicherheits- oder Anlageberatung.

Study the Past — Improve your Future. 🥋