Venus-Thena-(THE-)Vorfall: Was kaputtging und was übersehen wurde

Am 15. März 2026 umging ein Angreifer das ‚Supply Cap‘ (Einzahlungslimit) des THE (Thena)-Marktes im Core Pool des Venus-Protokolls (BNB Chain), blähte eine Besicherungsposition auf das 3,67-fache des vorgesehenen Limits auf und lieh sich Vermögenswerte in Höhe von ca. 14,9 Mio. $ [1]. Frühe Medienberichte stellten dies als einen Exploit in Höhe von ca. 3,7 Mio. $ dar, doch das On-Chain-Bild ist komplexer: Sowohl das Protokoll als auch der Angreifer verloren am Ende Geld.

Der eigene Post-Mortem-Bericht von Venus [1] sowie mehrere frühere Analysen [2, 3, 4] haben den Angriffsmechanismus im Detail seziert und die Umgehung des Supply Caps, den Spenden-Angriffsvektor sowie den grundlegenden Geldfluss abgedeckt. Dieser Artikel wiederholt diese Grundlagen nicht. Stattdessen untersucht er die On-Chain-Gewinn-und-Verlust-Situation sowohl für das Protokoll als auch für den Angreifer und konzentriert sich dabei auf die systemischen Risiken, die durch die Defensivmechanismen von Kreditprotokollen aufgedeckt wurden.

Durch die Analyse des Angriffs- und Liquidationsprozesses sowie die Nachverfolgung des vollständigen Geldflusses stellt dieser Artikel fest, dass 254 Liquidations-Bots über 8.048 Transaktionen hinweg um die Abwicklung der Position konkurrierten, dennoch verblieben uneinbringliche Forderungen (Bad Debt) von 2,15 Mio. $ [1]. Die Liquidation wurde ausgelöst, reichte jedoch nicht aus. Der Angreifer investierte 9,92 Mio. $ und behielt nach allen Liquidationen nur ca. 5,2 Mio. $, was einem On-Chain-Nettoverlust von ca. 4,7 Mio. $ entspricht. Diese Ergebnisse zeigen, wie alle drei Verteidigungslinien in Kreditprotokollen unter echtem Stress versagten, während auf aufkommende Frühwarnsignale nicht effektiv reagiert werden konnte. Dies offenbart die Grenzen bestehender Sicherheitsvorkehrungen und unterstreicht die Notwendigkeit für die Community, aus diesem Vorfall zu lernen und ihre Überwachungs- sowie Frühwarnfähigkeiten zu stärken.

Hintergrund

Supply Caps (Einzahlungslimits) sind eine Standard-Risikokontrolle in Kreditmärkten im Compound-Stil. Sie begrenzen, wie viel von einem bestimmten Vermögenswert als Sicherheit hinterlegt werden kann, und setzen der Exposition des Protokolls gegenüber volatilen oder wenig liquiditätsstarken Token eine Obergrenze. Venus setzte für seinen THE-Markt ein Supply Cap von 14,5 Mio. THE fest, was die geringe On-Chain-Liquidität des Tokens widerspiegelt.

Hinter dem Supply Cap liegen zwei zusätzliche Sicherheitsebenen. Die auf Orakeln basierende Bewertung der Sicherheiten bestimmt, wie viel ein Kreditnehmer gegen seine Einzahlungen aufnehmen kann. Wenn eine Position unterbesichert ist, wird erwartet, dass ein kompetitiver Liquidationsmarkt eingreift: Drittanbieter-Bots tilgen die Schulden und beschlagnahmen die Sicherheiten mit einem Abschlag, wodurch die Solvenz des Protokolls gewahrt bleibt.

Diese Drei-Schichten-Struktur (Expositionslimits, Bewertung, Liquidation) bildet das Risikorahmenwerk für die meisten Kreditprotokolle. Der Venus THE-Vorfall testete alle drei Ebenen gleichzeitig, und alle drei erwiesen sich als unzureichend. Die folgenden Abschnitte untersuchen, wie jede Ebene getestet wurde und wo sie versagte.

Der Angriff

Die Umgehung: Der Spenden-Angriff (Donation Attack)

Supply Caps beschränken in den meisten Compound-Forks nur den Mint-Pfad: die Standard-Einzahlungsfunktion, die das Limit prüft, bevor vTokens ausgegeben werden. Sie berücksichtigen keine Token, die direkt an die Vertragsadresse gesendet werden.

Der Angreifer nutzte diese Lücke aus. Eine direkte ERC-20-Überweisung an den vTHE-Vertrag erhöht den zugrundeliegenden Token-Bestand des Vertrags, ohne neue vTokens zu prägen. In der Buchhaltung im Compound-Stil bläht dies den exchangeRate-Wechselkurs zwischen vTokens und dem Basiswert auf. Jeder bestehende vToken-Inhaber profitiert: Ihre vTokens stellen nun einen Anspruch auf mehr zugrundeliegende Token dar, was ihren effektiven Sicherheitenwert aus Sicht des Protokolls erhöht.

Dieser „Spenden-Angriff“ ist eine bekannte Schwachstellenklasse in Compound-Forks. Jedes Protokoll, das Supply Caps nur auf dem Mint-Pfad durchsetzt, ist anfällig: Die tatsächliche Exposition gegenüber dem Basiswert kann das Limit bei weitem überschreiten, ohne eine Grenzwertprüfung auszulösen.

Vorbereitung (Juni 2025 bis März 2026)

Der Angriff begann nicht am 15. März. Der Angreifer erhielt 7.447 ETH über Tornado Cash mittels einer Finanzierungsadresse (0x7a79...f234), hinterlegte die ETH bei Aave als Sicherheit und lieh sich 9,92 Mio. $ in Stablecoins (USDT, DAI, USDC). Diese Gelder wurden auf mehrere Wallets verteilt, um ab Juni 2025 THE zu kaufen, wobei schrittweise eine kombinierte Position aufgebaut wurde, die am Morgen des Angriffs 84 % des Supply Caps (ca. 12,2 Mio. THE) erreichte.

Die kumulative vTHE-Position des Angreifers (Juni 2025 bis März 2026). Allmähliche Akkumulation über 9 Monate, gefolgt von einer vollständigen Liquidation.

Dieser neunmonatige Vorbereitungszeitraum war die gesamte Zeit über on-chain sichtbar. Nach jeder Einzahlung war der On-Chain-Status des Protokolls (Gesamtangebot, Konzentration der Position im Verhältnis zum Cap) öffentlich abfragbar. Jede einzelne Transaktion war jedoch routinemäßig und löste keine herkömmlichen Warnungen aus. Die Erkennung dieser Art von Risiko erfordert eine kontinuierliche Überwachung von Statusänderungen auf Protokollebene – ein Bereich, in dem Protokoll-Sicherheitsrahmen verbessert werden müssen.

Der Angreifer operierte über mehrere Adressen, die alle auf eine einzige Tornado-Cash-Finanzierungsquelle zurückzuführen sind:

Ausführung (15. März 2026)

Um 11:00 UTC hielt der Angreifer 12,2 Mio. THE innerhalb des Protokolls, immer noch innerhalb des 14,5-Mio.-Limits. Gegen 11:55 UTC setzte der Angreifer den Angriffsvertrag ein (0x4f477e...f5663f) [1] und führte die Spenden-Umgehung sowie das erste Leihen atomar im Konstruktor aus. Sechs Wallets überwiesen insgesamt ca. 36 Mio. THE direkt an den vTHE-Vertrag, was den Wechselkurs um das 3,81fache in die Höhe trieb. Der Angriffsvertrag, dem die Erlaubnis erteilt worden war, gegen die Position von 0x1a35 zu leihen, lieh sich daraufhin Vermögenswerte gegen die aufgeblähten Sicherheiten.

Von ca. 12:00 bis 12:42 UTC führten beide Adressen Folge-Transaktionen in einer rekursiven Leverage-Schleife aus [1]:

1. Leihen von Vermögenswerten gegen die aufgeblähten Sicherheiten (CAKE, BNB, BTCB, USDC)
2. Tausch der geliehenen Vermögenswerte in THE auf dem offenen Markt
3. Spende von THE an den vTHE-Vertrag, was den Wechselkurs weiter in die Höhe trieb und den Preis nach oben drückte
4. Wiederholung mit erhöhter Kreditkraft

Zeitplandaten stammen aus dem Venus-Post-Mortem [1].

Aufgrund der extrem geringen On-Chain-Liquidität von THE verursachten selbst bescheidene Käufe erhebliche Auswirkungen auf den Preis. Der aggregierte Marktpreis von THE schoss von ca. 0,26 $ auf über 0,53 $ (laut CoinMarketCap). Das Resilient Oracle von Venus (RedStone primär, Binance als Pivot) wies den sprunghaften Anstieg anfangs ab: Ab ca. 11:55 UTC setzte der BoundValidator für etwa 37 Minuten aus, da der Binance-Feed stark abwich und fast 4 $ erreichte [1]. In diesem Fenster konnte das Orakel den Preis von THE nicht aktualisieren. Da der Angreifer den Kaufdruck über mehrere Plattformen in der Aggregation von RedStone aufrechterhielt, konvergierten schließlich beide Feeds auf dem erhöhten Niveau um ca. 12:32 UTC. Das Resilient Oracle akzeptierte den Preis bei ca. 0,51 $ [1], und das Protokoll begann, die Sicherheiten des Angreifers zum manipulierten Kurs zu bewerten.

Preisschwankungen des THE-Tokens vor und nach dem Angriff.

Die kombinierte Wirkung der Wechselkursaufblähung (3,81x durch Spende) und der Preismanipulation (0,26 $ → 0,51 $) vervielfachte die Kreditkraft des Angreifers etwa siebenfach. Doch die reale Markttiefe von THE war nur ein Bruchteil dieses vom Orakel gemeldeten Wertes.

Überdehnung und Zusammenbruch (ab ca. 12:42 UTC)

Nach der Extraktion der ersten Runde geliehener Vermögenswerte hätte der Angreifer aufhören können. Stattdessen setzten sie die geliehenen Mittel weiterhin ein, um mehr THE zu kaufen, in dem Versuch, eine weitere Preisrallye zu erzwingen. Dies drückte den Gesundheitsfaktor (Health Factor) nahe an 1 [1]. Um 12:42 UTC erreichte die Position ihren Höhepunkt bei 53,2 Mio. THE.

Sobald der Kaufdruck nachließ, gab es nichts mehr, was den aufgeblähten Preis von THE stützte. Verkaufsdruck durch Liquidations-Bots und in Panik geratene Inhaber überwältigte die geringe Liquidität auf der Kaufseite, und der Preis von THE brach von ca. 0,51 $ auf etwa 0,22 $ ein [1] – weit unter den Wert vor dem Angriff von 0,26 $. Kaskadierende Liquidationen wickelten ca. 42 Mio. THE an Sicherheiten ab [1], und die letzte Verteidigungslinie des Protokolls wurde aktiviert: Drittanbieter-Liquidatoren schritten ein, um Verluste zu begrenzen.

Die Liquidationsrealität

In der DeFi-Kreditvergabe ist die Annahme einfach: Wenn Positionen unter Wasser geraten, greifen Drittanbieter-Liquidatoren ein, tilgen die Schulden, beschlagnahmen die Sicherheiten mit einem Abschlag und halten das Protokoll solvent. Der Venus THE-Vorfall hat diesen Mechanismus nicht gebrochen. Er hat seine Grenzen aufgezeigt.

Sie kamen. Es war nicht genug.

On-Chain-Liquidationsdaten (aus dem Dune-Dashboard von Venus [5], mit zusätzlicher Analyse auf Transaktionsebene) zeigen:

Das Dune-Dashboard verzeichnet 0x0870...cf43 als Liquidator für alle Transaktionen. Diese Adresse ist der Core Pool Liquidator-Vertrag von Venus, ein erlaubnisfreier Einstiegspunkt, über den jeder externe Aufrufer Liquidationen ausführen kann. Die Abfrage der tatsächlichen Transaktionssender zeigt 254 verschiedene Adressen, die über 8.048 Transaktionen hinweg um Liquidationsmöglichkeiten konkurrierten.

Von den 8.048 vTHE-Liquidations-Transaktionen zielten 8.039 auf die Hauptposition des Angreifers (0x1a35) ab; die restlichen 9 liquidierten vier nicht verbundene Nutzer mit kleinen vTHE-Beständen, die im Preissturz gefangen waren.

Die Teilnahme führte nicht zu einer vollständigen Wiederherstellung. Die Bots beschlagnahmten vTHE und tilgten Schulden in BNB, BTCB, CAKE, USDC und WBNB. Um Gewinne zu erzielen, mussten sie diese THE auf dem offenen Markt verkaufen. Da 53 Mio. THE gerade in einen Markt mit nur wenigen Millionen Dollar Tiefe geworfen worden waren, konnten die beschlagnahmten Sicherheiten nicht ohne massive Slippage in stabilen Wert umgewandelt werden. Das Ergebnis: Schulden in Höhe von 2,15 Mio. $ konnten nicht gedeckt werden und wurden zu uneinbringlichen Forderungen auf der Bilanz von Venus.

Zwei Positionen, zwei Ergebnisse

Der Angreifer betrieb zwei Positionen mit unterschiedlichen Sicherheitstypen [2]. Beide erfüllten komplementäre Rollen: 0x1a35 war die primäre Position, die über neun Monate THE ansammelte und wertvolle Vermögenswerte gegen die aufgeblähten Sicherheiten lieh, während 0x737b der Angriffsvertrag war, der die Spenden-Umgehung atomar ausführte und THE lieh (unter Verwendung von USDC als Sicherheit), um den Wechselkurs weiter in die Höhe zu treiben. Ihre Liquidationsergebnisse unterschieden sich sowohl in Zeitpunkt als auch Mechanismus:

Die 0x737b-Position wurde zuerst liquidiert, beginnend um 12:04 UTC während der Pump-Phase [2]. Ihre Sicherheit bestand aus 1,58 Mio. USDC (fester Wert), während ihre Schulden auf THE lauteten. Die Position wurde mit minimaler Marge bei THE ~0,26 $ angelegt. Als der Angreifer weiterhin THE an DEX kaufte und deren Marktpreis in Richtung ~0,51 $ pumpte, überstieg der THE-Schuldenwert die USDC-Sicherheit bei weitem, wodurch die Liquidation ausgelöst wurde. Die Liquidatoren beschlagnahmten die USDC, aber selbst nach 603 Transaktionen konnten die beschlagnahmten Sicherheiten die THE-Schulden nicht vollständig decken, wodurch ca. 1,85 Mio. THE (~359.000 $) unbezahlt blieben [1]. Dies war wahrscheinlich beabsichtigt: Der Zweck von 0x737b war es, THE für die Spenden-Umgehung zu leihen, und sobald diese Mission abgeschlossen war, war der Verlust der USDC-Sicherheit ein akzeptabler Preis.

Die 0x1a35-Liquidation erzählt die wahre Geschichte. Ihre Sicherheit war THE selbst. 254 Bots konkurrierten darum, sie über 8.039 Transaktionen zu liquidieren, aber das beschlagnahmte THE konnte zu keinem auch nur annähernd vom Orakel gemeldeten Wert verkauft werden. Der Zeitplan zeigt die Dynamik:

Beide Positionen trugen zu den Verlusten des Protokolls bei: ~359.000 $ aus den ungedeckten THE-Schulden von 0x737b und der Rest aus den illiquiden THE-Sicherheiten von 0x1a35. Von den insgesamt ca. 14,9 Mio. $, die von Venus geliehen wurden [1], konnten die Liquidatoren das meiste wiederherstellen. Die verbleibenden ~2,15 Mio. $ wurden zu uneinbringlichen Forderungen auf der Bilanz von Venus.

Ein Hinweis zu den von Dune abgeleiteten Zahlen: Das Venus Dune-Dashboard [5] bewertet beschlagnahmte Sicherheiten und getilgte Schulden unter Verwendung täglicher Snapshot-Preise aus seiner daily_market_info-Tabelle. Da der Preis von THE im Tagesverlauf von ~0,53 $ auf 0,22 $ abstürzte, können die von Dune abgeleiteten USD-Zahlen (einschließlich der stündlichen Aufschlüsselung oben und der einnahmenseitigen Zahlen im folgenden Abschnitt) von Echtzeitwerten abweichen. Wo offizielle Zahlen verfügbar sind (insgesamt geliehen ~14,9 Mio. $, Bad Debt ~2,15 Mio. $ [1]), verwenden wir diese als maßgebliche Quelle. Während absolute USD-Werte variieren können, bleiben die zugrunde liegenden Trends und Schlussfolgerungen konsistent.

Dem Geld folgen

Die Liquidationsdaten zeigen, wie die Positionen abgewickelt wurden. Um die tatsächliche Gewinn- und Verlustrechnung (P&L) des Angreifers zu verstehen, müssen wir über einzelne Transaktionen hinausblicken und vergleichen, was der Angreifer investiert hat und was er nach Abschluss aller Liquidationen behalten hat.

Was investiert wurde

Die Finanzierungskette des Angreifers: 7.447 ETH, die über Tornado Cash empfangen, bei Aave als Sicherheit hinterlegt, 9,92 Mio. $ in Stablecoins (USDT, DAI, USDC) geliehen und über neun Monate auf mehrere Wallets verteilt wurden, um THE und vTHE zu erwerben. Die gesamten 9,92 Mio. $ wurden in THE-Positionen auf Venus umgewandelt. Nach dem Angriff wurden alle THE-Sicherheiten liquidiert und dieses Investment wurde effektiv ausgelöscht.

Was von Venus geliehen wurde

Zum Höhepunkt (12:42 UTC) hatte der Angreifer insgesamt ca. 14,9 Mio. $ bei Venus geliehen [1]:

Nicht alle geliehenen Vermögenswerte wurden als Gewinn extrahiert. Ein erheblicher Teil wurde in den Angriff zurückgeführt:

• 0x1a35 lieh wiederholt BNB von Venus, tauschte sie gegen THE und spendete die THE direkt an den vTHE-Vertrag, um den Preispump und die inflationäre Wechselkursentwicklung aufrechtzuerhalten [1].
• 0x737b führte während Phase 3 48 Transaktionen aus (Funktionssignatur 0x91f38bff). Zwei davon liehen und behielten wertvolle Vermögenswerte (CAKE, WBNB): 0x4253a8...eca296 und 0xfd64d0...154808. Der Rest waren Leihen-Tauschen-Spenden-Schleifen: Vermögenswerte von Venus leihen, in THE tauschen und die THE an den vTHE-Vertrag spenden.
• 1,58 Mio. USDC, geliehen von 0x737b, wurden sofort als eigene Sicherheit erneut bereitgestellt [1]. Diese USDC wurden später während der Liquidation beschlagnahmt und verließen das Protokoll nie.
• 4,63 Mio. THE, geliehen von 0x737b, wurden direkt an den vTHE-Vertrag gespendet, um den Wechselkurs in die Höhe zu treiben [1].

Was der Angreifer behielt

Nachdem beide Venus-Positionen liquidiert waren, überprüften wir die endgültigen Token-Bestände über alle vom Angreifer kontrollierten Adressen hinweg (via DeBank):

Die Aave-Position (7.447 ETH-Sicherheit, ~9,92 Mio. $ Schulden) bleibt offen und unverändert (Gesundheitsfaktor von 1,45). Die 9,92 Mio. $ in Stablecoins wurden auf die BNB Chain abgehoben und in THE umgewandelt, aber dies reduziert die Aave-Schulden nicht. Aus Sicht von Aave ist der Angreifer lediglich ein Kreditnehmer mit ausreichender Sicherheit. Der Angreifer behält den Zugang zu den ETH abzüglich der ausstehenden Schulden.

Netto-On-Chain P&L

Die On-Chain-Operation war eindeutig unrentabel. Von den ~14,9 Mio. $, die von Venus geliehen wurden, behielt der Angreifer nur ~5,21 Mio. $. Der Rest wurde entweder in THE-Spendenschleifen wiederverwertet, während der Liquidation beschlagnahmt oder als uneinbringliche Forderung des Protokolls verbucht.

Verluste des Protokolls

Nach Abschluss aller Liquidationen verblieben bei Venus ca. 2,15 Mio. $ an Bad Debt (uneinbringlichen Forderungen) [1]:

Wertverteilung

Bei einem typischen DeFi-Exploit erleidet das Protokoll oder der Liquiditätsanbieter (LP) einen Verlust, der Angreifer profitiert, und der „fehlende Wert“ zwischen beiden wird von Dritten wie Liquidatoren, Arbitrage-Händlern und Block-Buildern vereinnahmt. Dieser Vorfall bricht mit diesem Muster: Der Angreifer verlor ebenfalls Geld auf der Chain (~4,71 Mio. $). Ob dieser Verlust durch Off-Chain-Positionen (z. B. unbefristete Futures an zentralisierten Börsen [3, 4]) ausgeglichen wurde, bleibt unüberprüfbar.

Erkenntnisse: Drei Verteidigungslinien

Der Angriff nutzte eine bekannte Schwachstelle aus, verwendete eine klassische Leverage-Schleife und verursachte dennoch 2,15 Mio. $ an uneinbringlichen Forderungen. Das tatsächliche Versagen war nicht ein einzelner Mechanismus, sondern die kumulative Wirkung von Schwächen über den gesamten Risikostapel hinweg.

Erste Linie: Expositionslimits

Das Supply Cap von Venus beschränkte nur den Standard-Mint-Pfad. Direkte Token-Überweisungen an den vToken-Vertrag umgingen es vollständig. Jede Risikokontrolle, die auf buchhalterischen Annahmen beruht, muss diese Annahmen über alle möglichen zustandsverändernden Operationen hinweg validieren, nicht nur für den erwarteten Einzahlungsfluss.

Zweite Linie: Bewertung der Sicherheiten

Der vom Resilient Oracle gemeldete Preis (~0,51 $) lag nahe am aggregierten Marktpreis, und der BoundValidator wies den extremen Binance-Feed korrekt für 37 Minuten zurück [1]. Doch selbst ein „korrekter“ Marktpreis ist bedeutungslos für Sicherheiten im Wert von zig Millionen, wenn der zugrunde liegende Markt nur über eine Tiefe von wenigen Millionen Dollar verfügt [3]. Diese Position erlaubte dem Angreifer, ca. 14,9 Mio. $ an Vermögenswerten zu leihen [1]; dennoch konnten die THE-Sicherheiten bei der Liquidation nur einen Bruchteil ihres vom Orakel gemeldeten Wertes realisieren, was zu insgesamt 2,15 Mio. $ an uneinbringlichen Forderungen führte. Für illiquide Token bietet eine nominale Überbesicherung keinen echten Sicherheitsspielraum, wenn die Sicherheiten nicht zu Orakelpreisen verkauft werden können. Kreditprotokolle sollten eine liquiditätsbereinigte Besicherungsbewertung integrieren, die Markttiefe, erwartete Slippage und Konzentrationsrisiken berücksichtigt.

Dritte Linie: Liquidation

Das gesamte Kreditmodell geht davon aus, dass Liquidatoren einschreiten und das Protokoll ausgleichen, wenn Positionen unter Wasser geraten. Bei diesem Vorfall verarbeiteten 254 Liquidations-Bots 8.048 Transaktionen allein auf der vTHE-Position. Der Liquidationsmarkt war aktiv und kompetitiv. Dennoch reichte es nicht aus: 2,15 Mio. $ an uneinbringlichen Forderungen blieben bestehen. Das Problem war kein Mangel an Liquidatoren, sondern ein Mangel an Liquidität. Als 53 Mio. THE auf einen Markt mit nur wenigen Millionen Dollar Tiefe trafen, konnte kein noch so großer Wettbewerb unter Bots die beschlagnahmten Sicherheiten in genügend Wert umwandeln, um die ausstehenden Schulden zu decken. Protokolle können Liquidation nicht als zuverlässiges Sicherheitsnetz betrachten, wenn der realisierbare Wert der Sicherheiten stark von dem vom Orakel gemeldeten Wert abweicht.

Die Überwachungslücke

Die neunmonatige Akkumulationsphase war von Anfang an On-Chain sichtbar: ein einzelnes Unternehmen, das sich dem Supply Cap näherte, zunehmende Konzentration in einem wenig liquiden Vermögenswert, schrittweiser Positionsaufbau über Monate hinweg. Venus hat anerkannt, dass „einige Community-Mitglieder diese Adresse vor dem Exploit markiert hatten“, stellte jedoch fest, dass „die Adresse zu diesem Zeitpunkt vollständig innerhalb der Protokollgrenzen agierte“ und dass das Protokoll als erlaubnisfreies System „Adressen nicht aufgrund von bloßem Verdacht einfrieren oder auf eine schwarze Liste setzen kann und sollte“ [1]. Als Teil seiner Abhilfe hat Venus erklärt, dass es „On-Chain-Risikoüberwachungsmechanismen erforscht, die anomale Akkumulationsmuster kennzeichnen und eine Überprüfung auf Governance-Ebene auslösen können“ [1].

Die verpassten Signale gehen über den langsamen Aufbau hinaus. Laut Venus’ Post-Mortem [1] funktionierte der Verteidigungsmechanismus des Orakels wie vorgesehen: Der BoundValidator wies den extremen Binance-Feed zurück und setzte für 37 Minuten aus, wodurch Preisaktualisierungen während des ersten Manipulationsfensters effektiv blockiert wurden. Dennoch eskalierte kein Überwachungssystem diese Anomalie. Ein Orakel, das auf einem Markt, auf dem ein einzelnes Unternehmen das Dreifache des Supply Caps hält, kontinuierlich aussetzt, ist ein Echtzeit-Signal hoher Schwere. 37 Minuten sind ein beträchtliches Zeitfenster. Hätte dies einen automatisierten Kill-Switch oder zumindest eine manuelle Überprüfung ausgelöst, hätte das Pausieren des THE-Marktes vor der erneuten Konvergenz des Orakels den Großteil der Leihtransaktionen verhindern können. Dies offenbart auch eine breitere Lücke: Protokoll-Verteidigungsmechanismen, die sich aktivieren und dann lautlos auflösen, ohne einen Alarm- oder Eskalationspfad, bieten nur Schutz gegen die einfachsten Angriffe.

Dies deutet auf zwei unterschiedliche Fähigkeitslücken hin. Die erste ist die Überwachung langfristiger Positionen: Die Nachverfolgung, wie sich die Konzentration eines einzelnen Unternehmens in einem wenig liquiden Vermögenswert im Laufe der Zeit im Verhältnis zu Supply Caps, Markttiefe und Liquidationskapazität entwickelt. Keine einzelne Transaktion während des neunmonatigen Aufbaus war böswillig, und keine Regel wurde gebrochen. Die zweite ist die Echtzeit-Überwachung der Orakel-Gesundheit: Das Erkennen anhaltender Anomalien bei Orakeln auf Märkten mit abnormaler Konzentration und deren Eskalation an Kill-Switch-Mechanismen. Beides erfordert eine kontinuierliche Überwachungsinfrastruktur, die über einzelne Transaktionen hinausblickt und Statusänderungen On-Chain über Adressen und Zeitfenster hinweg korreliert, um systemische Risiken zu erkennen, bevor sie sich materialisieren.

Fazit

Der Venus THE-Vorfall enthüllte keine neuartige Schwachstelle. Er zeigte, wie ein bekannter Angriffsvektor, mit Geduld ausgeführt, den gesamten Risikostapel eines Protokolls überfordern kann, wenn jede Ebene davon ausgeht, dass die anderen halten werden. Warnsignale waren monatelang On-Chain sichtbar, doch die Lücke zwischen Erkennung und Intervention bleibt ungelöst. Die Überbrückung dieser Lücke durch liquiditätsbewusste Risikoparameter, automatisierte Kill-Switches und Überwachung auf Positionsebene ist die zentrale Lehre, die dieser Vorfall für die DeFi-Kredit-Community hinterlässt.

Referenzen

• [1] Venus Protocol, "$THE Market Incident: Post-Mortem": https://community.venus.io/t/the-market-incident-post-mortem/5712
• [2] AllezLabs, "Venus Protocol THE Incident Timeline": https://x.com/AllezLabs/status/2033239532355858536
• [3] hklst4r, "Venus THE Attack Analysis": https://x.com/hklst4r/status/2033192855443808515
• [4] EmberCN, "Venus THE Attacker Fund Flow": https://x.com/EmberCN/status/2033204517467308144
• [5] Venus Protocol Liquidation Dashboard (Dune): https://dune.com/xvslove_team/venus-liquidations

Über BlockSec

BlockSec ist ein Full-Stack-Blockchain-Sicherheits- und Krypto-Compliance-Anbieter. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg zu erfüllen.

BlockSec hat zahlreiche Blockchain-Sicherheitspapiere auf angesehenen Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, zahlreiche Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Milliarden an Kryptowährungen gesichert.

• Offizielle Website: https://blocksec.com/

• Offizieller Twitter-Account: https://twitter.com/BlockSecTeam

• 🔗 BlockSec Auditing Service : Anfrage einreichen

• 🔗 Phalcon Security APP: Demo buchen

• 🔗 Phalcon Compliance