Jak exploit w escrow Notional Finance V1 zamienił dług 2^128 w zero

To nie był typowy przypadek niedostatecznego zabezpieczenia. Według publicznych rekonstrukcji problemem w Notional Finance V1 miała być niespójność księgowa: utworzono gigantyczny dług fCash na granicy 2^128, a następnie w kluczowym etapie wyliczania wolnego zabezpieczenia został on zredukowany do zera przez zawężenie typu do uint128. Jeśli system zapisywał zobowiązanie jako zero, konto mogło pozornie spełniać warunki wypłaty aktywów, do których nie powinno mieć dostępu. 416

Rekonstrukcja opiera się na monitoringu on-chain i ustaleniach badaczy bezpieczeństwa, a nie na opublikowanym raporcie po incydencie od zespołu protokołu. Transfery środków można obserwować w blockchainie, lecz pełna sekwencja wywołań, ostateczna skala szkód i status działań naprawczych nie były wówczas oficjalnie potwierdzone. 34

Na czym polegało „wyzerowanie” długu

W Notional V1 przyszłe zobowiązania pieniężne reprezentowano tokenami fCash. Zgodnie z alertem CertiK atakujący wykonał dwa wywołania mintfCashPair(), tworząc zobowiązanie -2^128. Podczas wyceny wolnego zabezpieczenia niebezpieczna konwersja do uint128 miała obciąć tę wartość do 0. 16

W praktyce opisywany scenariusz wyglądał następująco:

1. Utworzenie skrajnie dużej ujemnej pozycji fCash. Powstał dług dokładnie o takiej wartości, przy której zawężenie do 128-bitowej liczby bez znaku mogło usunąć jego reprezentację. 416
2. Uruchomienie wyceny zabezpieczenia. Księgowość escrow miała przekształcić zobowiązanie przez niebezpieczny downcast do uint128.
3. Pominięcie długu w kontroli. Zamiast odzwierciedlić ogromne ujemne zobowiązanie, obliczenie potraktowało je jako zero. 46
4. Przejście warunku wypłaty. Ponieważ dług nie obciążał wyliczenia wolnego zabezpieczenia, konto mogło wyglądać na wypłacalne i otrzymać dostęp do płynnych stablecoinów escrow. 46

Dlatego trafniej mówić tu o błędzie zawężającej konwersji i naruszeniu niezmiennika księgowego niż po prostu o „przepełnieniu licznika”. Kluczowym skutkiem miało być przekształcenie ujemnego zobowiązania w zero dokładnie w ścieżce wyceny, która powinna blokować wypłatę z niedostatecznie zabezpieczonego konta. 416

Ile środków miało wypłynąć

Raporty on-chain szacowały stratę na około 69 257 DAI i 1 650 824 USDC, czyli łącznie około 1,728 mln USD. Aktywa miały zostać zamienione na około 689,2 ETH, a następnie wpłacone do Tornado Cash. 215

W raportach wskazano kontrakt escrow Notional Finance pod adresem 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. Jedno z doniesień opisywało transakcję przygotowawczą z adresu kończącego się na Ce38, wysłaną 3 września 2026 r. o 23:58:47 UTC, oraz transakcję opróżniającą kontrakt wykonaną około trzy minuty później, już 4 września. 1723

Badacze połączyli z przepływem środków dwa adresy Ethereum:

• 0xC954…De69
• 0xDaCC…Ce38

To przypisanie w ramach analizy on-chain, a nie potwierdzona identyfikacja konkretnej osoby, organizacji ani faktycznego właściciela portfeli. 11

Dlaczego zamiana na ETH utrudniła odzyskanie środków

Zamiana DAI i USDC na ETH zmieniła sytuację z punktu widzenia śledzenia środków. Początkowe transfery stablecoinów były widoczne w sieci Ethereum, natomiast konwersja przeniosła wartość do ETH. Późniejsze wpłaty do Tornado Cash dodały warstwę prywatności, której celem jest zaciemnienie powiązań między źródłem, celem i stronami transakcji. 229

Nie oznacza to, że analiza blockchaina staje się niemożliwa ani że można na tej podstawie wskazać kontrolującego późniejszą wypłatę. Oznacza jednak, że bezpośredni ślad prowadzący od wykorzystanego escrow do późniejszego odbiorcy staje się wyraźnie mniej jednoznaczny, gdy środki trafiają do miksera. 29

Co pozostawało niepotwierdzone

W czasie opisywanych raportów Notional nie opublikował publicznej odpowiedzi na incydent. Otwarte pozostawały między innymi pytania o:

• definitywną przyczynę techniczną i pełny przebieg wywołań exploitu;
• to, czy dotknięte były także inne kontrakty, konta lub aktywa;
• ostateczną stratę po swapach, opłatach i ewentualnych dalszych transferach;
• dostępne możliwości wstrzymania działania, aktualizacji kontraktów, rekompensat lub odzyskania aktywów;
• tożsamość atakującego oraz to, czy wskazane adresy były jedynymi portfelami pod wspólną kontrolą. 3411

Opisywaną przyczynę należy więc traktować jako mocną, ale nadal wstępną rekonstrukcję — nie jako zastępstwo audytowanego post-mortem lub oficjalnego raportu z incydentu.

Lekcja dla starszych systemów DeFi

Stary kontrakt nie staje się bezpieczny tylko dlatego, że nie jest już centralnym elementem rozwoju produktu. Jeśli nadal przechowuje aktywa albo ma dostęp do mintowania, rozliczeń, kontroli zabezpieczenia czy wypłat, pozostaje aktywną powierzchnią ataku finansowego.

Dla zespołów rozwijających protokoły DeFi ten przypadek podkreśla potrzebę łącznej weryfikacji kilku zabezpieczeń:

• stosowania sprawdzanych konwersji zawężających i odrzucania wartości, których nie da się bezpiecznie reprezentować;
• testowania rozliczeń długu, zabezpieczenia i pozycji ze znakiem na granicach liczbowych, takich jak 2^128;
• kodowania reguł wypłacalności i zachowania wartości jako niezmienników oraz testowania ich w sekwencjach wielu wywołań;
• sprawdzania, czy nietypowe lub uprzywilejowane ścieżki wywołań nie pozwalają połączyć mintowania, rozliczenia i wypłaty w niezamierzonej kolejności;
• ograniczania wywołujących i przepływów wywołań wszędzie tam, gdzie funkcja jest bezpieczna wyłącznie w przewidzianym kontekście.

Szerszy wzorzec jest w DeFi dobrze znany: niewielki błąd reprezentacji danych lub autoryzacji może przerodzić się w pełną utratę środków, jeśli prowadzi do ścieżki wypłaty płynnych aktywów. Obrona nie powinna więc ograniczać się do audytu pojedynczych funkcji — konieczne jest wykazanie, że niezmienniki księgowe systemu obowiązują w każdej osiągalnej sekwencji wywołań.