Децентрализованные оракулы: почему сбой ценовых данных привел к потере депозита

Проблема возникает раньше: блокчейн видит транзакции, а реальный рынок остаётся за его пределами.

Критическая зона децентрализованных оракулов в блокчейне — ошибки интеграции. По данным Chainalysis, в 2022 году протоколы DeFi потеряли около 403,2 млн долларов в результате 41 атаки с манипулированием ценовыми оракулами. В марте 2026 года сбой защитного механизма CAPO в Aave привёл к ошибочной ликвидации залогов 34 аккаунтов на сумму около 26 млн долларов.

Цифры разные, механика похожая: цена, которой смарт-контракт доверился, превратилась в параметр чужого депозита. Дальше работает строгая логика протокола.

Слепое место блокчейна и роль оракула

Смарт-контракт живёт по правилам, заранее записанным в код. Он не открывает котировки, не звонит в API биржи и не сверяет данные с реальным рынком. Для внешней информации у него есть специальный мост — оракул.

Оракул собирает данные из внешних источников, передаёт их в блокчейн и позволяет смарт-контракту использовать их в расчётах. Chainlink и Pyth относятся к наиболее известным решениям в этой области. У децентрализованной схемы несколько поставщиков данных, агрегация, проверки отклонений и защита от части сбоев.

Но здесь легко перепутать две разные вещи: качество источника цены и качество кода, который её использует. Оракул может стабильно передавать данные, а принимающий смарт-контракт запросить не тот рынок, неверно пересчитать десятичные знаки или применить устаревший показатель.

Путь цены до ликвидации выглядит примерно так:

1. Поставщики оракула получают котировки с рынков.

2. Агрегатор отбрасывает часть выбросов и формирует ценовой поток данных.

3. Смарт-контракт протокола запрашивает нужную пару активов.

4. Код сопоставляет цену залога с размером долга.

5. При достижении порога позиция попадает под ликвидацию.

Сбой может возникнуть на любом участке. Испорченные данные поставщика, неверная агрегация, устаревшая цена в блоке, ошибка округления или неправильная логика протокола — всё это даёт один результат: смарт-контракт получает число и принимает решение.

Особенно уязвивы тонкие рынки. В децентрализованном обменнике (AMM) цена зависит от соотношения активов в пуле. Крупная сделка способна быстро сдвинуть котировку. Если протокол берёт именно эту спотовую цену, трейдер может временно переписать показатель, использовать его в своих расчётах и затем вернуть рынок к прежнему состоянию.

Получается цена, математически корректная для конкретного пула, но не representative для всего рынка. Смарт-контракт проверит формулу и посчитает её правильной.

Оракул может безупречно сообщить цену, а протокол всё равно примет решение по неверному активу.

Анатомия оракульного сбоя

Ликвидация в DeFi — это автоматическое исполнение заранее установленных правил. Заёмщик оставляет залог, получает кредит под него и поддерживает позицию выше порога. Когда обеспечение становится недостаточным, любой участник может погасить часть долга и забрать залог с дисконтом.

На многих протоколах состояние позиции показывает коэффициент здоровья. Когда он опускается ниже установленного уровня, залог можно ликвидировать. Само по себе это нормальный механизм: он освобождает заблокированные активы без участия заёмщика.

Проблема возникает, когда протокол получает неверную цену. Тогда:

1. Залог оценивается ниже реальной стоимости.

2. Коэффициент здоровья ошибочно падает.

3. Смарт-контракт считает позицию обеспеченной недостаточно.

4. Ликвидатор погашает часть долга.

5. Заёмщик теряет залог или его часть, а ликвидатор получает актив по сниженной цене.

Здесь важно distinctions между взломом кода и ошибочной интерпретацией данных. В некоторых инцидентах злоумышленник использовал уязвимость. В других смарт-контракт исполнил полностью формально корректное правило, опираясь на фиктивно искажённую цену.

Типичные ошибки децентрализованных оракулов выглядят так:

• Устаревшая цена. Данные не обновились, но протокол продолжил их использовать. В блокчейне нет встроенного сигнала, что котировка стала неактуальной.
• Манипуляция спотовой ценой. Крупная сделка кратковременно сдвигает цену в тонком пуле, после чего атакующий использует искажённый показатель.
• Неверная пара активов. Контракт запрашивает цену другого рынка или другого токена.
• Ошибка с единицами измерения. Цена хранится с восемью знаками, а контракт трактует её как число с двумя.
• Неправильная логика страхования. Защитный модуль использует цену, ошибочную цену или недостаточно надёжный источник.
• Отсутствие независимого резервирования. Основной и резервный источники зависят от одного проблемного пула.

Последний пункт особенно неприятен. Резервная цена выглядит надёжной, пока разработчик не обнаруживает, что оба источника используют один и тот же дефект. Redundancy в коде даётся дёшево, independence приходится проектировать отдельно.

Спотовая ликвидность: уроки Mango Markets и Makina Finance

Mango Markets: цена became collateral

В октябре 2022 года с платформы Mango Markets в сети Solana было выведено 117 млн долларов. Механизм эксплойта строился на искусственном повышении цены токена MNGO. Оракул передал протоколу искажённую котировку, завышенная стоимость актива позволила получить позицию с крупным залогом и вывести средства.

Этот случай важен по другой причине. Он показывает границу ответственности смарт-контракта: код исполнял заложенную логику. Если котировка входит во входные данные как достоверная, контракт не обязан заново проверять экономическую правдоподобность сделки, изменившей эту котировку.

Атакующий фактически подменил базу оценки залога. Чем крупнее доступная ликвидность, тем дороже обходится такая манипуляция. Чем тоньше рынок, тем дешевле.

Makina Finance: цена пула без TWAP

В январе 2026 года протокол Makina Finance потерял 4,13 млн долларов. Для атаки использовали мгновенный кредит — flash loan, то есть заём, который выдаётся и возвращается внутри одной транзакции. Объём привлечённых средств составил 280 млн USDC.

Здесь 280 млн — размер временно доступного кредита, а не размер похищенной суммы. Ущерб оказался значительно меньше.

Уязвимость находилась в функции accountForPosition() и оракуле MachineShareOracle. Контракт читал спотовые данные пула Curve DUSD/USDC, не применяя средневзвешенную по времени цену — TWAP — и не выполняя необходимую валидацию. Внутри одной транзакции расчётная стоимость доли выросла с 1,01 до 1,33. На этом искажённом значении строились дальнейшие расчёты.

Здесь flash loan выступал финансовым инструментом. Корневая уязвимость находилась в выборе цены и логике её использования. Быстрый кредит дал атакующему капитал для масштабной операции, но сам по себе не создал ошибку в протоколе.

Спотовая цена подходит для рынка, где сделка сопровождается глубокой ликвидностью. В тонком пуле она превращается в управляемый параметр.

CAPO в Aave: защитный механизм сломался

В марте 2026 года в Aave произошёл сбой CAPO — Correlated Asset Price Oracle. Этот механизм задуман как дополнительная защита для активов, цена которых связана с другими рыночными параметрами.

Ошибочный показатель wstETH составил 1,1939 при рыночном значении 1,228. На основании этих данных протокол начал ошибочно ликвидировать позиции. Пострадали 34 аккаунта, общий объём — около 26 млн долларов, или 10 938 wstETH.

Здесь зафиксирован именно программный сбой защитного механизма. Данные указывают на ошибочную логику CAPO, поэтому называть инцидент прямым взломом было бы неточно.

Случай показывает неприятную особенность сложных систем: резервный модуль тоже может перепутать рынок. Если он проверяет цену через производную метрику, корреляцию или иной агрегированный показатель, ошибка может перейти из основной защиты в резервную.

В мартовском инциденте несколько факторов сложились в одну цепочку:

• CAPO передал протоколу ошибочную цену.
• Защитная логика не остановила каскад ликвидаций.
• Заёмщики не успели исправить позиции или вывести залог.
• Автоматизация выполнила расчёт без участия человека.

Здесь важно понимать границу ответственности разных компонентов. Chainlink, Pyth или другой агрегатор может давать качественные данные, пока принимающий контракт обращается к ним корректно. Ошибка потребителя остаётся ошибкой потребителя.

Поэтому фраза «протокол использует Chainlink» сама по себе ничего не гарантирует. Нужно смотреть, какие данные запрашиваются, как проверяется их свежесть и что происходит, когда основной источник выходит за допустимые границы.

Масштаб: почему сбои оракулов опасны

Отдельные атаки наносят крупный ущерб, но масштаб проблемы виден в накопленной статистике.

Исследование Университета Винчестера и SyntiFi Risk Intelligence зафиксировало 72 flash-loan-атаки на DeFi за период с февраля 2020 по июль 2024 года. Общий связанный с ними ущерб достиг 1,211 млрд долларов. Свыше 81% совокупных потерь пришлось на четыре вектора атак, включая манипулирование ценами через оракулы.

Читать эту цифру нужно аккуратно. Flash loan — это способ получить капитал в рам одной транзакции. Сама возможность быстро занять крупную сумму не создаёт уязвимость. Её используют, когда в протоколе уже есть ошибка в ценообразовании, проверке залога или расчёте долга.

Отдельные агрегаторы потерь также считают разные события. Прямая кража из пула уменьшает средства протокола. Ошибочная ликвидация забирает залог заёмщика, и этот ущерб может учитываться иначе. Точной общ цифры потерь всех розничных заёмщиков за всю историю DeFi нет. Агрегированная статистика обычно фиксирует прямые потери протоколов и отдельные инциденты, поэтому складывать её с частными ликвидационными списаниями рискованно.

Для риск-менеджмента это означает простую вещь: средняя цена сбоя мало о чём говорит. Десять мелких ликвидаций способны разрушить доверие сильнее одного крупного взлома. Пользователь замечает не средние потери отрасли, а собственную позицию, закрытую в неподходящий момент.

Технический стандарт безопасной интеграции

Цена, отданная смарт-контракту, проходит несколько уровней обработки. Каждый требует отдельной защиты.

Как выбирать источник цены

Ни один механизм не покрывает все сценарии. У волатильного рынка TWAP способен отставать, у рынка с двумя поставщиками медиана теряет смысл, а спотовая цена остаётся самым очевидным местом для атаки.

Минимальные требования к контракту

1. Корректная пара и направление. ETH/USDC и USDC/ETH нельзя путать. Направление котировки должно явно задаваться контрактом.

2. Проверка единиц измерения. Десятичные знаки токенов, цены и доли необходимо приводить к общей базе до любых вычислений.

3. Контроль свежести. Разработчик должен проверять updatedAt и допустимый возраст данных через heartbeat — максимальный интервал обновления фида.

4. Защита от одноразовых всплесков. Для чувствительных рынков нужны TWAP, медиана или другой механизм, снижающий влияние одной аномальной сделки.

5. Порог отклонения. Резкое расхождение текущей цены с предыдущей или с рыночным ориентиром должно запускать аварийный предохранитель.

6. Независимый резерв. Резервный источник не должен повторять путь получения данных основного.

7. Обработка аномальных значений. Нулевая, отрицательная, чрезмерно старая или экстремальная цена должна приводить к остановке операций.

8. Проверка на границах. Сценарии устаревания, обвала ликвидности, манипуляции и ошибок округления нужно воспроизводить до запуска в основной сети.

Отдельный слой защиты нужен самому протоколу. Механизм паузы, ограничение новых займов и автоматическое прекращение ликвидаций при аномальной цене могут сохранить капитал пользователя в момент, когда данные уже испорчены. Резервный модуль без такого предохранителя иногда создаёт лишь видимость безопасности.

Аудит проверяет код, но не исправляет неверную рыночную модель. Бounty-программаrewardи заранее сообщённый баг репутацию проекта. Работают проверки на устойчивость, моделирование сценариев и continuously обновляемые мониторинги.

Что это значит для заёмщика

Мой простой фильтр для DeFi-кредита выглядит так:

• Проверяю, какая цена используется для залога и обновляется ли она.
• Смотрю на порог ликвидации и оставляю запас между текущим состоянием позиции и этим порогом.
• Избегаю максимального кредитного плеча: небольшая ошибка цены при полном залоге становится полной потерей депозита.
• Осторожно отношусь к тонким рынкам и токенам с низкой ликвидностью. Именно там чаще возникают спотовые искажения.
• Проверяю, насколько быстро можно выйти из позиции при падении цены или росте ликвидаций.
• Читаю разборы прошлых инцидентов: важнее описание механизма сбоя, чем общие слова о «тестировании и аудитах».
• Не считаю страховочный фонд или решение DAO гарантией возврата средств.

Главный риск здесь иногда выглядит безобидно. Пользователь видит привычный интерфейс, понятный график и аккуратное значение коэффициента здоровья. За интерфейсом стоит набор допущений: цена актуальна, рынок достаточно глубокий, резервный источник независим, а код правильно переводит числа в единицы. Ошибка в любом допущении способна закрыть позицию раньше, чем цена придёт в норму.

Децентрализованный оракул улучшает источник данных, но не исправляет ошибки подключения. Chainlink и Pyth не являются гарантией безопасности; название агрегатора не заменяет проверку архитектуры. Смарт-контракт выполнит полученное значение без возражения, даже если оно противоречит рынку.

Поэтому защита капитала начинается с признания простого факта: цена в блокчейне — результат нескольких инженерных решений. Моя задача — убедиться, что эти решения выдержат сбой. Всё остальное — математика, риск-менеджмент и личная ответственность.