Дмитрий Коновалов1 апреля 2026 года рынок DeFi получил один из самых показательных инцидентов последних лет. Взлом Drift Protocol на сотни миллионов долларов оказался не классической ошибкой в коде, а комбинацией человеческого фактора и особенностей инфраструктуры Solana. Именно поэтому этот кейс быстро вышел за рамки одного протокола и стал обсуждаться как системная проблема индустрии.
Что произошло с Drift Protocol 1 апреля 2026 года
Drift Protocol — это крупный DeFi-протокол в сети Solana, который объединяет торговлю бессрочными фьючерсами, спотовые рынки и систему займов под залог. Пользовательские средства распределены между несколькими модулями, и именно эта связанная архитектура сыграла роль в масштабе инцидента.
1 апреля 2026 года протокол столкнулся с атакой, в результате которой злоумышленник получил доступ к привилегированным функциям управления. После этого начался вывод средств из разных сегментов системы, а команда была вынуждена экстренно остановить операции.
По разным оценкам, общий ущерб составил от 280 до 300 миллионов долларов.
Под удар попали сразу несколько направлений: кредитный модуль, торговые балансы пользователей и пулы ликвидности. Это важно, потому что речь идёт не о локальной проблеме, а о воздействии на всю систему сразу.
Почему этот взлом нельзя назвать «обычным багом»
На первый взгляд ситуация могла показаться типичным DeFi-эксплойтом. Однако довольно быстро стало понятно: смарт-контракты напрямую не ломали, а классической уязвимости в коде не обнаружено.
Ключевая особенность — характер атаки. Вместо поиска ошибки злоумышленник получил доступ к административным действиям протокола, то есть к тем операциям, которые обычно выполняются только доверенными участниками управления.
Это был не взлом кода, а перехват управления системой.
Речь идёт о механизме мультиподписи (multisig), где критические действия требуют подтверждения нескольких участников. В Drift за это отвечал так называемый Security Council — группа доверенных подписантов, через которых проходили изменения параметров протокола.
Именно этот уровень оказался слабым звеном, а не техническая реализация контрактов.
Почему масштаб оказался таким большим
Drift Protocol — это не один контракт и не один пул ликвидности. Это комплексная система, где пользовательские средства используются сразу в нескольких сценариях: торговля, кредитование, обеспечение позиций и управление рисками.
Когда злоумышленник получает доступ к административным функциям, он фактически влияет на всю эту структуру. Это позволяет менять параметры рынков, добавлять новые активы, управлять лимитами и условиями вывода средств.
В результате атака затрагивает не отдельный сегмент, а всю экономику протокола.
Именно поэтому последствия оказались такими масштабными. Речь шла не о точечном эксплойте, а о системном сбое на уровне управления.
Что важно понять уже на этом этапе
Инцидент с Drift показывает, что безопасность DeFi не ограничивается кодом. Даже если контракты прошли аудит и не содержат критических ошибок, это не гарантирует защиту средств пользователей.
Ключевую роль начинают играть процессы: кто подписывает транзакции, как проверяются действия и какие ограничения действуют на уровне управления. Если этот слой уязвим, защита смарт-контрактов уже не спасает.
Дальше важно понять, как именно злоумышленник получил эти подписи и почему атака началась задолго до фактического вывода средств.
Как произошёл взлом: от социальной инженерии к контролю над системой
Если рассматривать атаку по шагам, становится очевидно: ключевые события происходили не в блокчейне, а за его пределами. Именно там злоумышленник получил доступ к самому важному ресурсу — подписи участников управления.
Атака началась с людей, а не с кода.
Роль социальной инженерии
Основной инструмент — социальная инженерия. Это ситуация, когда участника убеждают подтвердить действие, не раскрывая его реального смысла или последствий. В контексте multisig это особенно опасно, потому что подпись сама по себе выглядит легитимной.
На практике процесс может выглядеть как обычная рабочая операция: приходит запрос, он объяснён в понятном контексте, и участник подтверждает его. При этом реальный эффект транзакции может быть неочевиден или замаскирован.
В Drift подписи были получены заранее, до момента атаки.
Как устроен Security Council
В Drift Protocol ключевые административные действия проходили через Security Council — орган управления на базе мультиподписи. Для выполнения операции требовалось подтверждение нескольких участников.
На момент атаки действовала схема «2 из 5», то есть достаточно было двух подписей для выполнения критического действия. Дополнительно отсутствовал timelock — механизм задержки, который даёт время на проверку и отмену транзакции.
Комбинация низкого порога и отсутствия задержки значительно снижает устойчивость системы.
Как был получен контроль
После получения необходимых подписей злоумышленник смог инициировать транзакции от имени управляющего органа. С точки зрения блокчейна всё выглядело корректно: подписи валидны, значит действия разрешены.
Именно в этом заключается ключевая проблема — сеть не может отличить «добросовестную» подпись от подписи, полученной через обман. Для неё это одинаковые операции.
Система выполняла команды, которые формально были разрешены.
В результате атакующий получил возможность менять параметры протокола, управлять активами и подготавливать следующую фазу атаки — вывод средств.
Почему это не баг смарт-контракта
Важно зафиксировать: в этом случае смарт-контракты работали корректно. Они выполняли именно те действия, которые были разрешены управляющим органом.
Разница с классическими эксплойтами в том, что здесь не было ошибки, которую можно воспроизвести. Вместо этого была уязвимость в процессе принятия решений.
Контракты не были сломаны — им дали неправильные команды.
Это переносит фокус с технической безопасности на организационную. И именно здесь появляется следующий элемент атаки — механизм, который позволил отложить исполнение подписанных транзакций.
Роль durable nonce: отложенное исполнение транзакций
Следующий важный элемент — механизм durable nonce в сети Solana. Он позволяет подписывать транзакции заранее и выполнять их позже, не привязываясь к короткому времени жизни обычных операций.
В стандартной ситуации транзакция должна быть выполнена быстро, иначе подпись устаревает. Durable nonce снимает это ограничение и делает возможной отложенную отправку.
Подпись и исполнение оказываются разнесены во времени.
Как это используется в нормальной работе
Этот механизм нужен для легитимных задач: например, когда подписи собираются офлайн или заранее согласуются несколькими участниками. Он повышает гибкость работы с транзакциями.
Но вместе с этим появляется и риск: после подписи участник теряет полный контроль над моментом исполнения.
Как это помогло атаке
В случае с Drift злоумышленник получил подписанные транзакции и не использовал их сразу. Он сохранил их и дождался подходящего момента для исполнения.
Когда началась атака, никаких новых запросов на подпись уже не требовалось. Все действия выглядели как обычные операции управляющего органа.
Самый важный этап атаки произошёл задолго до её видимого начала.
Почему это не уязвимость сети
Важно понимать: durable nonce сам по себе не является ошибкой или багом. Это инструмент, который работает так, как задумано.
Проблема возникает в сочетании факторов — недостаточной проверки транзакций, отсутствия ограничений и человеческого фактора. В такой конфигурации механизм начинает усиливать риски.
Именно поэтому следующий этап атаки уже связан не с технической стороной, а с экономической моделью протокола.
Как вывели средства: схема с CVT и залогом
После получения контроля над управлением злоумышленнику нужно было превратить административные права в реальные активы. Для этого использовалась стандартная механика DeFi — залог (collateral).
В нормальной ситуации пользователь предоставляет актив в качестве обеспечения и получает возможность занимать или выводить другие средства. В этой атаке тот же принцип был использован, но с подменой исходных условий.
Роль CarbonVote Token (CVT)
CarbonVote Token (CVT) не является значимым рыночным активом. В контексте атаки он использовался как искусственный инструмент, которому придали ценность через административные изменения.
CVT стал мостом между контролем над системой и выводом средств.
Как работала схема
Злоумышленник смог добавить или активировать CVT в качестве допустимого залога, а затем задать ему цену через механизмы оценки (oracle). После этого токен стал восприниматься системой как полноценное обеспечение.
Дальше происходило следующее: под этот «залог» открывался доступ к выводу реальных активов, которые уже имели рыночную стоимость. С точки зрения протокола всё выглядело корректно.
Система принимала искусственную стоимость за реальную.
Почему это стало возможным
В обычных условиях добавление нового залога проходит строгую проверку: анализ ликвидности, устойчивости цены и рисков манипуляций. Однако при захваченном управлении эти ограничения можно обойти.
Административные права позволяют изменять параметры, управлять источниками цен и снимать ограничения. Именно это и было использовано в атаке.
В итоге экономическая модель протокола оказалась подменена, а вывод средств стал логическим продолжением уже принятых решений.
Что было дальше: реакция команды и план восстановления
После начала атаки команда Drift Protocol довольно быстро перешла в режим кризисного управления. Первым шагом стала остановка ключевых операций — депозиты были заморожены, вывод средств приостановлен, а часть функций протокола отключена. Это стандартная практика в подобных ситуациях, но здесь она имела критическое значение: нужно было зафиксировать состояние системы и не дать атаке расшириться дальше.
Задача на первом этапе — остановить потери и стабилизировать систему.
Ключевые элементы атаки Drift Protocol
| Элемент | Что это | Роль в атаке | Почему это стало уязвимостью |
|---|---|---|---|
| Социальная инженерия | Манипуляция подписантами для получения легитимных подписей | Дала доступ к мультиподписи без взлома ключей | Подписанты не всегда видят реальный эффект транзакций |
| Multisig (Security Council) | Механизм управления через несколько подписей | Позволил выполнять административные действия | Низкий порог (2 из 5) и отсутствие задержки |
| Durable nonce | Механизм отложенного исполнения транзакций в Solana | Позволил использовать подписи позже | Разделение подписи и исполнения во времени |
| Отсутствие timelock | Нет задержки перед выполнением операций | Ускорило выполнение атакующих транзакций | Не было времени на отмену или реакцию |
| CarbonVote Token (CVT) | Искусственный залоговый актив | Использован для вывода реальных средств | Получил «ценность» через административные изменения |
| Oracle (оценка цены) | Источник данных о стоимости активов | Задал цену CVT внутри системы | Манипулируемая или недостаточно защищённая оценка |
Атака стала возможной не из-за одного сбоя, а из-за комбинации нескольких уязвимых уровней.
Обновление по восстановлению от 16 апреля 2026
Спустя две недели после инцидента команда представила публичный план восстановления. Он не выглядит как быстрое решение с мгновенной компенсацией — скорее это поэтапная модель, где возврат средств зависит от доступных ресурсов и поддержки партнёров. Такой подход ближе к реструктуризации, чем к классическому «возврату средств».
В основе плана несколько ключевых направлений: создание пула восстановления, привлечение внешнего финансирования, выпуск отдельного токена для компенсаций и подготовка к перезапуску протокола. Отдельно обсуждается участие крупных партнёров, включая возможную поддержку до 127,5 млн долларов со стороны Tether и еще 20 млн долларов от других участников рынка.
Важно: речь идёт о предложениях и переговорах, а не о полностью реализованной компенсации.
Что означает recovery framework для пользователей
Для пользователей это не сценарий «вернули деньги на следующий день». И даже не гарантия полного покрытия потерь. Модель восстановления растянута во времени и зависит от нескольких источников ликвидности.
На практике это означает, что часть средств может быть покрыта из пула восстановления, часть — через будущие механики протокола (например, отдельный компенсационный токен), а оставшаяся доля зависит от привлечённой поддержки. Пользователь в такой модели становится участником долгосрочного процесса возврата, а не просто получателем компенсации.
Возврат средств — это процесс, а не разовое событие.
Условия перезапуска протокола
Команда Drift отдельно подчеркнула: перезапуск невозможен без изменений в безопасности. И это логично — проблема возникла не в коде, а в процессах управления, значит именно их и нужно усиливать.
Среди заявленных мер — проведение независимых аудитов, пересмотр схемы управления, усиление контроля за подписанием транзакций и введение дополнительных ограничений, включая задержки перед выполнением критичных операций. Эти изменения направлены на устранение именно тех слабых мест, которые были использованы в атаке.
Что это меняет для рынка DeFi
Инцидент с Drift Protocol быстро вышел за рамки одного проекта и стал предметом обсуждения на уровне всей индустрии. Причина проста: он показал уязвимость, которая раньше воспринималась как второстепенная.
Это пример крупной потери средств без единого бага в смарт-контракте.
Главный вывод: безопасность — это не только код
Долгое время в DeFi доминировала идея, что надёжность протокола определяется качеством его кода. Если контракты прошли аудит — значит средства защищены. Случай с Drift показывает, что этого недостаточно.
На практике безопасность складывается из нескольких уровней: процессов подписания транзакций, архитектуры управления и экономической модели протокола. Если хотя бы один из этих элементов уязвим, вся система теряет устойчивость независимо от качества кода.
Почему multisig больше не считается абсолютной защитой
Мультиподпись долго воспринималась как надёжный барьер: нужно несколько участников, значит риск ниже. Но этот инцидент показал, что сама по себе схема не гарантирует безопасность.
Если процесс получения подписей уязвим, а проверка транзакций недостаточно строгая, количество подписантов не играет решающей роли. Особенно это критично при низком пороге подтверждения и отсутствии задержек перед исполнением операций.
Multisig защищает только тогда, когда защищён сам процесс подписания.
Уроки для всей индустрии
Из этого кейса уже формируется набор практических выводов, которые, скорее всего, станут стандартом для крупных протоколов. Речь идёт о введении обязательных задержек для критичных операций, разделении ролей внутри управления и улучшении интерфейсов подписания, чтобы участники видели реальный эффект своих действий.
Отдельное внимание уделяется контролю за залоговыми активами и источниками цен. Добавление нового актива должно проходить многоуровневую проверку, а не зависеть от одного управленческого решения. И, конечно, усиливается фокус на человеческом факторе — обучении, регламенте и операционной безопасности.
Даже самая надёжная система уязвима, если уязвим процесс вокруг неё.
Мнения экспертов
Владимир Логиков:
«Этот кейс показал неприятную правду: безопасность DeFi — это не только код, а дисциплина процессов. Если подписи можно получить через обман, никакой аудит контрактов не спасёт. Мы увидим рост требований к управлению и более жёсткие стандарты для multisig.»
Кононыхин Максим:
«История с CVT — это сигнал для всех протоколов с кредитными моделями. Контроль за залогом и его оценкой должен быть многоуровневым. Если governance может быстро добавить актив без глубокой проверки, это потенциальная точка системного риска.»
Выводы
Взлом Drift Protocol — это не история про баг, а история про цепочку решений и слабых мест, которые сложились в одну линию. Социальная инженерия дала подписи, механизм durable nonce позволил отложить их использование, multisig без ограничений дал доступ к управлению, а CVT превратил этот доступ в реальные деньги.
Каждый элемент по отдельности выглядит безопасным. Вместе — создаёт критическую уязвимость.
Именно поэтому этот инцидент важен для всего рынка. Он показывает, что следующая волна атак в DeFi будет направлена не столько на код, сколько на процессы. И вопрос уже не в том, возможны ли такие атаки, а в том, кто окажется готов к ним.