«Прошёл аудит» — это утверждение о конкретном коде конкретной версии, поэтому на этой странице указаны отчёты, коммиты и адреса развёртываний — и перечислено то, что аудит не проходило, а это не менее важно.
Последняя сверка: 22 сентября 2026 года. Если найдёте ошибку, сообщите нам — мы её исправим.
Путь средств
Каждый контракт, который может коснуться ваших денег, — это каноническое развёртывание стороннего кода с опубликованными проверками.
Safe v1.4.1 — сам аккаунт
Ваш кошелёк — прокси Safe, использующий синглтон SafeL2 и SafeProxyFactory. Пакетные транзакции проходят через MultiSend.
Ackee Blockchain провела аудит Safe v1.4.0 (финальный отчёт — 16 марта 2023 года, проверка исправлений — 28 марта): 11 замечаний, ни одного критического или высокого; два замечания средней важности признаны, но код не менялся. В охват входили SafeL2, SafeProxyFactory, CompatibilityFallbackHandler, MultiSendCallOnly и SignMessageLib. v1.4.1 отличается от v1.4.0 одной функциональной строкой — исправлением совместимости с ERC-4337 при настройке модулей (PR #572); Safe проконсультировалась с Ackee и пришла к выводу, что повторный аудит не нужен. Логика MultiSend не менялась с v1.3.0, аудит которой провела G0 Group. Все адреса совпадают с safe-deployments. Основные контракты входят в программу вознаграждений за уязвимости Safe Foundation, высший уровень которой — до $1 000 000.
Инцидент с Bybit в 2025 году — не замечание к контрактам: злоумышленники подменили JavaScript, который отдавался веб-интерфейсу Safe, а заключение расследования Safe не нашло уязвимостей в контрактах. Наша страница об этом объясняет, почему тот же класс атак касается любого интерфейса кошелька, включая наш.
Safe4337Module v0.3.0 — адаптер ERC-4337
Развёрнут по адресу 0x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226 (точное совпадение
в Sourcify) и также назначен fallback handler вашего Safe. Проверялся трижды — отчёты здесь:
- Ackee Blockchain, финальный отчёт в марте 2024 года: одно предупреждение (использование оптимизатора компилятора) признано, ничего серьёзнее не открыто.
- Certora, август 2026 года: одно замечание средней важности, признанное и не исправленное в v0.3.0, — изменения авторизации не делают недействительными более поздние UserOperation, уже прошедшие проверку в том же пакете. См. «Известные проблемы» ниже.
- Nethermind, август 2026 года: замечаний нет.
SafeModuleSetup v0.3.0 (0x2dd6…5b47), который включает модуль при развёртывании
кошелька, вошёл в охват проверок Certora и Nethermind.
В истории модуля есть одна раскрытая проблема: v0.1.0 не подписывал initCode и paymasterAndData, что открывало путь к атаке на расход газа
(исправлено в v0.2.0);
по данным Safe, v0.1.0 не использовался за пределами тестовых сетей. Vela использует
v0.3.0 с EntryPoint v0.7 и Safe 1.4.1 — ту конфигурацию, которую описывает релиз
модуля.
Модуль passkey от Safe v0.2.1 — подписанты
Ваш первый ключ проверяет SafeWebAuthnSharedSigner по адресу 0x94a4F6affBd8975951142c3999aEAB7ecee555c2. «Shared» (общий) означает, что общим
является развёртывание контракта — так же, как синглтон Safe; ваш ключ общим не
является. Каждый Safe хранит собственный публичный ключ P-256 в собственном
хранилище.
У каждого дополнительного ключа свой контракт-подписант, который SafeWebAuthnSignerFactory по адресу 0x1d31F259eE307358a26dFb23EB365939E8641195 создаёт как прокси к синглтону SafeWebAuthnSigner по адресу 0x4E27b51350e6c2083EE19011120F50DAfEc5CA50.
Проверки, которые покрывают эти контракты в версии v0.2.1 (отчёты):
- Конкурсный аудит Hats Finance (июнь–июль 2024 года): ни высоких, ни средних замечаний; три низких, все исправлены.
- Проверка Certora коммита релиза: новых замечаний нет. (В более раннем аудите v0.2.0 отмечено, что общий подписант тогда ещё не проверялся — его добавили после того аудита.)
- Nethermind, август 2026 года: замечаний нет.
С момента релиза уязвимостей на уровне контрактов не раскрывалось, а контракты passkey входят в программу вознаграждений Safe Foundation.
Подписи passkey проверяет прекомпайл EIP-7951 / RIP-7212 в самой сети, запасного верификатора нет. Прежде чем включить сеть, приложение проверяет прекомпайл настоящей подписью. Две оговорки: в исходной спецификации RIP-7212 есть недочёты в граничных случаях, которые исправляет EIP-7951 (они затрагивают только входные данные, которые и так должны отклоняться, а не корректные подписи WebAuthn), и одна пробная проверка не может выявить все способы, которыми реализация в конкретной сети может отклоняться от стандарта.
EntryPoint v0.7 — исполняет вашу операцию
Развёрнут по адресу 0x0000000071727De22E5E9d8BAf0edAc6f37da032 — канонический релиз v0.7.0. Аудит провела OpenZeppelin по заказу Ethereum Foundation (январь 2024 года): ни критических, ни высоких
замечаний, пять средних, все 24 замечания устранены; коммит проверки исправлений
совпадает с релизом. Контракт входит в программу вознаграждений ERC-4337 Ethereum Foundation (до $250 000).
Известные проблемы, за которыми мы следим
Изменения авторизации в пределах одного пакета (Safe4337Module, Certora M-01)
EntryPoint проверяет все операции пакета, прежде чем выполнить любую из них. Поэтому если одна операция удаляет владельца, операция, подписанная этим владельцем и стоящая позже в том же пакете, всё равно проходит проверку и выполняется. Safe признала это и не стала менять v0.3.0.
Приложения Vela никогда не собирают смену владельцев, а dApp, который об этом просит, получает прямой отказ, поэтому сама Vela эту проблему не вызывает. Она всё равно важна для тех, кто удаляет скомпрометированный ключ другими инструментами Safe: рассчитывать, что этот ключ будет отключён в пределах того же пакета, нельзя.
Перехват подписанной операции (EntryPoint до v0.9)
В феврале 2026 года исследователи раскрыли способ вредительства и цензуры, затрагивающий все версии EntryPoint до v0.9, включая v0.7. Тот, кто получит подписанную операцию до того, как она попадёт в блок, может выполнить её внутри контролируемого им вызова и заставить внутреннее исполнение откатиться: операция завершается неудачей, и её приходится подписывать заново. (Комиссия Vela платится внутри самой операции, поэтому её перевод откатывается вместе с операцией, и газ теряет релей, а не вы.) Проблема касается операций, которые вызывают контракты с защитой от повторного входа или которые можно заставить откатиться временным состоянием; простые переводы она не затрагивает. Если раз за разом применять этот приём к выводу средств, можно на какое-то время лишить к ним доступа. Подделать подпись или перенаправить средства этим способом нельзя.
Релей Vela отправляет операции напрямую, а не через общий мемпул, но ожидающая
транзакция handleOps всё равно видна в публичном мемпуле, так что это сужает риск,
а не устраняет его. Исправление есть только в EntryPoint v0.9 (ноябрь 2025 года);
v0.7 исправить нельзя. Переход зависит от поддержки v0.9 в модуле 4337 от Safe, и
эта страница сообщит, когда это произойдёт.
Пробелы в собственной защите Vela
Это не замечания к контрактам, а места, где кошелёк защищает вас слабее, чем можно подумать. Каждый пункт заведён как задача на исправление, кроме тех, где сказано, что это осознанный компромисс:
- Неограниченное разрешение уходит, если вы его оставите — осознанный компромисс, потому что ограниченное разрешение ломает Permit2 и пакетные обмены. «Неограниченное» разрешение (2^200 и больше; 2^152 для Permit2) показывается красным и отправляется в том виде, в каком его запрашивает dApp, если вы его не ограничите. Подписанные permit нельзя ограничить нигде.
- Trusted Signer включается только по вашему выбору, и его проверка целостности пока ничего не отклоняет. Независимая страница подписи используется только на устройстве, где вы выбрали её при создании кошелька или входе, а веб-кошелёк использовать её не может. Настольное приложение сравнивает страницу с версиями, которые поставляются вместе с ним, но несовпадение только записывает в журнал; мобильные приложения пока ничего не проверяют.
- Сайт загружает сторонний скрипт аналитики на том же домене, что и passkey. Сайт запрещает своим страницам использовать passkey (заголовок Permissions-Policy) и не загружает этот скрипт на странице, которая работает с ключом.
Что аудит не проходило
- Собственные контракты Vela. Реестр публичных ключей по адресу
0x94fD1A891EB6c5F340622Baf2F3A0cb70A941EA9(Gnosis; тот же адрес в Ethereum и Base), исходное развёртывание реестра по адресу0x5266DfF591B9F9EecfEdb8E7EfEf6c687854edaf(его адрес входит в домен подписи каждой регистрации) и более ранний индекс, который они заменили (0xdd93420BD49baaBdFF4A363DdD300622Ae87E9c3, история только для чтения). Аудит они не проходили. Они не хранят средств, не имеют владельца и не могут быть обновлены; это слой поиска, а не слой авторизации. Право тратить дают только ключи, заданные в вашем Safe. Худший реалистичный сбой — кошелёк станет труднее найти на новом устройстве, а не деньги куда-то уйдут. - Multicall3. В его README прямо сказано: «This contract is unaudited». Vela использует его только для пакетного чтения — балансов, данных токенов, котировок — и никогда для разрешений или средств.
- Детерминированные деплоеры (CREATE2-прокси Arachnid и singleton factory от Safe) — стандарт экосистемы, без состояния и без формального аудита. Если их нет, проверка сети в Vela не проходит; она проверяет, что по адресу есть код, а не побайтовое совпадение.
- Tempo. Одна из 24 встроенных сетей, без нативной монеты; газ там Vela платит стейблкоином pathUSD. По состоянию на сентябрь 2026 года политика безопасности Tempo сообщает, что протокол ещё проходит аудит и активной программы вознаграждений за уязвимости нет. Средства в Tempo и газ, уплаченный там, несут этот риск на уровне сети; считайте её самой новой и наименее проверенной сетью в списке.
- Сама Vela. Приложения, бэкенд-сервисы и перечисленные выше контракты стороннего аудита не проходили, и он не запланирован. Это самая большая оговорка на этой странице. Подробности — в посте Vela is in alpha. Начинайте с небольших сумм и читайте код.
Проверьте сами
Каждый адрес ниже — каноническое публичное развёртывание. Сверьте их с safe-deployments, safe-modules-deployments и релизом EntryPoint:
| Контракт | Адрес |
|---|---|
| Синглтон SafeL2 v1.4.1 | 0x29fcB43b46531BcA003ddC8FCB67FFE91900C762 |
| SafeProxyFactory v1.4.1 | 0x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67 |
| MultiSend v1.4.1 | 0x38869bf66a61cF6bDB996A6aE40D5853Fd43B526 |
| CompatibilityFallbackHandler v1.4.1 ¹ | 0xfd0732Dc9E303f09fCEf3a7388Ad10A83459Ec99 |
| SafeModuleSetup v0.3.0 | 0x2dd68b007B46fBe91B9A7c3EDa5A7a1063cB5b47 |
| Safe4337Module v0.3.0 | 0x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226 |
| SafeWebAuthnSharedSigner v0.2.1 | 0x94a4F6affBd8975951142c3999aEAB7ecee555c2 |
| SafeWebAuthnSignerFactory v0.2.1 | 0x1d31F259eE307358a26dFb23EB365939E8641195 |
| Синглтон SafeWebAuthnSigner v0.2.1 | 0x4E27b51350e6c2083EE19011120F50DAfEc5CA50 |
| EntryPoint v0.7 | 0x0000000071727De22E5E9d8BAf0edAc6f37da032 |
| Multicall3 | 0xcA11bde05977b3631167028862bE2a173976CA11 |
| Реестр публичных ключей (Vela, без аудита) | 0x94fD1A891EB6c5F340622Baf2F3A0cb70A941EA9 |
¹ Проверяется при добавлении сети; в качестве fallback handler ваш Safe использует модуль 4337.