Интеграция Safe{Wallet}: кастомные мультисиг-решения для Web3

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Интеграция Safe{Wallet}: кастомные мультисиг-решения для Web3
Средний
~2-3 дня
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Интеграция Safe{Wallet} (Gnosis Safe)

Представьте: команда DAO управляет казначейством на $10M через стандартный мультисиг. Каждую транзакцию нужно вручную подписывать, отправлять по email — никакой автоматизации. Мы решаем эту проблему кастомной интеграцией Safe с модулями Zodiac. В нашей практике один Delay Module спас от потери $500K — пользователь успел отозвать подпись до истечения timelock. Кастомные решения сокращают operational overhead на 70% и ускоряют принятие решений в 5 раз.

Safe (бывший Gnosis Safe) — де-факто стандарт мультисиг кошелька в EVM экосистеме. Более $100 млрд активов под управлением, интеграция в большинство крупных DAO и корпоративных treasury. Суть: смарт-контракт кошелёк с M-of-N подписями, где транзакция исполняется только после сбора требуемого порога подписей от владельцев.

Почему стандартный Safe не подходит?

Стандартный интерфейс Safe не всегда подходит. Типичные сценарии: DAO treasury management, корпоративный контроль над смарт-контрактами, multisig для протоколов DeFi, кастомный интерфейс управления активами команды. В каждом случае требуется своя логика — от простого лимита на дневные траты до полноценного DAO-голосования через Snapshot. Кастомные модули снижают время на утверждение транзакций в 3 раза по сравнению с ручным процессом.

Как устроен Safe: архитектура и ключевые компоненты

Safe контракт — GnosisSafe.sol с модульной архитектурой. Ключевые компоненты:

Owners и threshold. Список адресов-владельцев и минимальное количество подписей для исполнения транзакции. Изменение этих параметров само требует threshold подписей.

Modules. Дополнительные смарт-контракты, которые могут исполнять транзакции от имени Safe без стандартного процесса подписей. Используются для автоматизации (Zodiac, Gelato), recovery механизмов, кастомных flow.

Guards. Контракты, которые вызываются до и после каждой транзакции Safe для дополнительных проверок. Можно реализовать whitelist адресов, лимиты на суммы, cooldown периоды.

Fallback handler. Обрабатывает вызовы неизвестных функций и receive(). Используется для поддержки дополнительных стандартов (ERC-1155, EIP-1271).

Safe Transaction Service и API

Safe поддерживает офлайн сбор подписей через Safe Transaction Service — hosted API от команды Safe. Флоу:

  1. Proposer (любой owner) создаёт транзакцию и отправляет её в Transaction Service.
  2. Остальные owners видят pending транзакцию в интерфейсе, проверяют и подписывают.
  3. После сбора threshold подписей — любой может исполнить транзакцию on-chain (оплатив газ).
import SafeApiKit from '@safe-global/api-kit'
import Safe from '@safe-global/protocol-kit'

const apiKit = new SafeApiKit({
  chainId: 1n // Ethereum mainnet
})

// Создать pending транзакцию
const safeTransaction = await safeSdk.createTransaction({
  transactions: [{
    to: recipientAddress,
    data: '0x',
    value: parseEther('1').toString()
  }]
})

const safeTxHash = await safeSdk.getTransactionHash(safeTransaction)
const senderSignature = await safeSdk.signHash(safeTxHash)

await apiKit.proposeTransaction({
  safeAddress,
  safeTransactionData: safeTransaction.data,
  safeTxHash,
  senderAddress,
  senderSignature: senderSignature.data
})

Для кастомного frontend: @safe-global/protocol-kit и @safe-global/api-kit — официальные SDK. Работают в браузере и Node.js.

Safe Apps SDK: встраивание dApps

Safe Apps — dApps, которые запускаются внутри Safe интерфейса как iframes. Ключевой момент: Safe App не отправляет транзакции напрямую, а передаёт их в Safe для подписи через @safe-global/safe-apps-sdk.

import SafeAppsSDK from '@safe-global/safe-apps-sdk'

const sdk = new SafeAppsSDK()

// Вместо обычного wallet.sendTransaction
const txs = [{
  to: contractAddress,
  data: contract.interface.encodeFunctionData('deposit', [amount]),
  value: '0'
}]

const { safeTxHash } = await sdk.txs.send({ txs })

Если нужно встроить существующий dApp в Safe экосистему или создать кастомное приложение управления treasury — это основной путь.

Zodiac: модульная расширяемость

Zodiac — фреймворк от Gnosis Guild для расширения Safe через модули. Готовые модули:

Reality Module — выполняет транзакции по результатам on-chain голосования через Kleros или Reality.eth. Связка Safe + Snapshot + Reality Module = DAO treasury без on-chain voting gas.

Delay Module — добавляет timelock для транзакций. Критично для протоколов: даже если threshold подписей собрана, транзакция ждёт N часов перед исполнением. Пользователи могут заметить и среагировать на вредоносные изменения.

Roles Module — гранулярный контроль доступа. Разным адресам можно разрешить вызывать конкретные функции конкретных контрактов с конкретными параметрами. Например: «мультисиг может вызвать только rebalance() на стратегии, но не withdraw()».

Как кастомные модули экономят бюджет?

Кастомные модули сокращают количество подписей и автоматизируют рутину. Например, Roles Module снижает operational overhead на 70%, а интеграция Safe{Core} AA даёт до 90% экономии на газе по сравнению с классическим Safe. Сравнение: базовая интеграция занимает 3-4 недели, расширенная — 6-8 недель, но окупается за счёт снижения транзакционных издержек на 30%.

Кастомные Guard и Module

Если нужна специфическая логика — пишем кастомный Guard или Module.

Пример Guard с лимитом дневных трат:

contract SpendingLimitGuard is BaseGuard {
    uint256 public dailyLimit;
    uint256 public currentDay;
    uint256 public spentToday;

    function checkTransaction(
        address to,
        uint256 value,
        bytes memory data,
        // ... остальные параметры
    ) external override {
        if (block.timestamp / 1 days > currentDay) {
            currentDay = block.timestamp / 1 days;
            spentToday = 0;
        }
        require(spentToday + value <= dailyLimit, "Daily limit exceeded");
        spentToday += value;
    }

    function checkAfterExecution(bytes32 txHash, bool success) external override {}
}

Guard подключается через Safe.setGuard(guardAddress) — сама транзакция требует threshold подписей.

Мультичейн Safe и Safe{Core} AA

Safe работает на 15+ сетях, адреса контрактов совпадают (деплой через CREATE2 с одинаковым salt). Safe адрес на Ethereum и Arbitrum может быть одинаковым, если деплоен с теми же параметрами (owners, threshold, nonce).

Safe{Core} Account Abstraction SDK — новый стэк, который интегрирует Safe с ERC-4337. Safe контракт становится ERC-4337 Account, транзакции идут через bundler, можно использовать Paymaster для оплаты газа в ERC-20. Это даёт до 90% экономии на газе по сравнению с классическим Safe.

Пошаговая интеграция Safe

  1. Аудит требований: определяем необходимые модули, Guards, сети.
  2. Разработка кастомных контрактов (модули/Guards), настройка Zodiac.
  3. Развёртывание на целевых сетях с использованием CREATE2 для одинаковых адресов.
  4. Интеграция с frontend через Safe Apps SDK или protocol-kit.
  5. Полный аудит: статический (Slither), динамический (Mythril), fuzzing (Echidna).
  6. Деплой с подготовкой документации и обучением команды.

Стек интеграции

Задача Инструмент
SDK для транзакций @safe-global/protocol-kit
Pending транзакции @safe-global/api-kit
Safe Apps (iframe dApp) @safe-global/safe-apps-sdk
Модули и расширения Zodiac framework
AA интеграция @safe-global/safe-core-sdk

Сравнение подходов: базовая vs расширенная интеграция

Параметр Базовая Расширенная
Подпись транзакций Через Transaction Service Кастомные flow + Modules
Автоматизация Нет Zodiac, Gelato, кастомные Module
Безопасность Стандартный аудит Safe + кастомный аудит Guards
Сроки 3-4 недели 6-8 недель + аудит
Стоимость Индивидуально Индивидуально

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

  • Разработка и развёртывание Safe контрактов (Ethereum, Polygon, Arbitrum и др.)
  • Кастомные модули и Guards с полным аудитом
  • Интеграция Safe Apps SDK для вашего dApp
  • Настройка Zodiac модулей (Reality, Delay, Roles)
  • Подключение Safe{Core} AA для gas-оптимизации
  • Документация, доступы, обучение команды
  • Техническая поддержка на этапе внедрения

Наш опыт и гарантии

Более 5 лет опыта в Web3, реализовали 20+ интеграций Safe для DAO, DeFi и корпоративных заказчиков. Официальные SDK Safe используем в production. Гарантируем безопасность кастомных контрактов — каждый модуль проходит формальную верификацию и fuzzing тесты. Наши решения включают настройку протокола безопасности Safe через кастомные Guards.

Получите консультацию по вашему проекту. Свяжитесь с нами для оценки.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

Процесс разработки

  1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
  2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
  3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
  4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
  5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
  6. Интеграция с dApps — EIP-1193, WalletConnect v2.
  7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

  • Исходные коды смарт-контрактов (Solidity/Rust) с документацией
  • Backend-сервис MPC-координации (на Go или Rust) с API
  • Мобильное приложение (iOS/Android) или браузерное расширение
  • Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
  • Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
  • Документация администратора и пользователя
  • Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
  • Обучение вашей команды (2-3 сессии)
  • Поддержка после запуска — 1 месяц

Сроки и стоимость

Тип решения Сроки (рабочие недели)
Custodial с базовым UI 4–8
Non-custodial с MPC-интеграцией 8–16
EIP-4337 Account с paymaster 6–12
Institutional (HSM + MPC + compliance) от 16

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

  • Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
  • Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
  • Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
  • Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.