White-label криптокошелек: разработка под ключ

Разработка White-label криптокошелька

Вы запускаете криптобиржу или DeFi-приложение. Пользователи должны управлять средствами в вашем брендированном интерфейсе, а не через сторонние кошельки. White-label криптокошелёк — это не смена логотипа MetaMask, а полноценный продукт с вашим брендом, бизнес-логикой и контролем. Мы разрабатываем такие кошельки под ключ: от архитектуры ключей до интеграции с dApps. Ниже — реальные технические решения, а не маркетинговые обещания.

Какую архитектуру выбрать: Custodial, Non-custodial или MPC?

Первое архитектурное решение определяет всё. Custodial — ключи на ваших серверах, простой UX, но вы несёте ответственность за средства. Non-custodial (HD Wallet) — ключи генерируются на устройстве пользователя, BIP-32/39/44 деривация. Стандарт для consumer-продуктов. MPC (Multi-Party Computation) — приватный ключ никогда не существует целиком ни на одном устройстве; shares распределены между клиентом и серверами. Схема 2-of-2 или 2-of-3 сочетает безопасность non-custodial с удобством восстановления.

Какие SDK и компоненты нужны для white-label кошелька?

Выбор базового кода критичен. WalletCore от Trust Wallet (open source, C++ ядро, биндинги под iOS/Android/WebAssembly) — самый зрелый для multi-chain HD кошелька, но сложен в интеграции. Coinbase Wallet SDK подходит для EVM + Base. WalletKit от Reown (ex-WalletConnect) обязателен для работы с dApps через WalletConnect v2. Собственная реализация на @noble/curves и @scure/bip32 даёт полный контроль, но оправдана для специализированных продуктов. Каждый вариант имеет свои компромиссы: готовые SDK ускоряют разработку на 30–40%, но ограничивают кастомизацию; собственное решение дает гибкость, но требует глубокой экспертизы.

Ключевые технические компоненты

Генерация и хранение ключей

Безопасность начинается с генерации энтропии: только CSPRNG (crypto.getRandomValues() в браузере, /dev/urandom на сервере). Пример генерации мнемоника и деривации адреса:

import { generateMnemonic, mnemonicToSeedSync } from "@scure/bip39";
import { wordlist } from "@scure/bip39/wordlists/english";
import { HDKey } from "@scure/bip32";

const mnemonic = generateMnemonic(wordlist, 256);
const seed = mnemonicToSeedSync(mnemonic);
const masterKey = HDKey.fromMasterSeed(seed);

const ethKey = masterKey.derive("m/44'/60'/0'/0/0");

Хранение на мобильных: iOS Keychain с kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Android Keystore с аппаратной привязкой. В вебе — зашифрованный IndexedDB или привязка к паролю через Argon2.

Multi-chain поддержка

Типовой набор для white-label продукта: EVM (Ethereum, BSC, Polygon, Arbitrum, etc.), Bitcoin (BIP-84/86), Solana, TON, Cosmos. Каждая экосистема — отдельный провайдер с интерфейсом:

interface ChainProvider {
  getBalance(address: string): Promise<bigint>;
  sendTransaction(tx: UnsignedTransaction, key: Uint8Array): Promise<string>;
  estimateGas(tx: UnsignedTransaction): Promise<bigint>;
  getTransactionHistory(address: string): Promise<Transaction[]>;
}

WalletConnect v2 интеграция

Без WalletConnect v2 кошелёк не работает с сотнями dApps. Протокол использует relay servers от Reown. Пример обработки session proposal и запроса на подпись:

import { Core } from "@walletconnect/core";
import { Web3Wallet } from "@walletconnect/web3wallet";

const core = new Core({ projectId: YOUR_PROJECT_ID });
const wallet = await Web3Wallet.init({
  core,
  metadata: { name: "Your Wallet", ... }
});

wallet.on("session_proposal", async ({ id, params }) => {
  const session = await wallet.approveSession({ id, namespaces: buildNamespaces(params.requiredNamespaces) });
});

wallet.on("session_request", async ({ topic, params, id }) => {
  const { request } = params;
  if (request.method === "eth_sendTransaction") {
    const txHash = await signAndSend(request.params[0]);
    await wallet.respondSessionRequest({ topic, response: { id, result: txHash, jsonrpc: "2.0" } });
  }
});

Почему важна мультичейн поддержка?

Пользователи ожидают работать с разными блокчейнами из одного интерфейса. Без мультичейн поддержки вы теряете аудиторию — до 40% потенциальных пользователей. Прямые RPC вызовы не масштабируются: используйте агрегаторы (Moralis, Covalent, Ankr Advanced API). Для метаданных токенов — TrustWallet Assets (open source). Для Solana — Helius.

Кастомизация и белый лейбл

Кастомизируемые элементы: визуальный брендинг через design tokens, список поддерживаемых сетей (конфигурационный файл), встроенные функции (swap, стейкинг, NFT галерея, fiat on/off ramp), in-app browser с инжектированным EIP-1193 провайдером, push-уведомления. Что не стоит пересобирать: криптографические примитивы — ошибки в них ведут к потере средств. Использование готовых модулей сокращает затраты на разработку на 30–40% по сравнению с написанием с нуля.

Безопасность

Биометрическая аутентификация (TouchID/FaceID, BiometricPrompt) обязательна. Jailbreak/root detection, certificate pinning для API, transaction simulation (Tenderly или Blowfish) перед подписью — показываем пользователю ожидаемые изменения балансов. Экономия на лицензиях и инфраструктуре может составлять до 50% при выборе MPC-архитектуры.

Что входит в готовое решение

• Полный исходный код кошелька с документацией
• Интеграция с выбранными блокчейнами и API
• Настройка брендинга и деплой в магазины приложений
• Обучение вашей команды
• Поддержка в течение 30 дней после запуска

Сроки и бюджет

Сроки зависят от функциональности: MVP (EVM only, mobile) — 6–8 недель, стандартный white-label (multi-chain, swap, fiat) — 3–5 месяцев, полнофункциональный (MPC, extension, audit) — от 6 месяцев. Для точной оценки вашего проекта свяжитесь с нами — мы подготовим коммерческое предложение.

Закажите разработку white-label криптокошелька под ключ. Получите консультацию по архитектуре и бюджету. Сократите время выхода на рынок на 50% за счет готовых компонентов.

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

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