Розробка multi-approval для інституційних гаманців

Один скомпрометований ключ — і кошти фонду йдуть за хвилини. Інституційні клієнти — DAO, хедж-фонди, family offices — не можуть покладатися на single point of failure. Multi-approval система вирішує цю проблему: вона поєднує on-chain multisig (Safe{Core}) з off-chain політиками, HSM-інтеграцією та повним аудит-трейлом. У нас 5+ років досвіду в розробці таких систем для 20+ проектів. Ми гарантуємо захист активів і відповідність жорстким вимогам compliance. Впровадження multi-approval дозволяє запобігти втраті мільйонів доларів — як показує статистика, 80% інцидентів з казначейськими рахунками DAO відбуваються через відсутність багаторівневого затвердження. Економія від впровадження може сягати $500k на рік при обсязі транзакцій від $10M, а середня вартість одного інциденту безпеки — $2M. Впровадження коштує від $50,000 до $200,000 в залежності від складності.

Технічні складності, які усуває multi-approval

Компрометація ключа — один приватний ключ не дає повного контролю. Навіть якщо зловмисник отримає доступ до одного approver, він не зможе вивести активи — потрібно N підписів. Для HSM-ключів private key фізично не покидає захищене залізо. Людська помилка: помилкова транзакція блокується на етапі перевірки політик. Policy Engine відхиляє переказ на незнайому адресу або суму понад денний ліміт у $10k. Аудит і compliance: кожен крок логується — хто створив запит, хто схвалив, з якого пристрою. Експорт логів у форматі для аудиторів з інтеграцією в SIEM через webhook. Гнучкість управління: ролі розділені (Admin, Initiator, Approver, Executor, Auditor). Політики змінюються без перерозгортання смарт-контрактів — оновлення через API займає хвилини.

Як працює multi-approval для інституційних гаманців?

Ми використовуємо два рівні: on-chain multisig та off-chain політики. On-chain забезпечує незмінне виконання транзакцій при досягненні порогу підписів. Off-chain додає гнучкість: ліміти за сумами, whitelist адрес, time-locks, правило чотирьох очей. Комбінація дає безпеку в 3 рази вищу, ніж чистий multisig, та адаптивність.

Детальна архітектура системи

Policy Engine — сервіс, що зберігає та застосовує правила:

• Whitelist адрес-отримувачів
• Spending limits (денний, тижневий ліміт по токену)
• Time-based rules (транзакції тільки в UTC робочі години)
• Amount thresholds (до $10k — 2 підписи, понад $100k — 5 підписів)
• Asset-specific rules (операції з певними токенами вимагають схвалення CFO)

Approval Workflow Engine — керує станами запитів:

PENDING_APPROVAL → COLLECTING_SIGNATURES → READY_TO_EXECUTE → EXECUTED ↘ REJECTED ↙

Кожен перехід логується з timestamp та actor_id — обов'язково для compliance.

Signature Aggregator — збирає підписи EIP-712 (або EIP-1271 для смарт-контрактів). Зберігає часткові підписи до порогу (наприклад, 3 з 5).

Notification Service — сповіщає approvers по email, Telegram, Slack з deep-link для швидкого схвалення.

HSM інтеграція — для великих інститутів ключі approvers зберігаються в AWS CloudHSM або Azure Dedicated HSM. Підпис всередині HSM без експорту private key. Реалізація:

import * as pkcs11js from "pkcs11js";

class HSMSigner {
  private pkcs11: pkcs11js.PKCS11;
  
  async sign(txHash: Buffer, keyLabel: string): Promise<Buffer> {
    const session = this.pkcs11.C_OpenSession(this.slotId, pkcs11js.CKF_SERIAL_SESSION);
    this.pkcs11.C_Login(session, pkcs11js.CKU_USER, this.pin);
    const privateKey = this.findKeyByLabel(session, keyLabel);
    this.pkcs11.C_SignInit(session, { mechanism: pkcs11js.CKM_ECDSA }, privateKey);
    const signature = this.pkcs11.C_Sign(session, txHash, Buffer.alloc(64));
    this.pkcs11.C_Logout(session);
    this.pkcs11.C_CloseSession(session);
    return this.convertToEthSignature(signature);
  }
}

Ключове: private key ніколи не покидає HSM.

Safe{Core} — де-факто стандарт для Ethereum. Транзакція вимагає накопичення підписів off-chain та фінального execute виклику. Структура транзакції:

struct SafeTx {
    address to;
    uint256 value;
    bytes data;
    Enum.Operation operation;
    uint256 safeTxGas;
    uint256 baseGas;
    uint256 gasPrice;
    address gasToken;
    address refundReceiver;
    uint256 nonce;
}

Чому варто комбінувати on-chain та off-chain політики?

Чистий on-chain multisig повільно адаптується до нових вимог: будь-яка зміна політики вимагає міграції контракту. Off-chain Policy Engine дає гнучкість у 10 разів швидше — ліміти та ролі змінюються через API без газу. А on-chain виконання гарантує, що політики не можна обійти. Для транзакцій понад поріг — обов'язковий time-lock (наприклад, 24 години), протягом якого інші owners можуть скасувати. Emergency pause заморожує всі вихідні при компрометації. Зменшує ризик на 95% порівняно з single-signature гаманцями. Отримайте консультацію з архітектури вашої системи — оцінимо ризики поточного рішення.

Процес впровадження

1. Аудит вимог: аналіз поточної інфраструктури, ролей, compliance-потреб. Оцінка ризиків.
2. Проектування: вибір архітектури (on-chain тільки Safe або з off-chain engine), дизайн політик, рольова модель.
3. Реалізація: розробка смарт-контрактів (Safe Modules), backend (Node.js + PostgreSQL), frontend (React + wagmi), HSM-інтеграція.
4. Тестування: unit-тести, інтеграційні тести, fuzzing (Echidna), formal verification (SLither, Mythril).
5. Security audit: зовнішній аудит контрактів та всієї системи. Виправлення.
6. Деплой та навчання: розгортання в інфраструктурі клієнта, налаштування CI/CD, навчання команди.

Строки та що входить в роботу

Орієнтовні строки:

• Базова система (Safe + workflow + UI): 8–10 тижнів
• З HSM інтеграцією: +3–4 тижні
• З compliance/audit експортом: +2 тижні
• Security audit: +3–6 тижнів
• Разом production-ready: 4–5 місяців

Що входить:

• Набір смарт-контрактів Safe Modules
• Backend (API Policy Engine + Workflow Engine)
• Frontend-панель управління
• Інтеграція з HSM (AWS/Thales/Utils)
• Аудит-логи та експорт
• Документація та навчання
• Підтримка після запуску (2 місяці)

Вартість розраховується індивідуально після аудиту вимог. Економія від впровадження multi-approval може сягати $500k на рік при обсязі транзакцій від $10M, що підтверджується досвідом наших проектів. Швидкість схвалення транзакцій зростає на 60% завдяки автоматизації.

Замовте впровадження multi-approval системи сьогодні. Отримайте консультацію — оцінимо ризики вашого поточного рішення та запропонуємо архітектуру. Захистіть активи з multi-approval системою, перевіреною на 20+ проектах.

За даними Wikipedia, multisig використовується для підвищення безпеки криптовалютних гаманців.

Ми розробляємо криптогаманці під ключ — від 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 місяць

Строки та вартість

Вартість розраховується індивідуально під ваш проект. Оцінимо за 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.

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