Notional-Finance-Exploit: Wie eine 2^128-Schuld bei der Prüfung zu null wurde

Der gemeldete Vorfall bei Notional Finance war offenbar kein klassischer Fall unzureichender Sicherheiten. Im Zentrum stand vielmehr ein Fehler in der Buchhaltung: Eine extrem große fCash-Schuld an der Grenze von 2^128 soll erzeugt und bei der Berechnung freier Sicherheiten durch eine Verengung auf uint128 zu null gemacht worden sein. Wurde die Verbindlichkeit in diesem entscheidenden Prüfschritt als null erfasst, konnte das Konto solvent wirken und Vermögenswerte abziehen, auf die es keinen Zugriff hätte haben dürfen. 416

Die technische Rekonstruktion beruht auf On-Chain-Beobachtungen sowie Berichten von Sicherheitsforschern, nicht auf einem veröffentlichten Post-Mortem von Notional. Die Geldbewegungen sind auf der Blockchain nachvollziehbar; der vollständige Aufrufablauf, der Gesamtschaden und der Stand möglicher Gegenmaßnahmen waren in den vorliegenden Berichten jedoch nicht abschließend bestätigt. 34

Wie aus der Schuld in der Prüfung null wurde

Notional V1 stellte künftige Zahlungsverpflichtungen über fCash dar. Nach einem öffentlichen Alert von CertiK nutzte der Angreifer zwei Aufrufe von mintfCashPair(), um eine Verbindlichkeit von -2^128 zu erzeugen. Bei der Bewertung der freien Sicherheiten soll eine unsichere Umwandlung nach uint128 diesen Wert auf 0 gekürzt haben. 16

Der von Forschern beschriebene Ablauf lässt sich vereinfacht so darstellen:

1. Extrem hohe negative fCash-Position erzeugen: Es wurde eine Schuld genau in jener Größenordnung angelegt, bei der eine Reduktion auf einen 128-Bit-unsigned-Wert die Schuldabbildung verlieren kann. 416
2. Sicherheitenbewertung auslösen: In der Buchhaltung des Escrows wurde die Verbindlichkeit Berichten zufolge über einen unsicheren uint128-Downcast verarbeitet.
3. Schuld aus dem Prüfergebnis entfernen: Statt eine enorme negative Verpflichtung zu berücksichtigen, behandelte die Berechnung den Wert als null. 46
4. Auszahlungsprüfung passieren: Weil die Schuld bei der Berechnung der freien Sicherheiten fehlte, konnte das Konto die Voraussetzungen für eine Auszahlung der liquiden Stablecoins des Escrows scheinbar erfüllen. 46

Der Vorfall ist damit präziser als Fehler einer verengenden Typumwandlung und einer verletzten Buchhaltungsinvariante zu beschreiben – nicht einfach als allgemeiner „Integer Overflow“. Der entscheidende berichtete Effekt war, dass eine negative Verbindlichkeit gerade in dem Bewertungspfad zu null wurde, der eine unterbesicherte Auszahlung hätte verhindern sollen. 416

Welche Mittel laut Berichten abflossen

On-Chain-Berichte bezifferten den Abfluss auf rund 69.257 DAI und 1.650.824 USDC, zusammen etwa 1,728 Millionen US-Dollar. Die Mittel sollen in ungefähr 689,2 ETH getauscht und anschließend bei Tornado Cash eingezahlt worden sein. 215

Als betroffener Vertrag wurde der Notional-Finance-Escrow unter 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683 genannt. Ein Bericht verzeichnete eine vorbereitende Transaktion von einer Adresse mit der Endung Ce38 am 3. September 2026 um 23:58:47 Uhr UTC; rund drei Minuten später folgte in den frühen Stunden des 4. September die Transaktion zum Abzug der Mittel. 1723

Öffentliche Ermittlungsberichte brachten zwei Ethereum-Adressen mit den Transfers in Verbindung:

• 0xC954…De69
• 0xDaCC…Ce38

Diese Zuordnung ist eine On-Chain-Einschätzung von Ermittlern, keine Identifizierung einer Person, Organisation oder eines letztlich kontrollierenden Akteurs. 11

Warum der Weg über ETH die Wiederbeschaffung erschwerte

Der Tausch von DAI und USDC in ETH veränderte die Ausgangslage für eine mögliche Wiederbeschaffung. Die Stablecoin-Transfers waren auf Ethereum direkt nachvollziehbar, danach lagen die Werte jedoch als ETH vor. Die gemeldeten Einzahlungen in Tornado Cash fügten eine Privatsphäre-Schicht hinzu, die Herkunft, Ziel und Gegenparteien von Transaktionen verschleiern soll. 229

Das macht Blockchain-Analysen nicht unmöglich und belegt auch nicht, wer spätere Auszahlungen kontrollierte. Der direkte, vermögenswertbezogene Pfad vom betroffenen Escrow zu einem späteren Empfänger wird nach dem Eintritt in einen Mixer aber deutlich schwieriger nachzuverfolgen. 29

Was zunächst offenblieb

Zum Zeitpunkt der Berichte hatte Notional keine öffentliche Stellungnahme zum Vorfall abgegeben. Damit blieben wesentliche Fragen offen:

• die endgültige technische Ursache und der vollständige Exploit-Aufrufablauf;
• ob alle betroffenen Verträge, Konten und Vermögenswerte bereits erfasst waren;
• die finale Schadenshöhe nach Tauschvorgängen, Gebühren oder späteren Transfers;
• mögliche Optionen zum Pausieren, Upgraden, Entschädigen oder Wiederbeschaffen; sowie
• die Identität des Angreifers und ob die zwei markierten Wallets die einzigen gemeinsam kontrollierten Adressen waren. 3411

Die berichtete Ursache ist deshalb als belastbare vorläufige Rekonstruktion zu verstehen, nicht als Ersatz für ein geprüftes Post-Mortem oder einen offiziellen Incident Report.

Lehre für alte DeFi-Systeme

Ein alter Smart Contract ist nicht automatisch risikoarm, nur weil er für die Produkt-Roadmap keine zentrale Rolle mehr spielt. Hält er weiterhin Vermögenswerte oder greift er auf Minting-, Settlement-, Sicherheiten- oder Auszahlungsabläufe zu, bleibt er eine aktive Angriffsfläche.

Für Protokollteams unterstreicht der gemeldete Notional-V1-Fall insbesondere diese Kontrollen:

• verengende Typumwandlungen absichern und nicht darstellbare Werte ausdrücklich ablehnen;
• Berechnungen für signierte Schulden, Settlement und Sicherheiten an Zahlengrenzen wie 2^128 testen;
• Solvenz- und Erhaltungsregeln als Invarianten festschreiben und über mehrstufige Aufrufsequenzen prüfen;
• untersuchen, ob ungewöhnliche oder privilegierte Pfade Minting, Settlement und Auszahlung in unbeabsichtigter Reihenfolge kombinieren können;
• Aufrufer und Aufrufpfade beschränken, wenn eine Funktion außerhalb ihres vorgesehenen Kontexts unsicher ist.

Das übergeordnete DeFi-Muster ist bekannt: Ein kleiner Fehler bei Datenrepräsentation oder Berechtigungen kann zum vollständigen Verlust werden, sobald er einen Auszahlungspfad mit liquiden Vermögenswerten erreicht. Entscheidend ist daher nicht nur das Audit einzelner Funktionen, sondern der Nachweis, dass die Buchhaltungsinvarianten bei jeder erreichbaren Folge von Aufrufen bestehen bleiben.