Уязвимость мультисиг кошельков ударила по StablR на $2 800 000. Европейский эмитент стейблкоинов, полностью совместимый с MiCA, потерял контроль над эмиссией за несколько часов. Не из-за бага в смарт-контракте. Не из-за атаки на блокчейн. Один скомпрометированный приватный ключ и схема 1-of-3, в которой одна подпись решает всё.
Звучит дико, но это реальность 2026 года. Проект прошёл юридическую экспертизу, KYC, AML, отчётность по резервам. А техническая архитектура управления оказалась дырявой настолько, что атакующему хватило одного ключа, чтобы перевыпустить миллионы токенов из ничего. Сейчас разберём пошагово, что произошло, и главное: как ты сам можешь проверить и закрыть такие дыры в своих контрактах или казначействе.
Как сработала уязвимость мультисиг кошельков StablR
Контракт эмиссии EURR и USDR управлялся через мультиподпись с порогом 1-of-3. По-человечески: любой из трёх администраторов мог единолично подписать критическую транзакцию, включая изменение списка владельцев. Это не защита, это иллюзия защиты с дополнительными целями для атаки.
Дальше всё пошло по учебнику. Злоумышленник получил приватный ключ одного из админов (как именно, публично не раскрыто, скорее всего фишинг или заражённое устройство), зашёл в админ-панель контракта, добавил свой адрес в owners, удалил двух легитимных подписантов и стал монопольным управляющим эмиссией. Несколько кликов, и проект больше не контролирует собственные токены.
А теперь к сути. После захвата атакующий выпустил 4,5 млн EURR и 8,35 млн USDR без обеспечения, раскидал их по DEX-пулам с тонкой ликвидностью и слил всё в 1115 ETH. Рынок отреагировал моментально: EURR и USDR потеряли паритет к USDT, классический депег без механизма восстановления.
Схема атаки на мультисиг StablR: 1-of-3 порог → компрометация одного ключа → захват управления → нес
Почему 1-of-3 хуже одиночного ключа
Логика мультиподписи в том, чтобы убрать единую точку отказа. Нужно несколько подписей, значит сложнее взломать. Но порог 1-of-3 эту логику инвертирует и превращает защиту в антизащиту.
Считай сам. При одиночном ключе у атакующего одна цель: ты. При 1-of-3 целей три, и достаточно сломать любую. Три человека, три устройства, три уровня операционной гигиены, и слабейшее звено решает за всех. Если один из админов хранит ключ в браузерном расширении на ноутбуке с пиратским софтом, остальные двое могут быть хоть в бункере, это не поможет.
Вот сравнение порогов, чтобы было нагляднее:
| Схема | Целей для атаки | Подписей нужно | Уровень риска |
|---|---|---|---|
| Одиночный ключ | 1 | 1 | Высокий |
| 1-of-3 | 3 | 1 | Очень высокий |
| 2-of-3 | 3 | 2 | Средний |
| 3-of-5 | 5 | 3 | Низкий |
| 4-of-7 + Timelock | 7 | 4 | Минимальный |
Для казначейства и критических операций общая практика индустрии: квалифицированное большинство, 3-of-5 или 4-of-7, плюс холодное хранение ключей. Аппаратный кошелёк, физически изолированный от сети. Подробнее про настройку холодного хранения мы разбирали в гайде по UNX и SEE на Ledger и Trezor: это не паранойя, а базовая гигиена для любого, кто управляет суммами больше зарплаты.
Почему MiCA не спасла: регуляция и техника живут отдельно
Тут самое неприятное для всей индустрии. StablR соблюдал MiCA полностью. Документация, резервы, раскрытие, лицензированные партнёры, всё чисто. MiCA говорит, кто имеет право выпускать токены и как они должны быть обеспечены. MiCA не говорит, какой порог мультиподписи ставить в операционном контракте.
И это не упущение регулятора. Техническая архитектура у каждого проекта своя, стандартизировать её законом нереально. MiCA создаёт правовое поле, но не заменяет security audit, не диктует пороги и не проверяет, как админ хранит сид-фразу. Между юридическим соответствием и операционной безопасностью пропасть, и StablR в неё провалился.
Похожая история была при взломе кошелька Polymarket: тоже компрометация ключа, а не уязвимость кода. Регуляция защищает от мошеннических схем эмитента. От операционных ошибок команды она не защищает вообще.
Что должна была сделать команда: пошаговый чек-лист
Проблема не в мультиподписи как инструменте. Проблема в конкретных решениях. Давай по пунктам, что нужно сделать тебе, если ты управляешь казначейством или критическим контрактом.
- Шаг 1: подними порог. Открой админ-панель Safe (бывший Gnosis Safe), зайди в Settings, выбери Owners, нажми Change threshold. Для контракта эмиссии минимум 3-of-5. Для повседневных операций 2-of-3 ещё допустимо, для критики нет.
- Шаг 2: перенеси ключи на хардвер. Каждый подписант подключает Ledger или Trezor к Safe через WalletConnect. Никаких MetaMask на рабочем ноутбуке для холодного казначейства. Совет: один из ключей храни на устройстве, которое физически не выходит в сеть кроме момента подписи.
- Шаг 3: включи Timelock. Любое изменение состава owners или параметров эмиссии проходит через задержку 24-72 часа. Готовые контракты OpenZeppelin TimelockController, подключаются как module к Safe.
- Шаг 4: настрой мониторинг. Tenderly, OpenZeppelin Defender или Forta. Создай алерт на события AddedOwner, RemovedOwner, ChangedThreshold. Попробуй сначала на тестнете: добавь сам себя в owners и убедись, что алерт прилетел в Telegram за секунды.
- Шаг 5: проведи учения. Раз в квартал имитируй компрометацию одного ключа. Проверь, успеваете ли вы отменить подозрительную транзакцию за окно Timelock.
Ни один из этих шагов не требует юриста или лицензии. Всё описано в открытых стандартах безопасности смарт-контрактов. Разбор уязвимостей DeFi 2025-2026 показывает: подавляющее большинство крупных взломов это не экзотика, а базовые операционные косяки.
Почему команды раз за разом наступают на те же грабли
Скорее всего, StablR потратил большие деньги на юридическое соответствие. MiCA это долго и дорого: консультанты, аудиты резервов, отчётность регулятору. На фоне этих счетов настройка Timelock и выбор порога выглядят как мелочь, которую сделают потом. Это потом не наступает.
К слову, та же дилемма у любого проекта с реальными активами на блокчейне, включая структуры с PoR и PoL механизмами вроде UniMex: юридическая оболочка и техническая безопасность это разные дисциплины, разные специалисты, разные бюджеты. Когда приоритет уходит в одну сторону, вторая становится дырой. Внешне всё выглядит надёжно, а внутри 1-of-3 на эмиссии.
Удивляет другое. Все эти механизмы (Timelock, мониторинг, аппаратные ключи) существуют годами. Они бесплатны или почти бесплатны. Документация в открытом доступе. И всё равно проект на $2,8 млн обходится без них, пока не становится поздно.
Это аналитический разбор по публичным данным об инциденте, не инвестиционная рекомендация. Я не аудитор безопасности и не юрист, перед запуском своих контрактов проверяй настройки сам и зови специалистов.
Как проверить порог мультисига в чужом контракте?
Зайди на Etherscan, открой адрес контракта Safe, во вкладке Read Contract найди функцию getThreshold. Нажми Query, увидишь число подписей. Рядом getOwners покажет список адресов. Если порог 1 при нескольких owners, беги.
Что делать, если я подозреваю утечку своего ключа?
Немедленно инициируй транзакцию замены этого owner на новый адрес через оставшиеся подписи, если порог позволяет. Параллельно выведи активы с любых контрактов, к которым ключ имеет доступ. Уведоми остальных подписантов через канал, к которому скомпрометированное устройство точно не имеет доступа: голосовой звонок, не Telegram с того же ноутбука.
Timelock замедляет легитимные операции, это не мешает работе?
Да, мешает, и в этом смысл. Для операций, где скорость важнее (свопы, ребалансировка) держи отдельный operational кошелёк с маленьким лимитом. Казначейство и эмиссия живут под Timelock, оперативка без него.
Сертифицированный замок на двери стоит дорого и блестит. Но если ключ от него лежит под ковриком у одного из трёх жильцов, домушнику не нужно ломать замок. Он просто заходит.