Safe – инфраструктура программируемых смарт-аккаунтов, известная мультиподписью для команд, DAO и владельцев крупных криптовалютных портфелей. Вместо одного приватного ключа пользователь разворачивает контракт и задаёт несколько owners, порог подтверждений и дополнительные правила. Safe Wallet предоставляет интерфейс, но активы принадлежат контракту в выбранной сети.
Проект расширился за пределы классического multisig. Модули добавляют автоматизацию, guards проверяют операции, ERC-4337 позволяет использовать account abstraction, а Safenet строит отдельную сеть исполнения и безопасности вокруг SAFE. Эти части нельзя смешивать: базовый Safe Smart Account работает без Safenet и без владения токеном.
История
Первый код мультиподписного кошелька, из которого вырос Safe, Stefan George написал в 2017 году внутри экосистемы Gnosis. Продукт назывался Gnosis Multisig, затем Gnosis Safe. Он стал отдельной инфраструктурой для коллективного управления средствами и протокольными treasury.
В 2022 году Safe отделился от Gnosis и запустил SafeDAO. SAFE первоначально использовался для governance и оставался непередаваемым. В апреле 2024 года сообщество включило transferability, после чего токен стал свободно перемещаться согласно обычным правилам ERC-20.
Версия Safe Smart Account 1.4.1 закрепила архитектуру модулей, guards и совместимость с ERC-4337 через отдельный модуль. 15 октября 2025 года Safe Labs приняла операционную ответственность за размещаемое приложение Safe Wallet, тогда как Safe Ecosystem Foundation продолжила поддерживать протокол, контракты, SAFE и управление. В 2026 году заработала бета-версия staking для Safenet. Она ещё не использует конфискацию stake за нарушение – текущие наказания ограничены потерей наград.
Команда
К сооснователям Safe относятся Stefan George, Lukas Schor и Richard Meissner. Они участвовали в выделении продукта из Gnosis и развитии контрактной архитектуры. В совете Safe Ecosystem Foundation Lukas Schor занимает пост президента, Stefan George – вице-президента, Richard Meissner – члена совета.
Safe Labs возглавляет Rahul Rumalla. Компания развивает пользовательские и коммерческие продукты, включая размещаемый интерфейс. Foundation отвечает за экосистему и stewardship, SafeDAO – за governance-процессы и treasury в пределах принятых правил, а независимые команды встраивают Safe в свои кошельки и протоколы.
Наличие нескольких организаций не устраняет концентрацию. Контрактные релизы, официальный интерфейс, индексирующий сервис и Safenet имеют конкретных операторов. При анализе следует смотреть, какая организация управляет именно той частью, которой пользуется аккаунт.
Safe Smart Account
Safe – контрактный аккаунт с набором owners и threshold. Владельцем может быть обычный EOA, аппаратный кошелёк или другой контракт. Порог задаёт минимальное число действительных подписей для исполнения. Конфигурация 2 из 3 переживает потерю одного ключа, но два скомпрометированных владельца контролируют аккаунт.
Операция описывает адрес назначения, сумму, calldata, тип вызова, параметры gas и nonce Safe. Owners подписывают структурированный EIP-712-хеш. Подписи можно собрать вне цепи, а затем любой исполнитель отправляет одну транзакцию в контракт. Он проверяет порядок, владельцев, порог и nonce, после чего выполняет действие.
Nonce защищает от простого повторного исполнения той же операции. Однако две конкурирующие транзакции с одним nonce не могут обе пройти. Команда должна согласовать очередь, особенно если несколько участников параллельно предлагают платежи.
Proxy и singleton
Каждый аккаунт обычно является лёгким proxy. Он хранит собственные owners, threshold, nonce и подключённые расширения, но исполняет базовую логику через delegatecall к общему singleton-контракту. Это уменьшает стоимость развёртывания и позволяет многим аккаунтам использовать проверенный код.
Proxy фиксирует адрес singleton при создании. Обновление экосистемы не переписывает автоматически уже развёрнутый Safe. Пользователь может мигрировать или изменить master copy только через надлежащую операцию, если версия это позволяет. Поэтому в разных сетях одновременно существуют аккаунты разных версий.
Совпадающий адрес Safe в нескольких сетях не означает общее состояние. Owners, nonce, модули и активы хранятся отдельно. Контракт может быть развёрнут детерминированно, но пользователю нужно проверить цепь и версию реализации.
Подписи и исполнение
Safe поддерживает подписи EOA, заранее одобренные хеши и контрактные подписи по EIP-1271. Это позволяет одному owner быть другим multisig или политикой. Сложная иерархия повышает гибкость, но может скрыть реальное число людей, способных провести операцию.
Последний отправитель платит network gas, если операция не предусматривает возмещение из Safe. Сервисные интерфейсы способны предложить sponsored execution, но базовый контракт не обещает бесплатные транзакции. Фактическая цена зависит от сети, calldata и подключённых механизмов.
Safe может выполнить обычный call или delegatecall. Второй режим запускает внешний код в контексте аккаунта и особенно опасен: злонамеренная библиотека способна изменить storage или добавить backdoor. Owners должны понимать не только адрес получателя, но и тип операции.
Safe Transaction Service
Transaction Service индексирует события Safe, декодирует известные контракты и хранит предложенные операции и offchain-подписи. Благодаря ему несколько owners видят одну очередь и могут подписать её с разных устройств. После достижения порога сервис не забирает средства – исполнение всё равно проверяет контракт.
Если сервис недоступен или цензурирует предложение, аккаунт не обязан останавливаться. Подписи и транзакцию можно сформировать другими инструментами и отправить напрямую. Но обычный пользователь может не иметь такого интерфейса, поэтому операционная зависимость всё равно значима.
Декодированное описание – удобная подсказка, а не часть консенсуса. Неизвестный контракт или прокси может отображаться неполно. Подписант должен сверять адрес, сеть, сумму и calldata, как объясняется в статье о том, что означает подпись сообщения.
Модули
Module – контракт, которому Safe заранее разрешил вызывать execTransactionFromModule. После включения он способен инициировать операции без сбора обычного порога для каждой из них, если его собственная логика разрешает действие. Так реализуют лимиты расходов, роли сотрудников, автоматизацию и мосты.
Добавление и удаление модуля требует стандартного порогового решения owners. Но после добавления безопасность аккаунта не сильнее кода модуля. Уязвимый либо слишком широкий модуль может вывести активы даже при сохранности всех ключей.
Нужно проверять proxy и права самого модуля, возможность обновления, администратора, allowed targets и лимиты. Удаление из интерфейса должно завершиться onchain-операцией. Простое отключение интеграции на сайте не отзывает контрактное разрешение.
Guards и Module Guards
Guard выполняет проверку до и после обычной транзакции Safe. Он способен запретить перевод на неизвестный адрес, потребовать дополнительные условия или вести журнал политики. В версии 1.4.1 отдельный Module Guard проверяет операции модулей.
Guard получает большую власть. Ошибка или намеренный revert может заблокировать все обычные транзакции, включая попытку снять сам guard. Перед подключением нужна проверенная процедура восстановления, а код должен учитывать исключения для аварийных действий.
Guard не превращает плохую подпись в хорошую. Он применяет формальные условия, заданные программой. Если разрешённый адрес взломан или политика ошибочна, проверка пропустит опасную операцию.
Fallback handlers
Fallback handler обрабатывает вызовы, для которых у Safe нет собственной функции. Через него добавляют совместимость с token callbacks, EIP-1271 и другими интерфейсами. Safe4337 использует специальный handler вместе с модулем.
Поскольку handler получает произвольные внешние вызовы, неверная реализация может расширить поверхность атаки или создать конфликт селекторов. Его адрес является частью конфигурации безопасности и должен проверяться наравне с owners и модулями.
ERC-4337 и account abstraction
Safe поддерживает ERC-4337 через Safe4337Module и совместимый fallback handler в версии 1.4.1 и новее. Пользователь формирует UserOperation, bundler передаёт её EntryPoint, а модуль проверяет подписи и исполняет действие. Paymaster при желании оплачивает gas по своим правилам.
Это не автоматическая функция любого старого Safe. Модуль нужно корректно включить, версия контракта и EntryPoint должны совпадать. Ошибка bundler задерживает отправку, paymaster может отказать, а уязвимость модуля добавляется к рискам базового аккаунта.
Экспериментальные подходы на основе EIP-7702 и Safe Lite нельзя считать тем же уровнем зрелости. В актуальной документации такие варианты прямо отделены и могут оставаться неаудированными. До production-использования нужно проверять статус конкретной реализации.
Safe Wallet и Workspace
Safe Wallet помогает создать аккаунт, собрать подписи, отображать токены и подключать приложения. Workspace группирует несколько аккаунтов и участников для организации. Эти интерфейсы не изменяют порог onchain, пока пользователь не подпишет соответствующую транзакцию.
Компрометация сайта способна подставить адрес или calldata и убедить owners подписать корректно сформированную, но вредоносную операцию. Несколько подписантов не помогают, если все доверяют одному экрану. Для крупных переводов полезны независимое декодирование и out-of-band-подтверждение реквизитов.
Safenet
Safenet – развивающийся слой исполнения, который должен давать быстрые межсетевые операции, гарантии и последующее урегулирование. Валидаторы наблюдают и подтверждают корректность действий, а SAFE служит stake. Это отдельная сеть вокруг Smart Accounts, а не обновление, автоматически включённое во всех старых аккаунтах.
В 2026 году staking Safenet работает в Beta. Валидатор регистрируется в Gnosis Chain и связывает адрес Ethereum staking. Для права на вознаграждения требуется средний self-stake не менее 3,5 млн SAFE за reward period. Делегаторы могут поддерживать валидатора и получать свою часть.
В Beta нет slashing, который конфискует staked SAFE. Наказание экономическое: при недостаточном участии валидатор теряет награды. Если participation ниже 75%, награда за период не начисляется; нарушение требования self-stake лишает валидатора собственной доли, но само по себе не штрафует делегаторов. Будущую конфискацию нельзя выдавать за действующий механизм.
Токен SAFE
SAFE – ERC-20 в Ethereum с фиксированным максимальным предложением 1 млрд токенов. Он используется для SafeDAO governance и staking в Safenet. Для обычного создания и использования Safe Smart Account SAFE не требуется.
После стратегического раунда распределение описывается так: 5% предназначены пользователям, 5% – guardians, 8% – стратегическим backers, 15% – core contributors, 7% – Foundation, 55% – treasury SafeDAO и GnosisDAO, ещё 5% – совместной treasury. Внутри 55% доли составляют 40% и 15% соответственно.
Разблокировки растянуты до восьми лет и различаются по категориям. У пользовательской части половина была доступна сразу, половина распределяется четыре года. Это исходная структура, а не точное обращающееся предложение на текущий день. Переводы treasury и разблокировки нужно проверять по блокчейну и решениям DAO.
SafeDAO и управление
SafeDAO работает на основе Конституции и процедур предложений. Обсуждение проходит на форуме, сигнал может фиксироваться через Snapshot, а принятые решения исполняются предусмотренными аккаунтами и организациями. OBRA задаёт рамку финансирования результатов, а не право любого держателя изменить singleton.
SAFE даёт governance-вес, но не контроль над чужим аккаунтом. Owners конкретного Safe остаются единственными, кто может изменить его threshold и расширения. DAO также не управляет корпоративными решениями Safe Labs как обычной дочерней компанией.
Большая treasury и значительные аллокации организациям создают концентрацию голосов. Делегирование улучшает участие, но делегат способен голосовать иначе, чем ожидает держатель. Для оценки токена полезно применять принципы из материала о том, как читать токеномику.
Применение
Safe подходит для DAO treasury, корпоративных платежей, протокольных admin-ключей, коллективного владения NFT и личного резервного кошелька. Порог позволяет разделить риск между аппаратными устройствами, людьми и юридическими ролями.
Контрактный аккаунт полезен и одному человеку. Он может разместить owners на разных устройствах, включить восстановление через доверенных лиц и ограничить повседневные расходы модулем. Но избыточная сложность способна сделать восстановление труднее обычной seed-фразы.
Для управления протоколом Safe часто хранит upgrade-ключи и treasury. В этом случае безопасность внешнего проекта зависит от конфигурации Safe. Поэтому при анализе DeFi важно смотреть не только на multisig 3 из 5, но и на личности owners, задержку timelock и подключённые модули.
Основные риски
Неверный threshold
Слишком низкий порог допускает сговор или компрометацию нескольких ключей. Слишком высокий делает аккаунт неработоспособным после потери одного owner. Схема должна учитывать реальные резервные копии и доступность людей.
Общий источник компрометации
Пять owners не дают независимость, если все ключи хранятся в одном браузере или подписывают с одного заражённого интерфейса. Устройства, география и каналы проверки должны различаться. Основы такой схемы разобраны в обзоре мультиподписного кошелька.
Модули, guards и handlers
Расширение способно обойти обычный порог, остановить исполнение или открыть новую функцию. Даже аудированный модуль может быть опасен с неверными параметрами. Список подключений следует регулярно сверять непосредственно в контракте.
Blind signing и delegatecall
Пакетная транзакция может скрывать несколько действий, approvals и делегированный вызов. Читаемое название приложения не доказывает содержимое calldata. Для критичных операций подписанты должны использовать независимый декодер.
Transaction Service и интерфейс
Недоступность сервиса не блокирует контракт, но может остановить команду, не умеющую собрать операцию вручную. Фишинговый интерфейс способен предложить вредоносный перевод. Нужен резервный путь и проверка официального домена.
Разные сети и версии
Одинаковый адрес может иметь разную конфигурацию, а старая версия – не поддерживать новый модуль. Перевод в неправильную сеть не появляется автоматически в нужном Safe. Перед операцией проверяют chain ID, singleton и owners.
Safenet Beta
Минимальный self-stake повышает барьер и может концентрировать валидаторов. Отсутствие slashing снижает прямой ущерб оператору за нарушение, а система ещё меняется. Staking SAFE не следует считать безрисковым депозитом или фиксированной доходностью.
Governance и рынок SAFE
Крупные treasury, команда и backers обладают существенным объёмом токенов. Разблокировки влияют на рынок, а право голоса не создаёт денежного потока. Успех Safe Smart Account не обязательно приводит к спросу на SAFE, поскольку базовый продукт работает без токена.
Как безопаснее настроить Safe
Сначала определяют угрозы и выбирают owners на действительно независимых устройствах. Затем задают порог, при котором одна потеря не блокирует средства, а одна компрометация не даёт контроль. Адреса owners сверяют вне браузера до первой крупной суммы.
Модули, guard и handler добавляют только после аудита кода, admin-ролей и процедуры удаления. Полезно провести тестовое восстановление, небольшой перевод и прямую проверку конфигурации через независимый RPC. Для временных разрешений можно рассмотреть сессионные ключи, но их лимиты также задаются кодом.
Команда документирует, кто может предлагать, подтверждать и исполнять транзакцию, как проверяется адрес получателя и что делать при недоступности интерфейса. Такая операционная дисциплина часто важнее добавления ещё одного owner.
Итог
Safe превратил мультиподпись в программируемую платформу аккаунтов. Proxy и singleton дают проверяемую основу, owners и threshold распределяют контроль, а модули и ERC-4337 расширяют сценарии. Главный компромисс – каждое удобное расширение добавляет новый путь обхода базового порога.
SAFE связан с SafeDAO и безопасностью Safenet, но не нужен для хранения активов в Smart Account. Safenet пока находится в Beta и использует потерю наград вместо конфискации stake. При оценке Safe нужно разделять зрелые контракты, hosted-интерфейс, экспериментальные account abstraction-компоненты и новую сеть. Надёжность конкретного аккаунта определяется его конфигурацией, а не популярностью бренда.
