| Поверхность | Что делает | Главный риск |
|---|---|---|
| Owners + threshold | Авторизуют обычный execTransaction | Компрометация или потеря нужного числа owner keys |
| Module | Вызывает execTransactionFromModule по своей логике | Перевод без нового owner-threshold для каждой операции |
| Transaction guard | Проверяет обычную Safe transaction до и после execution | Ошибка или malicious logic блокирует операции |
| Fallback handler | Обрабатывает неизвестные core selectors и добавляет интерфейсы | Неожиданная логика подписи, callback или dispatch |
- Поверхность
- Owners + threshold
- Что делает
- Авторизуют обычный execTransaction
- Главный риск
- Компрометация или потеря нужного числа owner keys
- Поверхность
- Module
- Что делает
- Вызывает execTransactionFromModule по своей логике
- Главный риск
- Перевод без нового owner-threshold для каждой операции
- Поверхность
- Transaction guard
- Что делает
- Проверяет обычную Safe transaction до и после execution
- Главный риск
- Ошибка или malicious logic блокирует операции
- Поверхность
- Fallback handler
- Что делает
- Обрабатывает неизвестные core selectors и добавляет интерфейсы
- Главный риск
- Неожиданная логика подписи, callback или dispatch
Module добавляет второй путь исполнения
Базовый мультисиг для малого бизнеса полезен только после проверки расширений. Safe хранит enabled modules в linked list и позволяет читать их через getModulesPaginated. Разрешённый module вызывает execTransactionFromModule; core проверяет, что caller включён, но не собирает owner signatures заново. Ограничение суммы, адресов или времени существует лишь тогда, когда его действительно реализует и соблюдает код module.
Guard способен разрешить меньше, но и остановить всё
Transaction guard вызывается вокруг обычного execTransaction и может проверять destination, value, data и operation. Safe прямо предупреждает: сломанный guard способен создать denial of service. В Safe 1.5.0 ModuleManager также поддерживает отдельный module guard для execTransactionFromModule. Эти адреса нельзя смешивать: transaction guard не автоматически проверяет module path, а наличие module guard нужно подтверждать по версии и on-chain storage.
Очередь и Safe nonce остаются отдельной задачей: guard отвечает на допустимость исполнения, но не превращает off-chain предложение в on-chain отмену. Если guard отклонил вызов, сначала сохраните revert data, guard address и точный payload; не создавайте конкурирующие предложения ради обхода неизвестного правила.
Fallback handler расширяет интерфейс proxy
Когда selector не совпадает с core-функцией Safe, fallback manager может переслать calldata настроенному handler и добавить original caller в конец. Официальные handlers реализуют token callbacks, ERC-1271 signatures или дополнительные dispatch rules, но произвольный handler расширяет attack surface. Проверьте его runtime code, proxy/implementation и конфигурацию так же строго, как аудит смарт-контракта, а не по знакомому имени в приложении.
| Наблюдение | Вывод | Следующее действие |
|---|---|---|
| Modules пусты, guard и fallback нулевые | Дополнительные paths по этим slots не найдены | Всё равно сверить singleton/version, owners и threshold |
| Есть неизвестный enabled module | Возможен самостоятельный execution path | Остановить пополнение; получить code, config, audit и removal plan |
| Есть transaction guard | Обычные операции зависят от его pre/post checks | Проверить код и тест удаления/аварийного исполнения |
| Есть fallback handler | Proxy обслуживает дополнительные selectors/callbacks | Проверить handler implementation и ожидаемые interfaces |
| Safe 1.5.0 использует module guard | Module executions имеют отдельный контрольный слой | Проверить оба guard-address и их recovery независимо |
- Наблюдение
- Modules пусты, guard и fallback нулевые
- Вывод
- Дополнительные paths по этим slots не найдены
- Следующее действие
- Всё равно сверить singleton/version, owners и threshold
- Наблюдение
- Есть неизвестный enabled module
- Вывод
- Возможен самостоятельный execution path
- Следующее действие
- Остановить пополнение; получить code, config, audit и removal plan
- Наблюдение
- Есть transaction guard
- Вывод
- Обычные операции зависят от его pre/post checks
- Следующее действие
- Проверить код и тест удаления/аварийного исполнения
- Наблюдение
- Есть fallback handler
- Вывод
- Proxy обслуживает дополнительные selectors/callbacks
- Следующее действие
- Проверить handler implementation и ожидаемые interfaces
- Наблюдение
- Safe 1.5.0 использует module guard
- Вывод
- Module executions имеют отдельный контрольный слой
- Следующее действие
- Проверить оба guard-address и их recovery независимо
Снимок состояния должен быть воспроизводимым
Проверка до перевода
- 1Закрепите сеть и proxy
Сохраните chain ID, Safe address, block number и текущий singleton/implementation. Один адрес в другой сети — другой state.
- 2Прочитайте базовый контроль
Получите owners, threshold и nonce напрямую из контракта или независимого RPC.
- 3Перечислите modules
Пройдите getModulesPaginated до sentinel и сохраните порядок; один первый page не доказывает полный список.
- 4Получите guards и fallback
Зафиксируйте transaction guard, module guard при поддерживаемой версии и fallback handler.
- 5Свяжите адрес с кодом
Для каждого extension проверьте bytecode/proxy, implementation, config, audit scope и управляющие ключи на этом блоке.
- 6Проверьте recovery
На тестовой копии или малом Safe воспроизведите disable/remove path до хранения существенных средств.
Удаление расширения тоже проходит через существующую архитектуру
Stop-сигналы
- интерфейс показывает только owners и скрывает modules, guards или fallback;
- extension address не имеет проверенного кода либо указывает на изменяемый proxy без понятного admin;
- guard не имеет испытанного removal path и может заблокировать транзакцию собственного удаления;
- module обещает лимит, который не находится в code/config конкретного deployment;
- новый handler добавляют вместе с несвязанным переводом или delegatecall;
- подписантам не показывают, что именно подписывает кошелёк в self-call Safe.
Проверка закрыта, когда другой reviewer получает тот же block-pinned список owners, modules, guards и fallback handler, связывает каждый адрес с кодом и воспроизводит ожидаемый removal path. Если опасное расширение уже включено, остановите новые поступления и не импровизируйте: guard может блокировать обычный путь, module — сохранять альтернативный. Сначала смоделируйте exact self-call, threshold, predecessor и порядок исполнения; затем покажите участникам, что именно подписывает кошелёк, соберите подписи и независимо проверьте итоговый state.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Safe Docs — Smart Account Modules Safe · Проверено 22 августа 2026 г. в 10:35 GMT+5
- Safe Docs — Smart Account Guards Safe · Проверено 22 августа 2026 г. в 10:35 GMT+5
- Safe Docs — Fallback Handler Safe · Проверено 22 августа 2026 г. в 10:35 GMT+5
- Safe 1.5.0 — ModuleManager.sol Safe · Проверено 22 августа 2026 г. в 10:35 GMT+5
- Safe Smart Account — Safe.sol Safe · Проверено 22 августа 2026 г. в 10:35 GMT+5