Інтеграція 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. Flow:

  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 для газ-оптимізації
  • Документація, доступи, навчання команди
  • Технічна підтримка на етапі впровадження

Наш досвід та гарантії

Понад 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 — значні втрати, FTX — понад значну суму клієнтських коштів).

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 транзакції та батчинг операцій.

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 день — зв'яжіться з нами. Надаємо гарантію на код та 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.

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