Урок на мільярд доларів: Безпека DeFi зосереджується не на коді, а на управлінні операціями

Оригінальний переклад: Спільнота登链

Короткий зміст та вступ:

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

Ми не повинні були втратити мільярд доларів

За останні дванадцять місяців було втрачено близько 1 мільярда доларів через інциденти у DeFi, але більша частина з них цілком могла бути запобігти.

Почнемо з останнього exploit: 18 квітня — exploit на 292 мільйони доларів у Kelp DAO.

AAVE знизився на 15%. Aave тимчасово заблокував ринок rsETH у всіх розгортаннях, а згодом — для запобігання — заблокував позики WETH. Самі контракти Aave ніколи не були зламані, але за кілька годин використання WETH-ринку досягло 100% завантаженості. Ті, хто ніколи не торкався rsETH, раптом не могли зняти кошти.

Після цього з’явилися поширені думки у crypto twitter: Міст поганий. DeFi поганий. Ось чому справжні гроші не заходять.

Я вважаю, що ці твердження не захоплюють суть.

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

Kelp — яскравий приклад.

— один верифікатор. Один точковий збій.

Злом Kelp не був через помилку у смарт-контракті. Причина у тому, що @KelpDAO обрав конфігурацію децентралізованої мережі валідаторів LayerZero (DVN) з одним вузлом. За повідомленнями, атакуючі, пов’язані з північнокорейською групою Lazarus, не зламали сам DVN. Спершу вони визначили, які RPC провайдери використовуються DVN. Потім зламали двох з них, щоб отримати фальшиві дані. Після цього вони здійснили DDoS-атаку на решту провайдерів, змусивши систему перейти на вже зламані. DVN під добросовісним підписом підписала фальшиве міжланцюгове повідомлення — оскільки інших верифікаторів для перевірки результату не було, цього підпису вистачило.

Один верифікатор. Один точковий збій.

116 500 rsETH було вивільнено з LayerZero OFT Adapter (керує міжланцюговими токенами) для атакуючих, що призвело до втрати підтримки у 16 L2. Атакуючі заклали rsETH на Ethereum у якості застави у Aave, Compound і Euler, і позичили 236 мільйонів доларів WETH, доки це не було виявлено. Тепер усі, хто тримають rsETH на якомусь L2, мають претензію на порожній сейф.

Цей ризик був помічений ще за дванадцять днів до інциденту.

6 квітня інженер @liliangjya5 з @get_truenorth опублікував відкритий кодовий навик Claude, у якому підкреслюється непрозорість конфігурації DVN, позначаючи один точковий збій у 16 ланцюгах як найбільший ризик і порівнюючи цю ситуацію з експлойтами Ronin і Harmony 2022 року. Час коміту — відкритий, кожен може його побачити.

[]

Kelp ніколи не публікували поріг DVN. У чеклісті інтеграції LayerZero чітко рекомендується використовувати конфігурацію з кількома DVN. Kelp залишився з конфігурацією 1-із-1. Ніхто не змушував їх публікувати, ніхто не змушував змінювати.

Через дванадцять днів — 2,92 мільярда доларів зникли.

За останні дванадцять місяців DeFi не можна заперечувати

Злом Kelp — найбільший, але не єдиний.

• Ще два тижні тому, 1 квітня, Drift зазнав втрат у 285 мільйонів доларів після кількох місяців соціального інженерингу. Атакуючі використали довговічні nonces Solana для отримання валідних підписів адміністратора, зробили білого списку токенів без цінності заставою і вивели реальні активи. Щонайменше 20 інших протоколів повідомили про вплив.

• 22 березня Resolv зазнав атаки через сторонню інфраструктуру. Атакуючі проникли у GitHub і хмарне середовище стороннього проекту, отримали права на підписання minting-процесів, створили 80 мільйонів USR без підтримки активів і викрали 25 мільйонів доларів ETH. Смарт-контракти залишилися цілі, вразливими були привілеї ключів і операційна інфраструктура.

• 10 березня Aave через невідповідність у налаштуваннях оракулів викликав ліквідацію приблизно на 26 мільйонів доларів, залучивши 34 рахунки. Це спричинило падіння ціни wstETH на 2,85%. У цьому випадку не було зловмисників і не було експлойту. Втрати сталися через добросовісне оновлення налаштувань, яке не було протестоване на ворожі сценарії.

• Ще до початку 2026 року ми пережили втрати Cetus на Sui у 223 мільйони доларів, Cork — 12 мільйонів через втрату wstETH після кількох аудитів, Balancer — понад 120 мільйонів у листопаді, а Aerodrome — не через помилку у смарт-контракті, а через DNS-хак, що спричинив втрати понад 100 тисяч доларів. Знову ж, контракти залишилися цілими, а фішингова сторінка зробила останній удар.

Загалом, це майже 1 мільярд доларів втрат. Кожна аварія має різні причини, але формується певна модель.

Ці експлойти вже перейшли у офчейн

Ризики смарт-контрактів не зникли — Cetus, Cork і Balancer — це реальні збої логіки onchain. Будь-який протокол, що досі вважає, що invariant testing, adversarial simulation і формальні методи — це опція, навряд чи пройде без уроку після однієї релізу. Але це вже не головна тема.

Глядаючи на весь крипто, Chainalysis оцінює, що у 2025 році було викрадено понад 6,5 мільярдів доларів, з яких лише три найбільші хакі склали 69% втрат. Як і раніше, найбільші втрати спричинені привілеями доступу, підписними процесами, соціальним інженерингом і сторонньою інфраструктурою, а не ізольованими помилками у смарт-контрактах.

Я вважаю, що це три різні моделі провалів: Code layer, Control plane, Composability.

2. Code — найкращий захист у DeFi, але й тут ще не все вирішено. У нас є fuzzing, статичний і динамічний аналіз, формальні перевірки, bug bounty, аудити, invariant testing — кожна серйозна команда знає, що робити.

3. Control plane — тут DeFi значно відстає від TradFi. Signer-устройства, ротація ключів, перевірка привілеїв, CI/CD, захист DNS, безпека реєстраторів доменів. Більшість протоколів навіть не мають повного інвентарю цих поверхонь, не кажучи вже про контроль над ними.

4. Composability — одна з найсильніших переваг DeFi, але й найменш оцінених ризиків. Коли один ринок позик додає якийсь обгорнутий актив, він перетворює збій мосту у власний збій. Коли позиція під заставою приймає токен з лічильником ліквідності, вона успадковує затримки управління емісії. Aave не писав коду Kelp, але все одно зазнав збитків через його провал — і це відкриває проблеми з його управлінням.

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

Традиційна фінансова система вже має playbook

Дискусії про те, щоб зробити DeFi “більш схожим на TradFi”, часто йдуть у неправильному напрямку. Інтуїція у крипто — що ставати більш схожим на TradFi означає повільніше, більш централізовано, з більшою регуляцією.

[]

Я вважаю, що це неправильно.

Хоча TradFi не ідеальна, вона винайшла багато корисних речей, які значно перевищують permissioning. Вона створила механізми для роботи критичних систем під час збоїв — ці рамки вже існують. Вони пройшли випробування десятиліттями банкрутств, перерв у торгівлі, кібератак і операційних аварій.

Приклади:

• NIST Cybersecurity Framework 2.0 — підняв управління (Govern) до рівня з ідентифікацією, захистом, виявленням, реагуванням і відновленням.

• Basel Committee on Banking Supervision — визначив операційну стійкість як здатність виконувати критичні операції під час збоїв.

• Британська Financial Conduct Authority — вимагає від компаній ідентифікувати важливі бізнес-сервіси, встановлювати допустимі рівні впливу та тестувати їхню здатність витримати збої.

• Institute of Internal Auditors — через модель Three Lines розділяє управління, ризики та незалежний аудит.

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

Коли Lazarus атакували RPC провайдерів LayerZero, вони використовували той самий playbook, що і для атак на SWIFT і ланцюгові supply chain. Традиційна фінансова система має понад тридцять років досвіду у цьому. Але DeFi здається, що вважає, ніби з історії традиційних фінансів нічого не можна взяти.

Привілеї — це системно важлива утиліта

Привілеї мають бути набагато важчими у використанні, ніж звичайні функції протоколу. Ключі, multisig або сервісні акаунти, що можуть додавати активи, переміщати резерви, оновлювати оракули, змінювати пірінг мостів або логіку ліквідації — це системно важливі фінансові утиліти. Мінімальні стандарти:

• Апарати для зберігання ключів (hardware wallets)

• Захищена автентифікація від фішингу

• Незалежні signer-устройства

• Вихід із out-of-band для транзакцій

• Відокремлення Quorum

• Встановлення тайм-аута для всіх неекстрених операцій

• Чітке відмовлення від функцій, що можуть бути використані для зловживань у майбутньому (dormant signatures)

Після інциденту з Drift, їхній план відновлення — хороший мінімальний стандарт.

Offchain-інфраструктура також є частиною протоколу. Управління кодом, CI/CD, хмарний IAM, реєстри пакетів, домени, DNS, поверхня WalletConnect і фронтенд у браузері — все це у зоні реальної загрози. Стандарти безпеки включають мінімальні привілеї, апарати для автентифікації, безсекретне розгортання, відтворювані збірки з BOM, фіксація залежностей. На межі безпеки — блокування реєстраторів, захист DNS і децентралізовані дзеркальні фронтенди, що забезпечують безперервність у разі аварії.

DNS-хак Aerodrome нагадує, що межі безпеки ширші, ніж у більшості команд.

Кожна зміна має тестуватися у ворожих сценаріях. Перевірка міжланцюгових верифікаторів має базуватися на перевірці доказів, а не на attestation. Канонічний міст перевіряє підписані блок-хаеди через меркл-дерево — криптографічна гарантія: зламаний вузол може відмовитися надавати дані, але не підробити їх. Перевірка доказів (proof-verification) сильніша за attestation, але все одно має ризики консенсусу, реалізації та оновлень. Важливо розуміти, які збої вона виключає і які залишаються.

Використання attestation не дає таких гарантій. Вони підписують будь-який вміст RPC-ендпоінтів, що збільшує поверхню атаки. Якщо attestation використовується для швидкості або сумісності, то quorum — це не кількість, а незалежність. П’ять валідаторів, що читають один і той самий отруєний RPC, підпишуть одне й те саме неправдиве повідомлення п’ять разів. Лише коли члени quorum мають справді незалежні джерела даних, безпека зростає, ідеально — з комбінацією приватних і довірених публічних вузлів. Kelp — приклад того, як досвідчений зловмисник використовує цю прогалину.

Не всі активи варто включати до спільної баланс-статистки. Активи мостів, liquid staking токени, vault share, синтетичні долари і wrapper-токени слід вважати структурованими продуктами. Вони потребують окремого onboarding-мему, що охоплює широкий спектр ризиків і обмежень. У більшості випадків їх слід тримати у ізольованих ринках, а не у спільному core pool.

Aave ще у квітні 2025 року зупинив rsETH через баг over-minting у Kelp. Через рік rsETH повернувся до спільного ринку — і це вимагає більш суворого контролю.

Виявлення і реагування мають працювати на машині. Коли протокол може бути зламаний за кілька хвилин, людське втручання — лише імітація управління. Автоматизація — норма: виявлення аномалій у операціях адміністратора, mint/burn, використанні, відхиленнях оракула, трафіку мосту, обмеженнях швидкості, заздалегідь визначених тригерах і пост-громадських перевірках. Це — основа для auto-freeze з обмеженим впливом.

Ми маємо почати пріоритетно захищати кошти користувачів. Невеликі незручності від автоматичних блокувань — набагато менше, ніж вартість відсутності таких автоматизацій.

Управління має визначити, що не може зламатися

Щоб допомогти команді визначити цілі безпеки, управління має чітко прописати, що абсолютно не можна допустити зламати. Рада директорів, фонд або DAO мають окреслити важливі бізнес-сервіси: депозити і зняття, ліквідації, оновлення оракулів, виконання управлінських рішень, входи/виходи через мост, фронтенд, комунікація у разі аварії.

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

Це — суть операційної стійкості у банківській системі, і її можна безпосередньо застосувати до DeFi.

DeFi має запровадити справжню модель Three Lines:

• Перша лінія: продукти, інженери, казначейство і операції відповідають за ризики і контрольні заходи.

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

• Третя лінія: незалежний аудит підтверджує, що перша і друга лінії справді працюють.

Незалежність — це спосіб запобігти тому, щоб мотивація зростання змушувала команду саму себе перевіряти.

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

Термінові повноваження мають бути вузькими, заздалегідь визначеними і з sunset-термінами. Випадки Cetus і Sui демонструють дві сторони — швидке екстрене втручання може врятувати сотні мільйонів доларів. Але це піднімає важливе питання: хто може перервати ці системи, що теоретично не можна зупинити, і за якими правилами. Відповідь — до запуску, а не під час кризи, — визначити тригери, уповноважених акторів, стандарти доказів, максимальну тривалість, прозорість і шлях повернення до нормального управління.

Кожен протокол має мати план вирішення кризи заздалегідь. Drift створює recovery pool після інциденту. Aave після невідповідності оракулів повернувся до компенсації користувачам. Resolv компенсував у співвідношенні 1:1 власникам до зломів. Це — адекватні реакції, але вищий стандарт — заздалегідь затверджений waterfall: спершу захист користувачів, потім казначейські резерви, страхування або модулі безпеки, відповідальність сервіс-провайдерів і чіткі межі для соціалізованих втрат.

Розмежування протоколів, що серйозно ставляться до управління, і тих, що ігнорують його, — три питання: хто може зупинити небезпечний запуск? хто може у разі умов заморозити ринок? і хто заплатить, якщо делегований сервіс-провайдер спричинить збитки?

Протокол, що не може назвати відповідальних, тригери і відповідальність, — не має чітко визначеного управління, а просто сподівається, що експлойт ніколи не станеться.

Ризикові дані визначають успіх або провал контролю

Безпечний DeFi потребує live data plane — потоку даних, що керує кожним замороженням, обмеженням і ліквідацією через onchain і offchain сигнали. Control plane відповідає за дії, data plane — за повідомлення, чи потрібно діяти.

Стандарти даних і самі дані — не менш важливі. Вхідні дані для оракулів, заморожень і змін параметрів мають мати чіткі вимоги до свіжості, provenance, рівня довіри і перехресної перевірки з незалежними джерелами. У разі розбіжностей потрібно заздалегідь визначити fallback-дії, а не ухвалювати рішення на льоту.

Aave пропонує risk-managed oracle для USDe і зважений за часом Slope2 Risk Oracle — правильний напрямок. Випадок з wstETH нагадує, що кожен автоматичний цикл контролю має мати захисні бар’єри від помилок конфігурації.

Розкриття інформації — це теж контроль. Користувачі мають мати публічну сторінку статусу, watchlist атакуючих, реєстр інцидентів у реальному часі, швидкий і точний початковий коментар, а також постмортем, що чітко розділяє факти і гіпотези, точно кількісно оцінює збитки, перелічує зміни у контролі і пояснює шляхи компенсації. Оновлення Drift, постмортем Resolv і пояснення у Aave — набагато краще, ніж мовчазне мовлення після розмитих твітерів. Стандарти галузі мають включати відпрацьовану комунікаційну playbook.

Значення ризикових даних — у тому, щоб стимулювати дії. Обмеження кредитування, зниження cap, призупинення ринків, оновлення вручну, доведення безпечності — все це має базуватися на даних. Аналітика, що не входить до control, limit або assurance — не заслуговує назви risk infrastructure.

Модель загроз AI вже змінилася

У квітні 2026 року модель загроз AI зазнала змін. Claude Mythos Preview від Anthropic довів здатність розпізнавати і експлуатувати всі основні уразливості у операційних системах і браузерах. Більше 99% знайдених вразливостей ще не оприлюднені, оскільки патчі ще не зроблені. Банки і регулятори у Великій Британії, США і Німеччині вже вважають можливості Mythos реальним cyber risk.

Так само і протоколи DeFi мають діяти.

З практичної точки зору, spear-phishing стає дешевшим, розробка експлойтів — швидшою, reconnaissance — більш автономною, а низькорівневі сигнали — раніше виявляються. Захист і реагування мають включати:

• Захищені робочі станції розробників, як і привілейовані кінцеві точки

• Аналіз коду з AI у контрольованому доступі

• За замовчуванням — захист від фішингу у процесах підпису

• Виявлення аномалій і обмежені auto-реакції, що враховують швидкість атаки

Це — оптимістична версія історії Kelp. Ті самі можливості AI, що загрожують протоколам, можуть і захищати їх. Відкритий інструмент аудиту на Claude Code, що запущений за дванадцять днів до атаки Kelp, вже вказав точний ризик. Не ідеальний — він оцінив ризик як medium, тоді як слід було — critical; не може проникнути без onchain-перевірки; і пропустив, що конфіг DVN можна запитати через LayerZero EndpointV2 contracts.

Але він поставив правильні питання, яких інші не задавали.

Саме цю модель слід застосовувати. AI як незалежний рівень безпеки, що будь-який LP, протокол або аудитор може використовувати для випередження руху коштів.

Безпечний DeFi не означає повільний DeFi

Після подій з Kelp поширена думка — у DeFi є проблеми безпеки. Я вважаю, що ця постановка — помилка.

У DeFi є проблеми control plane, ціноутворення комодитизації і дисципліни управління. Вони мають відомі рішення, багато з яких ще у банківських керівних документах тридцятилітньої давнини. Єдина перешкода — чи візьмуть їх на практиці засновники.

Безпечний DeFi не означає повільний. Slow і safe — різні характеристики. Відкритий доступ, комбінація, цілодобове глобальне розрахункове середовище; банківська дисципліна, незалежне викликанння, швидкість роботи і постійна гарантія — все це можливо одночасно.

Інструменти вже є. Playbook вже є. Капітал для безпечного DeFi — вже є.

DeFi тільки починається. І ми маємо зробити так, щоб через десять років воно існувало.