Разработка системы мультисиг-управления под ключ

Как избежать потерь из-за неверного управления мультисигом?

Потеря $625M в Ronin Bridge произошла не из-за уязвимости смарт-контракта — 5 из 9 ключей валидатора хранились в одной точке. Мультисиг был, порог был, но физическая изоляция отсутствовала. Это типичная ошибка: технически корректный контракт при плохом key management приводит к катастрофе. Без правильной архитектуры системы мультисиг-управления даже проект с TVL $1B под угрозой. Наши инженеры с 5+ лет опыта помогают избежать таких рисков. Мы разрабатываем системы мультисиг-управления под ключ, которые включают и техническую архитектуру, и организационные процедуры. Это более чем 20 реализованных проектов с разными требованиями к безопасности.

Правильно настроенная система мультисиг-управления не только предотвращает потери, но и экономит средства на аудите. В одном проекте мы заменили кастомный контракт на Safe с Guard и сэкономили клиенту более $50k на аудите — проверенный код Safe уже аудирован многократно. Кроме того, атаки на кросс-чейн мосты (не только Ronin) обошлись экосистеме более чем в $2 млрд. Большинство можно было предотвратить правильным распределением ключей и настройкой guards. По данным Chainalysis, в 2023 году потери от bridge hacks превысили $2.5 млрд — это в 3 раза больше, чем от прямых взломов DeFi-протоколов.

Когда нужен кастомный мультисиг?

Три случая из практики:

• Нестандартные правила кворума. Протокол хочет: 2/5 для транзакций до $10k, 4/5 для $10k-$1M, 5/5 для >$1M. Safe не поддерживает динамический threshold. Решение — Safe + кастомный guard (SafeGuard), который проверяет сумму и требует дополнительные подписи.
• On-chain голосование по транзакциям. Если решения должны проходить через токен-голосование (snapshot + исполнение через мультисиг), стандартный Safe + Governor + Timelock работает. Если нужна делегированная схема с взвешенными голосами — кастомная интеграция.
• Не-EVM чейны. Для Solana — программа на Anchor с secp256k1 или нативные multisig accounts. Для Aptos/Sui — кастомные Move-модули.

Как выбрать архитектуру мультисиг-системы?

Архитектура зависит от баланса безопасности и оперативности. Safe (бывший Gnosis Safe) — стандарт де-факто для мультисиг-управления в Web3, используется Uniswap DAO, Aave, Lido, ENS и сотнями других. Аудирован многократно, открытый исходный код, модульная архитектура.

Почему Safe лучше кастомного контракта?

3+ года в production на суммах >$100B TVL — это аргумент весомее любого аудита нового контракта. Кастомный мультисиг разрабатываем только при явных ограничениях: нестандартная цепочка (не EVM), специфическая логика кворума, требования к privacy. По нашим данным, использование Safe снижает сроки внедрения в 5 раз по сравнению с кастомной разработкой, а стоимость аудита — в 3 раза.

Архитектура Safe — разработка системы мультисиг

Safe работает по схеме M-of-N: транзакция исполняется, когда собирает M подписей из N владельцев. Под капотом — execTransaction() с массивом подписей ECDSA в упорядоченном виде. Сигнатуры можно собирать off-chain (через Safe{Wallet}) или on-chain через approveHash().

// Формат подписи для Safe // r (32 bytes) + s (32 bytes) + v (1 byte) // v=1: approved hash on-chain // v=2: eth_sign signature // v>30: EIP-1271 contract signature 

Safe Modules: расширение без кастомного контракта

Модули — это отдельные контракты с правом вызывать execTransactionFromModule() на Safe. Это позволяет добавить автоматизацию (например, ежедневные выплаты до лимита X без мультисиг) без изменения основного контракта.

Стандартные модули: Allowance Module (делегирует право на расходы до лимита), Safe{Recovery Module} (социальное восстановление доступа). Кастомные модули разрабатываем под специфику клиента.

Главный риск модулей: модуль с уязвимостью обходит весь мультисиг. Любой кастомный модуль требует аудита с той же серьёзностью, что и сам контракт казначейства.

Что такое Safe Guards и как они усиливают защиту?

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

• Whitelist разрешённых адресов-получателей
• Лимиты на сумму транзакции
• Time-based restrictions (нет транзакций в выходные — для regulated protocols)
• Блокировка изменения owners без дополнительного согласования

interface Guard { function checkTransaction( address to, uint256 value, bytes calldata data, Enum.Operation operation, uint256 safeTxGas, uint256 baseGas, uint256 gasPrice, address gasToken, address payable refundReceiver, bytes memory signatures, address msgSender ) external; function checkAfterExecution(bytes32 txHash, bool success) external; } 

Как обеспечить надежное хранение ключей?

Даже идеальный контракт бесполезен при плохом key management. Минимальные требования:

• Ключи в hardware wallets (Ledger, Trezor), не в hot wallets
• Географическое распределение подписантов
• Задокументированный процесс замены скомпрометированного ключа
• Регулярная проверка, что все подписанты имеют доступ к своим ключам
• Timelock поверх мультисига для критических операций

Мы помогаем не только с техническим деплоем, но и с разработкой операционных процедур. По статистике, 95% уязвимостей мультисиг-систем связаны именно с организационными ошибками, а не с кодом.

Чек-лист безопасности при развёртывании мультисига:

• Каждый key holder использует отдельное устройство (Ledger/Trezor)
• Ключи хранятся в трёх географически разных точках
• Настроен процесс восстановления доступа (social recovery или timelocked admin)
• Все модули и guards проходят аудит
• Регулярно (раз в квартал) тестируется доступ всех подписантов

Что входит в работу

• Анализ сценариев управления и рисков
• Выбор архитектуры (Safe или кастом)
• Разработка конфигурации, модулей и guards
• Развертывание и тестирование в testnet
• Аудит смарт-контрактов (если кастомные компоненты)
• Документация по процедурам key management
• Обучение команды подписантов
• Техническая поддержка после запуска

Процесс и сроки

Стоимость рассчитывается индивидуально после описания требований.