10 березня 2026 року сектор децентралізованих фінансів (DeFi) отримав черговий сигнал тривоги. Некоректна конфігурація ризикового оракула CAPO у протоколі Aave призвела до помилкової ліквідації приблизно $27 мільйонів у позиціях wstETH. Хоча протокол не зазнав збитків у вигляді поганого боргу, а постраждалі користувачі отримають повну компенсацію, цей випадок породив ширше питання: коли базова інфраструктура дає збій, як звичайні користувачі можуть проактивно захищати свої активи, не покладаючись на команди проектів для відшкодування?
Оракули є ключовим містком між позаланцюговими реальними даними та смартконтрактами в блокчейні, формуючи основу кредитних ринків DeFi. Якщо цей компонент виходить з ладу, навіть найстійкіші протоколи швидко занурюються у хаос. Використовуючи нещодавню подію ліквідації у Aave як кейс, ця стаття системно аналізує, як ризик оракула поширюється, і пропонує практичні стратегії захисту з точки зору користувача.
Ліквідація на $27 мільйонів: історія помилки в оракулі Aave
10 березня протокол Aave зіткнувся з несправністю у своїй системі оракула на основній мережі Ethereum та Prime-інстанціях, що призвело до некоректної ліквідації близько 10 938 позицій wstETH у приблизно 34 акаунтах на загальну суму $27 мільйонів. Треті сторони — боти для ліквідації — отримали прибуток близько 499 ETH під час інциденту.
Засновник Aave Стані Кулєчов пізніше підтвердив, що подія була спричинена помилкою конфігурації системи CAPO (Collateral Asset Price Oracle), а не вразливістю протоколу. Протокол не зазнав поганого боргу, а всі постраждалі користувачі отримають повну компенсацію за рахунок коштів, повернутих через BuilderNet і казну DAO. Загальна сума компенсації очікується не більше ніж 345 ETH.
Огляд хронології: як один параметр спричинив ланцюгову реакцію
Система CAPO, яку Aave запустив наприкінці 2024 року, є механізмом ризикового оракула, розробленим для запобігання атакам маніпуляції оракулами. Вона розраховує та подає максимальні курси обміну й оновлення темпів зростання через позаланцюгові хаотичні оракули, після чого застосовує логіку перевірки через смартконтракти в блокчейні. За понад рік роботи CAPO обробила понад 1 200 payload і 3 000+ параметрів без серйозних інцидентів.
10 березня ризиковий менеджер Aave Chaos Labs зіткнувся з невідповідністю між обмеженнями на блокчейні та намірами оновлення під час рутинної зміни параметрів. Ключові події хронології:
- Намір оновлення: Позаланцюговий процес Chaos Labs визначив, що параметр
snapshotRatioдля wstETH потрібно оновити до приблизно 1,2282, що відображає актуальний курс обміну за сім днів до цього. - Обмеження на блокчейні: Цей параметр обмежується механізмом безпеки смартконтракту — курс може зростати не більше ніж на 3% кожні три дні. Тому значення могло змінитися лише з приблизно 1,1572 до 1,1919, а не безпосередньо до цільового 1,2282.
- Невідповідність оновлення: Тим часом параметр
snapshotTimestampбув успішно оновлений до мітки часу за сім днів до цього. - Наслідки: Невідповідність між ratio і timestamp призвела до того, що система CAPO встановила стелю курсу обміну wstETH лише на рівні 1,1939, тоді як фактичний ринковий курс становив близько 1,2282 — різниця приблизно 2,85%. Це недооцінення спричинило масові ліквідації.
Аналіз даних: структурна помилка, що призвела до відхилення на 2,85%
| Метрика | Значення | Джерело/Пояснення |
|---|---|---|
| Загальна ліквідація | ~$27 мільйонів | Загальна вартість позицій, що постраждали |
| Ліквідована сума | ~10 938 wstETH | Загальна кількість wstETH, ліквідована примусово |
| Постраждалі акаунти | ~34 | Кількість користувачів, яких безпосередньо зачепило |
| Відхилення курсу | ~2,85% | Стеля курсу CAPO була нижчою за фактичний ринковий курс |
| Прибуток ліквідаторів | ~499 ETH | Доходи ботів-ліквідаторів |
| Компенсація користувачам | ≤ 345 ETH | Кошти, виділені DAO Aave на компенсацію, включаючи 141,5 ETH, вже повернені через BuilderNet |
Технічна причина цього інциденту — порушення атомарності оновлення параметрів. Модель безпеки CAPO залежить від синхронізованого оновлення параметрів, але позаланцюговий процес не врахував обмеження блокчейну, що спричинило невідповідність між snapshotRatio і snapshotTimestamp — параметрами, які мають змінюватися одночасно. Ця технічна деталь виявляє глибшу проблему: навіть після року стабільної роботи точки тертя між управлінням параметрами та виконанням на блокчейні можуть зберігатися у складних системах.
Дискусія: стійкість протоколу чи крихкість системи?
Інцидент викликав дебати за кількома напрямками:
Підтримуючі точки зору:
- Визнання стійкості протоколу: Багато хто вважає, що Aave продемонстрував зріле управління кризою. Chaos Labs і BGD Labs швидко знизили ліміт запозичення wstETH до 1 для постраждалих інстанцій і скоригували параметри через Risk Steward для відновлення курсу обміну. Відсутність поганого боргу розглядається як доказ ефективного контролю ризиків.
- Похвала механізму компенсації: Засновник Aave оперативно пообіцяв повну компенсацію, частково повернувши кошти через BuilderNet, а решту — за рахунок казни DAO. Такий підхід із пріоритетом користувача отримав широке визнання у спільноті.
Критичні та рефлексивні точки зору:
- Занепокоєння щодо складності оракула: Деякі стверджують, що хоча CAPO створювався для підвищення безпеки, його складна параметризація принесла нові ризики. Незначна помилка при оновленні параметра спричинила каскад на $27 мільйонів, що підкреслює крихкість інфраструктури DeFi.
- Справедливість механізмів ліквідації під питанням: Хоча подія виникла через технічну помилку, ліквідації відбулися згідно з правилами протоколу. Дехто вважає, що такі «несправедливі, але формально коректні» ліквідації виявляють етичну дилему автоматизованих систем — коли вхідні дані хибні, чи виправдане «коректне виконання»?
Критичний аналіз
Фактично:
- Помилка конфігурації CAPO дійсно призвела до недооцінки wstETH на близько 2,85%, що спричинило ліквідації на $27 мільйонів.
- Протокол не зазнав поганого боргу, а постраждалі користувачі отримають повну компенсацію.
- Коренем проблеми став позаланцюговий процес оновлення, який не врахував обмеження параметрів на блокчейні, а не дефект у базовій архітектурі CAPO чи оракула.
З точки зору:
- «Ризик оракула контрольований» проти «Складність підвищує ризик» — перша позиція базується на відсутності поганого боргу та швидкій реакції Aave; друга — на припущенні, що без своєчасного втручання наслідки могли бути набагато гіршими.
- Дебати щодо «справедливості ліквідації» — прихильники вважають, що прозоре виконання правил виправдане; критики стверджують, що коли джерело даних хибне, результат втрачає основу справедливості.
Спекулятивно:
- Деякі аналізи припускають, що подібні помилки конфігурації можуть існувати й в інших протоколах із складними механізмами оракула, але прямих доказів наразі немає.
- Обговорення того, чи «ризик оракула повністю врахований у ціні», здебільшого є екстраполяцією із цього випадку й не мають кількісної підтримки.
Вплив на індустрію: управління оракулами чекає на перегляд
Вплив цього інциденту на сектор DeFi можна розглядати у короткостроковій та довгостроковій перспективі:
Короткостроковий вплив:
- Обмежений вплив на довіру до Aave: Завдяки швидкій реакції та зобов’язанню щодо повної компенсації ринкова позиція Aave залишилася майже незмінною. Дехто навіть розглядає управління кризою як ознаку зрілості.
- Перевірка довіри до wstETH: Хоча учасники Lido підкреслювали, що подія не пов’язана із wstETH чи самим протоколом Lido, wstETH як ліквідований актив зазнав додаткового тиску продажу під час інциденту, що могло вплинути на оцінку ризику деяких власників.
- Прибутки ботів-ліквідаторів: Ліквідатори заробили близько 499 ETH, що підкреслює стимули для моніторингу й використання аномалій у DeFi-екосистемі.
Довгостроковий вплив:
- Перегляд процесів управління оракулами: Цей випадок змусить протоколи переглянути й посилити процеси оновлення параметрів оракула. Постмортем Chaos Labs чітко визначив «помилку позаланцюгового процесу, який не врахував обмеження блокчейну» як корінь проблеми. Потрібні більш суворі механізми симуляції та тестування перед оновленням.
- Переоцінка ризиків E-Mode: Ліквідації були зосереджені у позиціях Efficient Mode (E-Mode), які створені для підвищення капітальної ефективності для сильно корельованих активів, але можуть посилювати вплив окремих збоїв оракула. Протоколи мають переглянути припущення щодо ризиків E-Mode.
- Зростання потреби в освіті користувачів: Із ускладненням механізмів оракула бар’єр знань для розуміння ризиків протоколу зростає. Цей випадок знову доводить, що навіть «системи, які працювали стабільно рік», можуть зазнати несподіваних збоїв. Необхідна чіткіша інструкція для користувачів щодо ідентифікації й мінімізації таких ризиків.
Перспективи: три можливі шляхи еволюції ризику оракула
Враховуючи поточну структуру DeFi-екосистеми, можна прогнозувати кілька потенційних сценаріїв розвитку ризику оракула:
Сценарій 1: поступова оптимізація
Протоколи посилять управління параметрами оракула, впроваджуючи суворіші симуляції позаланцюгових процесів і мультипідписні рев’ю. Системи, подібні до CAPO, залишаться, але оновлення параметрів відбуватимуться «повільно, поетапно, із мультипідписом». Вплив на користувачів поступово зменшиться, хоча час від часу можуть траплятися дрібні помилки конфігурації.
Сценарій 2: системне покращення
Ця подія стимулює індустрію до створення стандартів конфігурації оракула, а спеціалізовані провайдери ризикових сервісів, такі як BGD Labs і Chaos Labs, відіграватимуть ще більшу роль. Протоколи можуть впровадити «дашборди моніторингу стану оракула» для відображення ключових параметрів у реальному часі. Користувачі зможуть проактивно моніторити ризики через сторонні інструменти.
Сценарій 3: екстремальний ризик
У більш песимістичному сценарії, якщо кілька оракула одночасно будуть некоректно налаштовані або атакуючі знайдуть способи маніпулювати оновленнями параметрів, можуть статися масові ліквідації. Якщо такі події трапляються під час високої волатильності ринку, це може спричинити кризи ліквідності й накопичення поганого боргу. Aave уникнув поганого боргу завдяки своєчасному втручанню, але не всі протоколи мають такі можливості екстреної реакції.
Самозахист користувача: чотири кроки для проактивного захисту від ризику оракула
Для користувачів DeFi проактивний захист — а не сподівання на компенсацію від проекту — є основою безпеки активів. Ось практичні стратегії, сформульовані на основі цього інциденту:
Розумійте свої заставні активи
wstETH як дериватив ліквідного стейкінгу має складну цінову кореляцію з ETH. Власникам потрібно розуміти, як його оцінюють оракули. Зазвичай протоколи перехресно перевіряють ціни з кількох джерел, але механізми, подібні до CAPO, можуть додавати додаткові обчислювальні шари. Користувачам слід ознайомитися з документацією протоколу щодо конфігурації оракула для конкретних активів.
Моніторте ризикові параметри протоколу
- Слідкуйте за провайдерами ризикових сервісів: Звіти організацій, таких як Chaos Labs, часто сигналізують про потенційні проблеми на ранньому етапі. Користувачі можуть підписатися на цих провайдерів у X (колишній Twitter) чи Discord для отримання оновлень.
- Розумійте обмеження оновлення параметрів: Як показав цей інцидент із правилом «зростання на 3% кожні три дні», кожен актив має специфічні правила оновлення параметрів оракула. Хоча звичайним користувачам складно відстежувати всі технічні деталі в реальному часі, форуми управління спільнотою часто обговорюють коригування параметрів.
Диверсифікуйте ризики й встановлюйте запас безпеки
- Уникайте надмірної концентрації в одному активі: Навіть у E-Mode не варто вкладати всі позиції в один сильно корельований актив. Диверсифікація застави допомагає зменшити загальний ризик у разі збою оракула конкретного активу.
- Підтримуйте здоровий запас безпеки: Під час волатильності ринку чи дрібних відхилень оракула більший health factor забезпечує буфер. Не варто доводити співвідношення запозичення до межі — залишайте мінімум 20% запасу безпеки.
- Відстежуйте пороги ліквідації щодо поточних цін: Регулярно перевіряйте, наскільки близько ваші позиції до ліквідації. Якщо розрив надто малий, навіть відхилення оракула на 2%-3% може спричинити ліквідацію — як показав цей випадок.
Використовуйте інструменти моніторингу й сповіщення
- Налаштуйте моніторинг на блокчейні: Платформи, такі як Forta, дозволяють встановити сповіщення про ризики для протоколів, якими ви користуєтесь. Отримуйте оперативні повідомлення про значні зміни параметрів чи аномалії оракула.
- Використовуйте дашборди ризиків DeFi: Інструменти, такі як DeBank і Zapper, не лише показують огляд активів, а й інтегрують індикатори ризику. Користувачі можуть переглядати загальний статус кредитування протоколу й ризики ліквідації.
Розумійте межі «компенсації»
Обіцянка Aave щодо повної компенсації відображає відповідальне управління проектом, але це не повинно призводити до самозаспокоєння користувачів. У довгостроковій перспективі не всі протоколи мають можливість чи бажання відшкодовувати збитки від технічних збоїв. Користувачам слід управляти ризиками із налаштуванням «компенсації не очікується».
Висновок
Помилка конфігурації оракула Aave стала одночасно стрес-тестом для управління ризиками DeFi та сигналом для підвищення обізнаності користувачів про ризики. За ліквідаціями на $27 мільйонів стояла технічна помилка, спричинена невідповідністю параметрів, що підняла ширше питання співіснування зі складними системами.
Для користувачів ризик оракула ніколи не можна повністю усунути, але його можна управляти через розуміння механізмів, моніторинг подій і встановлення розумних запасів безпеки. У DeFi найнадійніший захист завжди походить від власної обізнаності й проактивного захисту користувача. Коли межі «код — це закон» інколи дають тріщину, лише ті, хто добре підготовлений, можуть пройти крізь бурю без втрат.
