Розробка White-label криптогаманця під ключ

Розробка White-label криптогаманця

Ви запускаєте криптобіржу або DeFi-додаток. Користувачі повинні керувати коштами у вашому брендованому інтерфейсі, а не через сторонні гаманці. White-label криптогаманець — це не зміна логотипу MetaMask, а повноцінний продукт з вашим брендом, бізнес-логікою та контролем. Ми маємо 7+ років досвіду в блокчейн-розробці та реалізували 30+ проєктів. Нижче — реальні технічні рішення, а не маркетингові обіцянки.

Яку архітектуру обрати: Custodial, Non-custodial чи MPC?

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

Які SDK та компоненти потрібні для white-label гаманця?

Вибір базового коду критичний. WalletCore від Trust Wallet (open source, C++ ядро, біндинги під iOS/Android/WebAssembly) — найзріліший для multi-chain HD гаманця, але складний в інтеграції. Coinbase Wallet SDK підходить для EVM + Base. WalletKit від Reown (екс-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. Підтримуємо понад 50 блокчейнів. Кожна екосистема — окремий провайдер з інтерфейсом:

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 сервери від 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% порівняно з написанням з нуля, що економить від $50,000 до $100,000.

Безпека

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

Що входить у готове рішення

• Повний вихідний код гаманця з документацією
• Інтеграція з обраними блокчейнами та 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 — значні втрати, 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.

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