«Проаудировано» — это утверждение про конкретную версию конкретного кода, поэтому здесь мы не машем этим словом: страница называет точные отчёты, точные адреса развёртывания и различия между проаудированной и развёрнутой версиями. Она также перечисляет то, что не проаудировано, — этот список несёт не меньшую нагрузку, чем первый.

Последняя сверка: август 2026. Нашли здесь ошибку — скажите нам, поправим.

Путь, по которому идут деньги

Ваших денег могут касаться четыре слоя контрактов. Все четыре — сторонние контракты с опубликованными аудитами, и в каждом случае развёрнутый адрес совпадает с официальным каноническим развёртыванием.

Safe v1.4.1 — сам аккаунт

Ваш кошелёк — это прокси Safe: синглтон SafeL2, фабрика прокси, обработчик совместимости и MultiSend для пакетных вызовов.

Ackee Blockchain аудировала Safe v1.4.0 (итоговый отчёт — март 2023): 11 находок, ни одной критической или высокой. Версия v1.4.1, которую мы разворачиваем, отличается от проаудированной v1.4.0 однострочной правкой совместимости с ERC-4337 (PR #572). Логика MultiSend не менялась с версии v1.3.0, проаудированной G0 Group. Все адреса совпадают с каноническими развёртываниями в safe-deployments, а сами контракты входят в программу вознаграждений Safe Foundation (до $1 000 000 за критическую находку).

Чего аудит не покрывает: инцидент с Bybit в 2025 году. Та атака скомпрометировала сборочный конвейер официального веб-фронтенда Safe, а не контракты, — официальное заключение расследования не нашло уязвимости в смарт-контрактах Safe. Мы читаем это как урок про веб и эксплуатацию — тот самый слой, по которому стоит придирчиво проверять и нас.

Safe4337Module v0.3.0 — адаптер ERC-4337

Развёрнут по адресу 0x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226 — каноническому адресу v0.3.0 (точное совпадение в Sourcify: байт-код в блокчейне и есть проаудированный код). Аудит Ackee Blockchain (итоговый отчёт — март 2024), нерешённых находок выше информационного уровня нет. Связка v0.3.0 + EntryPoint v0.7 + Safe ≥1.4.1, которую мы используем, — ровно та конфигурация, что описана в аудите и в примечаниях к релизу.

В истории модуля есть одна раскрытая проблема: v0.1.0 (2023) не подписывала initCode и paymasterAndData — вектор griefing по газу. Её исправили в v0.2.0, а v0.1.0 так и не вышла за пределы тестовых сетей. Мы используем v0.3.0, которая унаследовала исправление.

SafeWebAuthnSharedSigner v0.2.1 — подписывающий контракт для passkey

Развёрнут по адресу 0x94a4F6affBd8975951142c3999aEAB7ecee555c2 — каноническому адресу v0.2.1 (одинаковому во всех сетях благодаря фабрике синглтонов Safe).

Что значит «shared» (общий) — и чего оно не значит: общим является развёртывание контракта, ровно так же, как общим является синглтон Safe. Ваш ключ — нет. Каждый Safe вызывает configure() через delegatecall и хранит свой собственный публичный ключ P-256 в собственном хранилище. Один экземпляр signer представляет ровно один passkey на один Safe, и ничей чужой Safe не может воспользоваться вашим.

Здесь важна версия. Аудит v0.2.0 прямо указывал, что общий signer в область проверки не входит — контракта тогда ещё не существовало. То, что мы разворачиваем, покрывают аудиты v0.2.1: аудит-соревнование Hats Finance (июнь–июль 2024: ноль высоких, ноль средних, три низких находки — все исправлены) плюс проверка релизного коммита от Certora без новых находок. С момента релиза уязвимостей на уровне контрактов не раскрывалось; контракты passkey входят в программу вознаграждений Safe Foundation.

Собственная документация Safe рекомендует сочетать владение через passkey с путём восстановления, а не считать одну учётную запись единственным ключом к аккаунту. Как это устроено у Vela — в разделе Восстановление и вход.

Проверка P-256 в блокчейне идёт напрямую через прекомпайл RIP-7212, без запасного верификатора на Solidity. Прежде чем включить сеть, приложение проверяет прекомпайл настоящей подписью и отказывается от сети, если проверка не прошла. Две честные оговорки: в исходной спецификации RIP-7212 есть краевые дефекты, ради исправления которых написан EIP-7951 (на корректно сформированные подписи WebAuthn они не влияют), и такая проба не поймает все способы, которыми реализация в конкретной сети может разойтись со спецификацией в необычных условиях исполнения.

EntryPoint v0.7 — точка входа ERC-4337

Развёрнут по адресу 0x0000000071727De22E5E9d8BAf0edAc6f37da032каноническое развёртывание v0.7.0. Аудит OpenZeppelin (по заказу Ethereum Foundation, январь 2024): ноль критических, ноль высоких, пять средних находок — все закрыты, и проаудированный коммит и есть развёрнутый релиз. EntryPoint v0.7.0 входит в программу вознаграждений ERC-4337 от Ethereum Foundation (до $250 000).

Известные проблемы, за которыми мы следим

Вектор griefing в EntryPoint

В феврале 2026 года исследователи безопасности из Trust Security раскрыли вектор griefing и цензуры, затрагивающий все версии EntryPoint до v0.9, включая используемую нами v0.7. Атакующий, перехвативший подписанную UserOperation до её попадания в блок, может выполнить её внутри подконтрольного ему фрейма вызова и заставить внутреннее исполнение откатиться: операция не проходит, но газ всё равно списывается. Ethereum Foundation выплатил исследователям вознаграждение в $50 000 и классифицировал проблему как вектор цензуры/griefing, а не кражи средств; на практике её никогда не эксплуатировали.

Что он может: сжечь комиссию и задержать транзакцию. Чего не может: украсть средства или подделать подпись. Уязвимость Vela к нему узкая, потому что UserOperation уходит прямо в релей, а не в публичный mempool, — перехватывать особо негде, и худший случай ограничен комиссией, на которую вы и так согласились. Исправление существует только в EntryPoint v0.9 (ноябрь 2025); саму v0.7 залатать нельзя. Мы рассчитываем перейти на неё по мере того, как окружающий стек — прежде всего линейка 4337-модулей Safe — добавит поддержку v0.9, и отметим это здесь, когда так случится.

Что не проаудировано

  • Собственные контракты Vela. Два маленьких контракта нашего авторства, развёрнутых в Gnosis: индекс публичных ключей passkey (реестр «только на добавление», который помогает вашим устройствам найти ваш публичный ключ) и вспомогательный пакетный контракт к нему. Они не проаудированы. По конструкции они не держат средств, не имеют владельца и не обновляемы — это слой обнаружения, а не слой авторизации. Право тратить всегда идёт от passkey, настроенного внутри вашего Safe. Худший реалистичный сбой — griefing (кто-то занял запись в индексе): восстановление станет менее удобным, но деньги это не сдвинет. Контракт-разделитель для расчётов по газу из ранней схемы комиссий больше не участвует в потоке транзакций.
  • Multicall3. Его собственный README прямо говорит: «This contract is unaudited». Мы используем его ровно так, как его авторы называют безопасным, — пакетные вызовы только на чтение: балансы, метаданные токенов, котировки. Vela никогда не выдаёт ему разрешений, и он никогда не держит средств. Худшее последствие ошибки — неверно прочитанные данные.
  • Деплойер CREATE2. Детерминированный прокси развёртывания Arachnid — принятый в экосистеме stateless-деплойер без формального аудита. Наши проверки сети завершаются отказом, если его нет или он изменён.
  • Tempo и pathUSD. У Tempo, одной из наших двенадцати встроенных сетей, нет нативной монеты; газ там рассчитывается в стейблкоине pathUSD. По состоянию на август 2026 ни у ядра протокола Tempo, ни у pathUSD нет опубликованного аудита безопасности или программы вознаграждений, а независимая оценка обеспечения от DefiLlama (апрель 2026) отнесла pathUSD к высокому риску. Это риск уровня сети, который не смягчит никакой кошелёк: средства, которые вы держите в Tempo, и расчёты по газу там его наследуют. Считайте Tempo самой новой и наименее проверенной сетью в списке и соразмеряйте балансы. Мы обновим этот раздел, когда аудиты появятся.
  • Сама Vela. Наше приложение и бэкенд-сервисы не проходили стороннего аудита. Это самая крупная оговорка на странице, мы пишем о ней в шапке сайта, а честные подробности — в Vela в альфе. Начинайте с маленьких сумм. Читайте код.

Проверьте сами

Каждый адрес выше — публичное каноническое развёртывание, которое можно сверить с официальными реестрами: safe-deployments, safe-modules-deployments и примечания к релизу EntryPoint:

КонтрактАдрес
SafeL2 singleton v1.4.10x29fcB43b46531BcA003ddC8FCB67FFE91900C762
SafeProxyFactory v1.4.10x4e1DCf7AD4e460CfD30791CCC4F9c8a4f820ec67
CompatibilityFallbackHandler v1.4.10xfd0732Dc9E303f09fCEf3a7388Ad10A83459Ec99
MultiSend v1.4.10x38869bf66a61cF6bDB996A6aE40D5853Fd43B526
SafeModuleSetup v0.3.00x2dd68b007B46fBe91B9A7c3EDa5A7a1063cB5b47
Safe4337Module v0.3.00x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226
SafeWebAuthnSharedSigner v0.2.10x94a4F6affBd8975951142c3999aEAB7ecee555c2
EntryPoint v0.70x0000000071727De22E5E9d8BAf0edAc6f37da032
Multicall30xcA11bde05977b3631167028862bE2a173976CA11
Индекс публичных ключей passkey (Gnosis)0xdd93420BD49baaBdFF4A363DdD300622Ae87E9c3