Як експлойт Notional Finance V1 перетворив борг на 2^128 на нуль

Повідомлений інцидент із Notional Finance не схожий на звичайну нестачу застави. За попередньою реконструкцією, проблема полягала у розбіжності в обліку: було створено гігантський борг fCash на межі 2^128, а під час розрахунку вільного забезпечення протокол звузив значення до uint128. У результаті борг у цій критичній точці нібито став нульовим — і рахунок міг виглядати платоспроможним, хоча не мав би пройти перевірку для виведення активів. 416

Важливо: ця картина спирається на ончейн-моніторинг і повідомлення дослідників безпеки, а не на офіційний постмортем Notional. Рух коштів у блокчейні можна перевірити, але повну послідовність викликів, остаточний масштаб збитків і статус виправлень на момент публікацій не було офіційно підтверджено. 34

Як величезний борг міг стати нулем

У Notional V1 майбутні грошові зобов’язання представлялися токенами fCash. Згідно з публічним попередженням CertiK, зловмисник двічі викликав mintfCashPair() і створив зобов’язання −2^128. Під час оцінки вільного забезпечення небезпечне приведення до uint128 нібито обрізало це значення до 0. 16

Описана дослідниками схема виглядала так:

1. Створення екстремальної від’ємної позиції fCash. Було сформовано борг такого розміру, за якого звуження до 128-бітного беззнакового цілого могло втратити його представлення. 416
2. Запуск оцінки забезпечення. У розрахунку escrow-контракту зобов’язання, за повідомленнями, перетворювалося через небезпечний downcast до uint128.
3. Зникнення боргу в перевірці. Замість величезного від’ємного зобов’язання система врахувала нуль. 46
4. Прохід перевірки на виведення. Без боргу в розрахунку вільного забезпечення обліковий запис міг виглядати таким, що відповідає умовам для виведення ліквідних стейблкоїнів з escrow. 46

Тому цей випадок точніше описувати не просто як «переповнення цілих чисел», а як помилку звужувального перетворення типів та порушення облікового інваріанта. Ключовий ефект, про який повідомляли, полягав у тому, що від’ємне зобов’язання стало нулем саме в механізмі оцінки, який мав не допустити виведення коштів за недостатнього забезпечення. 416

Скільки коштів, імовірно, вивели

Ончейн-звіти оцінювали втрати приблизно у 69 257 DAI та 1 650 824 USDC, або близько $1,728 млн. За повідомленнями, ці активи обміняли приблизно на 689,2 ETH, після чого внесли до Tornado Cash. 215

У публікаціях фігурував escrow-контракт Notional Finance за адресою 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683. Один зі звітів вказував на підготовчу транзакцію з адреси, що закінчується на Ce38, о 23:58:47 UTC 3 вересня 2026 року; приблизно через три хвилини, вже на початку 4 вересня, відбулася транзакція виведення коштів. 1723

Дослідники також пов’язували з переказами дві Ethereum-адреси:

• 0xC954…De69
• 0xDaCC…Ce38

Це ончейн-атрибуція дослідників, а не встановлення особи, організації чи фактичного контролера цих гаманців. 11

Чому переказ у ETH і Tornado Cash ускладнив повернення

Переказ DAI та USDC в ETH змінив ситуацію з потенційним відстеженням активів. Вихідні операції зі стейблкоїнами чітко видно в Ethereum, але після обміну активи опинилися в ETH. Подальші внесення до Tornado Cash додали шар приватності, призначений для приховування зв’язку між джерелом, призначенням і контрагентами транзакцій. 229

Це не означає, що блокчейн-аналіз стає неможливим, і не доводить, хто контролював будь-яке подальше виведення. Проте після потрапляння коштів у міксер простежити прямий шлях від скомпрометованого escrow-контракту до конкретного подальшого отримувача стає істотно складніше. 29

Що на той момент лишалося невідомим

На час появи повідомлень Notional не оприлюднила офіційної відповіді щодо інциденту. Тому залишалися відкритими важливі питання:

• остаточна технічна причина та повна послідовність викликів експлойту;
• чи охоплювали зафіксовані транзакції всі уражені контракти, рахунки й активи;
• фінальний обсяг втрат з урахуванням обмінів, комісій і наступних переказів;
• можливості призупинення роботи, оновлення контрактів, компенсацій або повернення активів;
• особа зловмисника та чи були позначені адреси єдиними гаманцями під спільним контролем. 3411

Отже, оприлюднену технічну причину варто розглядати як сильну, але все ж попередню реконструкцію — не як заміну аудованому постмортему або офіційному звіту.

Урок для старих DeFi-контрактів

Старий контракт не стає безпечним лише тому, що він більше не є центром розвитку продукту. Якщо він досі зберігає активи або має доступ до випуску токенів, розрахунків, застави чи механізмів виведення, він залишається реальною фінансовою поверхнею атаки.

Для команд протоколів цей випадок підкреслює потребу перевіряти комплексно кілька речей:

• застосовувати перевірені звужувальні перетворення та явно відхиляти значення, які неможливо безпечно представити;
• тестувати розрахунки боргу, погашення й забезпечення зі знаком на числових межах, зокрема 2^128;
• формалізувати правила платоспроможності та збереження коштів як інваріанти й тестувати їх у послідовностях із кількох викликів;
• перевіряти, чи не можна скомпонувати незвичні або привілейовані шляхи викликів так, щоб поєднати випуск, розрахунок і виведення в небезпечному порядку;
• обмежувати викликачів і сценарії викликів там, де функція безпечна лише у передбаченому контексті.

Ширший патерн для DeFi добре відомий: невелика помилка в представленні даних або авторизації може перетворитися на повну втрату коштів, якщо дістається шляху виведення ліквідних активів. Захист потребує не лише аудиту окремих функцій, а й доказу того, що облікові інваріанти системи зберігаються в кожній досяжній послідовності викликів.