Ajna v2 verliert rund 775.000 US-Dollar durch Manipulation der Liquidationsbuchhaltung

Ajna v2 ist am 29. August 2026 angegriffen worden. Nach den bisher verfügbaren Berichten wurden aus sieben Ethereum-Lending-Pools insgesamt rund 775.000 US-Dollar abgezogen. Der Exploit beruhte offenbar nicht auf der Manipulation eines externen Preis-Feeds, sondern auf einem Angriff gegen Aj nas eigene Liquidationsbuchhaltung – also gegen jene interne Logik, mit der das Protokoll Sicherheiten, Schulden und Liquidationsbedingungen bewertet. 1311

Die öffentlichen Informationen reichen aus, um die betroffenen Pools und die grundsätzliche Angriffsklasse einzuordnen. Eine abschließende, Transaktion für Transaktion verifizierte Rekonstruktion sämtlicher Zustandsänderungen liegt jedoch noch nicht vor. Aussagen über die exakte Abfolge der Aktionen sollten daher vorerst als vorläufig gelten.

Was ist beim Ajna-v2-Exploit passiert?

Der Angriff betraf die Pools syrupUSDC, wstETH, rETH, cbETH, WBTC, WETH/USDC und sDAI. Der Gesamtschaden wurde zunächst auf etwa 775.000 US-Dollar geschätzt; eine spätere Aufstellung kam auf rund 775.400 US-Dollar. Den größten Einzelverlust meldete der syrupUSDC-Pool mit ungefähr 173.700 US-Dollar. 1913

Ajna erklärte, ungewöhnliche Geldbewegungen zu untersuchen, und wies Nutzer an,

• ihre Quote-Token abzuziehen,
• offene Kredite zurückzuzahlen und
• jede weitere Interaktion mit dem Protokoll einzustellen. 111435

Die Warnung sollte verhindern, dass weitere Transaktionen mit den möglicherweise manipulierten Abrechnungszuständen interagieren.

Kein Preisorakel angegriffen – sondern die interne Liquidationslogik

Ajna verzichtet bewusst auf externe Preisorakel. Anders als viele DeFi-Kreditprotokolle nutzt das System nicht etwa einen Dienst wie Chainlink, um die Preise von Sicherheiten festzulegen. Stattdessen beruhen Kreditvergabe und Liquidationen auf Aktivitäten innerhalb des jeweiligen Pools und auf einer internen Bucket-Abrechnung. 333

Im normalen Liquidationsprozess werden Schulden und Sicherheiten aus diesen Buckets entfernt. Dadurch verändern sich interne Kennzahlen wie der Lowest Utilized Price (LUP). Für die Bewertung von Krediten spielen außerdem der Threshold Price (TP) des Kreditnehmers und der Neutral Price (NP) eine Rolle. 3437

Diese Architektur beseitigt zwar eine bekannte Angriffsfläche im DeFi-Bereich – die Manipulation eines externen Preis-Feeds. Sie macht die wirtschaftliche Abrechnung aber nicht automatisch sicher. Den Berichten zum Angriff vom 29. August zufolge manipulierte der Angreifer den internen Liquidationspfad so, dass die Behandlung von Sicherheiten, Schulden und Liquidationspreisen nicht mehr die tatsächliche Deckung der Pools widerspiegelte. 1311

Wichtig ist die Einschränkung bei der Beweislage: Die bisher veröffentlichten Berichte beschreiben den Exploit auf hoher Ebene. Sie belegen noch nicht unabhängig die vollständige Abfolge aus Einzahlungen, Kreditaufnahmen, Liquidationen, Rückzahlungen und Abhebungen. Präziser ist deshalb die Aussage, der Angreifer habe offenbar die interne Liquidationsbuchhaltung ausgenutzt, statt eine noch nicht bestätigte Transaktionsgeschichte als endgültig gesichert darzustellen.

Warum „ohne Orakel“ nicht „sicher vor Preismanipulation“ bedeutet

Der Fall zeigt einen entscheidenden Unterschied:

Wer externe Preis-Feeds entfernt, beseitigt das Orakelrisiko – nicht aber das Preisrisiko.

Ajna konzentrierte zentrale Annahmen in der eigenen Marktstruktur und den Liquidationsregeln. Wenn ein Angreifer die interne Darstellung von Sicherheiten, Schulden oder Liquidationspreisen verschieben oder ausnutzen kann, kann die wirtschaftliche Wirkung einem Orakel-Angriff ähneln – auch wenn kein Drittanbieter-Feed manipuliert wurde. 111

Das ist eine grundsätzliche Lehre für DeFi-Lending-Protokolle. Sicherheitsprüfungen müssen nicht nur den Smart Contract und externe Abhängigkeiten untersuchen. Ebenso wichtig ist die Frage, ob der interne Buchhaltungszustand auch bei ungewöhnlichen Kombinationen aus Kreditaufnahme, Liquidation und Rückzahlung noch dem realen wirtschaftlichen Wert entspricht.

Unveränderlichkeit erschwerte die Notfallreaktion

Ajna v2 wurde als unveränderlich beschrieben: Es gebe weder eine Governance-Struktur noch einen Upgrade-Pfad, einen Administratorschlüssel oder einen zentralen Mechanismus, mit dem die betroffenen Contracts angehalten werden könnten. 9

Dieses Design begrenzt zwar in normalen Zeiten die Risiken willkürlicher Eingriffe, nachträglicher Upgrades und zentraler Kontrolle. Im Ernstfall entsteht jedoch ein klarer Zielkonflikt: Ist die eingesetzte Logik fehlerhaft, kann das Team die Verträge während eines laufenden Angriffs möglicherweise weder pausieren noch kurzfristig reparieren.

Defimon Alerts erklärte, eine vorbereitete Attacke bereits mehr als eine Stunde vor der ersten Exploit-Transaktion erkannt und Ajna über den Discord-Kanal des Projekts gewarnt zu haben. Nach Darstellung des Monitoring-Unternehmens reagierte das Team nicht. Diese Schilderung stammt von Defimon und ist keine unabhängig abschließend bewertete Feststellung; Zeitpunkt und Reaktion sollten daher bis zu weiteren Belegen entsprechend vorsichtig eingeordnet werden. 816

Was der Vorfall für das DeFi-Risiko bedeutet

Der Ajna-Schaden war im Vergleich zu den größten Krypto-Diebstählen relativ begrenzt. Der Vorfall zeigt jedoch, warum die Zahl der Angriffe und das Protokolldesign ebenso wichtig sind wie die Höhe des einzelnen Verlusts. TRM Labs registrierte im ersten Halbjahr 2026 207 Krypto-Hacks und Exploits – den höchsten Sechsmonatswert in der eigenen Datensammlung. Auf Smart-Contract-Exploits entfielen rund 125 Vorfälle. 1829

The Defiant berichtete unabhängig davon von etwa 70 DeFi-Exploits und Verlusten von 746 Millionen US-Dollar im zweiten Quartal 2026. Da die verschiedenen Tracker unterschiedliche Kriterien verwenden, sind die Zahlen nicht unmittelbar miteinander gleichzusetzen. Zusammen weisen sie jedoch auf ein weiterhin angespanntes Bedrohungsumfeld für DeFi-Protokolle hin. 23

Ajna liefert dazu eine besonders konkrete Warnung: Ein Protokoll kann auf externe Orakel verzichten und trotzdem von einer kritischen internen wirtschaftlichen Abhängigkeit geprägt sein. Orakelfreies Design, Unveränderlichkeit und Dezentralisierung reduzieren manche Risiken – können andere aber vergrößern, vor allem wenn nach Beginn einer fehlerhaften Abrechnung kein Notfallmechanismus mehr zur Verfügung steht.