Интеграция с BitGo: кастодиальное хранение криптоактивов под ключ

Интеграция с BitGo

Кастодиальное хранение криптоактивов — одна из самых критичных задач для любого криптосервиса. Ошибка на этапе работы с ключами может стоить миллионов: вспомните историю с потерей доступа к кошельку или кражу через уязвимость в мультиподписи. BitGo решает эту проблему с помощью проверенной схемы 2-из-3, где ни одна сторона не владеет всеми ключами. Мы внедряем BitGo под ключ — от настройки инфраструктуры до интеграции с вашим бэкендом. За 5+ лет мы реализовали интеграции для десятков проектов, включая DeFi-протоколы, NFT-маркетплейсы и криптовалютные биржи.

Как BitGo обеспечивает безопасность мультиподписи?

BitGo использует 2-of-3 multisig — три ключа распределены: User key (у клиента), BitGo key (на серверах BitGo в HSM) и Backup key (офлайн, для восстановления). Транзакция требует подписей двух из трёх. Обычный флоу: user key инициирует → BitGo key подписывает после проверки Policy Engine. Схема исключает единую точку отказа и соответствует стандартам квалифицированного кастодиана. Для холодного хранения используется отдельный процесс, где backup key никогда не покидает HSM.

Почему выбирают BitGo для кастодиального хранения?

BitGo — старейший кастодиан в криптоиндустрии (основан в 2013). Он получил статус qualified custodian в штате Нью-Йорк, что важно для регуляторного соответствия. В отличие от MPC-решений, multisig не требует сложной математики и может быть верифицирован на уровне блокчейна. Например, для Bitcoin мультиподпись легко проверяется через обычный explorer. Решение BitGo быстрее в настройке: интеграция API занимает от 2 до 4 недель, тогда как у MPC-решений onboarding может затянуться до 8 недель из-за инфраструктурных требований. Источник: документация BitGo

Архитектура BitGo-кошельков

Каждый кошелек привязан к конкретному активу — coin. BitGo предоставляет единый REST API для всех поддерживаемых сетей (Bitcoin, Ethereum, Polygon, Arbitrum, Solana и другие). Кошельки могут быть горячими (online) или холодными (offline). Для холодного хранения ключи генерируются на аппаратном модуле безопасности (HSM) и никогда не покидают устройство. API позволяет создавать неограниченное количество кошельков и адресов, что удобно для создания мультивалютных платформ.

BitGo API интеграция: пример на TypeScript

import * as BitGoJS from "bitgo";

const bitgo = new BitGoJS.BitGo({
  env: "prod",          // или "test" для BitGo Express
  accessToken: process.env.BITGO_ACCESS_TOKEN,
});

// Получение кошелька
const wallet = await bitgo
  .coin("eth")
  .wallets()
  .get({ id: "WALLET_ID" });

// Получение адреса для депозита
const address = await wallet.createAddress();
console.log(`Deposit to: ${address.address}`);

// Отправка транзакции
const txRequest = await wallet.send({
  address: "0xRecipient",
  amount: "100000000000000000", // 0.1 ETH в wei
  walletPassphrase: process.env.WALLET_PASSPHRASE,
  comment: "Payment #123",
});

Как настроить Policy Engine?

Policy Engine — это набор правил, которые проверяются перед подписью. Типичные настройки: whitelist адресов, дневные лимиты, многофакторная аутентификация для крупных переводов. Пример конфигурации:

// Whitelist адресов
await wallet.createPolicy({
  id: "whitelist-policy",
  type: "allowanddeny",
  condition: { type: "destination", add: ["0xApprovedAddress1"] },
  action: { type: "allow" },
});

// Дневной лимит
await wallet.createPolicy({
  id: "daily-limit",
  type: "velocityLimit",
  condition: { type: "velocity", amount: 10000, timeWindow: 86400 },
  action: { type: "getApproval" },
});

Правила выполняются в порядке приоритета: deny → allow → velocity → approval. Это позволяет гибко настроить безопасность под ваш бизнес.

Webhook и мониторинг транзакций

BitGo отправляет webhook-уведомления о входящих и исходящих переводах. Пример интеграции:

// Создание webhook
await bitgo.coin("eth").webhooks().add({
  type: "transfer",
  url: "https://yourapp.com/webhooks/bitgo",
  label: "Deposit notifications",
});

// Express handler
app.post("/webhooks/bitgo", async (req, res) => {
  const { type, wallet, transfer } = req.body;
  if (type === "transfer" && transfer.type === "receive") {
    await creditUserBalance(wallet, transfer.valueString, transfer.txid);
  }
  res.status(200).send("OK");
});

Webhooks работают в реальном времени, позволяя моментально реагировать на депозиты. Также можно настроить polling через REST API для отказоустойчивости.

Сравнение BitGo и Fireblocks

BitGo выигрывает в прозрачности и регуляторной истории, Fireblocks — в скорости подключения и мультичейн поддержке. По нашим данным, интеграция BitGo занимает в 2 раза меньше времени, чем разработка собственного кастодиального решения.

Что входит в интеграцию под ключ?

• Анализ требований и проектирование архитектуры
• Настройка BitGo Express (локальный прокси) при необходимости
• Разработка интеграции: создание кошельков, управление адресами, отправка транзакций
• Конфигурация Policy Engine: whitelist, лимиты, правила подтверждения
• Интеграция webhook для мониторинга в реальном времени
• Тестирование на тестовой сети и в продакшене
• Документация по API и обучение команды
• Гарантийная поддержка 1 месяц после запуска

Процесс работы

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

Сроки интеграции BitGo API — от 4 до 8 недель в зависимости от объёма. Параллельно идёт комплаенс-онбординг (от 2 до 8 недель). Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта.

Частые ошибки при интеграции BitGo и как их избежать

• Игнорирование rate limit — BitGo API ограничивает 10 запросов в секунду на кошелёк. Используйте очередь.
• Отсутствие мониторинга backup key — если ключ утерян, восстановление через BitGo займёт недели.
• Слишком агрессивные политики — блокировка всех транзакций выше лимита без возможности поднять лимит одобрением.

Правильная настройка Policy Engine и резервирование ключей — основа безопасной интеграции.

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

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

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

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

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