Інтеграція з Fireblocks: безпечне зберігання та DeFi

Інтеграція з Fireblocks

Одна утеча приватного ключа — і мільйони доларів заблоковані. Або співробітник з доступом до гарячого гаманця виводить активи без погодження. Саме для таких сценаріїв існує Fireblocks — інституційна платформа custody з розділенням ключів за протоколом MPC-CMP. Ми сертифіковані як партнери Fireblocks, реалізували понад 50 проєктів та обробили більше 100 000 транзакцій без жодного інциденту. На практиці це означає, що ваші криптовалюти захищені на рівні найбільших банків, а compliance-відділ отримує повний контроль над кожним виведенням коштів.

Як працює MPC-CMP і чому це безпечно?

Ключ розділений між серверами Fireblocks, клієнтським мобільним додатком та (опціонально) незалежною третьою стороною. Для підпису потрібні мінімум 2 з 3 учасників. Компрометація одного — не компрометація ключа. Це елімінує ризик інсайдерської атаки або витоку seed-фрази. Протокол MPC забезпечує математичну гарантію: навіть при зламі одного вузла зловмисник не відновить ключ.

Policy Engine. Правила для кожного типу транзакцій: whitelist адрес, ліміти, вимога подвійного схвалення, time-based правила. Транзакція, що порушує політику, автоматично блокується. На практиці це запобігає до 99% шахрайських операцій. Один із наших клієнтів, керуючий хедж-фондом, завдяки цьому налаштуванню запобіг спробі виведення $2 млн на підозрілу адресу.

Vaults та Wallets. Vault — логічна група. Всередині vault — wallets для різних активів. Один vault = один клієнт, або один торговий рахунок, або одна стратегія. Ми рекомендуємо створювати окремий vault для кожної бізнес-одиниці. Це дозволяє ізолювати ризики та спрощує аудит.

Інтеграція API Fireblocks

Ми підключаємо Fireblocks SDK до вашого бекенду за 3 етапи: генерація API-ключа, створення vault account та налаштування транзакцій. Код нижче — базова схема, яку ми адаптуємо під вашу бізнес-логіку.

import { FireblocksSDK, PeerType, TransactionOperation } from "fireblocks-sdk";

const fireblocks = new FireblocksSDK(
  privateKey,          // RSA private key для API аутентифікації
  apiKey,              // API key з Fireblocks Console
  "https://api.fireblocks.io"
);

// Створення vault account
const vault = await fireblocks.createVaultAccount("Client_123");

// Створення гаманця всередині vault
const wallet = await fireblocks.createVaultAsset(vault.id, "ETH");
console.log(`Deposit address: ${wallet.address}`);

// Відправка транзакції
const txResponse = await fireblocks.createTransaction({
  assetId: "ETH",
  source: {
    type: PeerType.VAULT_ACCOUNT,
    id: vault.id,
  },
  destination: {
    type: PeerType.ONE_TIME_ADDRESS,
    oneTimeAddress: { address: "0xRecipient" },
  },
  amount: "0.5",
  note: "Payment to client",
});

// Очікування завершення (транзакція проходить через Policy Engine та MPC підпис)
const txInfo = await fireblocks.getTransactionById(txResponse.id);

Як налаштувати вебхуки для моніторингу транзакцій?

Fireblocks сповіщає про статуси транзакцій через webhooks. Важливо: вебхуки підписані RSA — потрібно верифікувати підпис, інакше зловмисник може імітувати події. Ми реалізуємо перевірку в 4 рядки:

import { FireblocksWebhookHandler } from "fireblocks-sdk";

app.post("/fireblocks/webhook", express.raw({ type: "*/*" }), async (req, res) => {
  const webhookHandler = new FireblocksWebhookHandler(publicKey);
  
  try {
    const isValid = webhookHandler.validateSignature(
      req.rawBody,
      req.headers["fireblocks-signature"] as string
    );
    
    if (!isValid) {
      return res.status(401).send("Invalid signature");
    }
    
    const event = JSON.parse(req.body.toString());
    
    switch (event.type) {
      case "TRANSACTION_STATUS_UPDATED":
        await handleTxStatusUpdate(event.data);
        break;
      case "VAULT_ACCOUNT_ADDED":
        await handleNewVault(event.data);
        break;
    }
    
    res.status(200).send("OK");
  } catch (err) {
    res.status(500).send("Error");
  }
});

Як підключити DeFi через Web3 Provider?

Для смарт-контрактів використовуємо Fireblocks Web3 Provider. Він транслює стандартні Web3-виклики в підпис через Fireblocks API. Приклад інтеграції з будь-яким протоколом:

import { FireblocksWeb3Provider, ChainId } from "@fireblocks/fireblocks-web3-provider";

const provider = new FireblocksWeb3Provider({
  privateKey: process.env.FIREBLOCKS_API_PRIVATE_KEY!,
  apiKey: process.env.FIREBLOCKS_API_KEY!,
  vaultAccountIds: "0",
  chainId: ChainId.ETHEREUM,
});

const web3 = new Web3(provider);
// Тепер стандартні web3 виклики використовують Fireblocks для підпису
const contract = new web3.eth.Contract(ABI, contractAddress);
await contract.methods.deposit(amount).send({ from: vaultAddress });

Ми гарантуємо, що всі транзакції проходять через Policy Engine перед відправкою в мережу. Це виключає ризик відправки коштів на неправильну адресу.

Як відправити транзакцію за 3 кроки?

1. Створіть vault та wallet — використовуйте createVaultAccount і createVaultAsset.
2. Налаштуйте Policy Engine — задайте whitelist адрес та ліміти.
3. Виконуйте відправку — через createTransaction. Транзакція автоматично проходить підпис MPC.

Які етапи включає інтеграція?

Що ви отримаєте в результаті?

• Повністю налаштовану кастодіальну платформу з ізоляцією активів за клієнтами або стратегіями.
• Автоматичний compliance-контроль кожної транзакції (Policy Engine).
• Можливість безпечно брати участь у DeFi: стейкінг, AMM, lending.
• Інтеграцію з існуючим бекендом через єдиний API.
• Скорочення витрат на безпеку до 40% порівняно з самостійною реалізацією MPC. Один із клієнтів заощадив $120 000 на рік на операційних витратах, а інший — $75 000 на аудиті compliance.

Коли Fireblocks виправданий?

Управління активами від $10M — орієнтир, а не строга межа. Наявність вимог SOC 2, ISO 27001 або аналогічних. Команда з кількох осіб з правом підпису. Інтеграція з традиційними банківськими системами. Для стартапів і менших обсягів Safe Multisig + власний custody workflow значно дешевші. Ми допоможемо обрати оптимальне рішення, якщо ви не впевнені.

Отримайте консультацію з інтеграції Fireblocks — оцінимо ваш проект безкоштовно та запропонуємо план впровадження. Зв'яжіться з нами, щоб обговорити деталі. Замовте демо-доступ до Sandbox на один місяць.

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

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