Кастомна розробка HD-гаманця для бізнесу: BIP-32/39/44 та мультичейн

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Кастомна розробка HD-гаманця для бізнесу: BIP-32/39/44 та мультичейн
Середній
~1-2 тижні
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    965
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1208
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    954

Створення надійних криптогаманців для бізнесу

Ми команда блокчейн-інженерів із сумарним досвідом 12+ років у production-рішеннях (Ethereum, Solana, Polygon, Arbitrum, Optimism). За 5 років роботи реалізували понад 50 кастомних гаманців для DeFi-протоколів, централізованих бірж, NFT-маркетплейсів та enterprise-рішень. Наші спеціалісти — автори opensource-бібліотек для BIP-32 та BIP-39, сертифіковані за стандартами безпеки OWASP. Кожен гаманець проходить повний цикл аудиту: статичний аналіз (Slither), fuzzing (Echidna) та перевірку на відповідність BIP-44. Професійна розробка криптогаманця під ключ може заощадити вашому проекту до 60% бюджету на інтеграцію порівняно з типовими рішеннями.

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

HD-гаманець використовує три ключові стандарти. BIP-39 визначає перетворення ентропії в мнемонічну фразу (12 або 24 слова). BIP-32 будує дерево ключів через CKD-функцію: hardened derivation (з апострофом у шляху) захищає майстер-ключ — навіть якщо зловмисник отримає дочірній private key, він не зможе відновити parent. BIP-44 задає єдиний формат шляхів: m / purpose' / coin_type' / account' / change / index. Наприклад, перший Ethereum-адрес: m/44'/60'/0'/0/0. Офіційні test vectors з репозиторію BIP-39 підтверджують коректність реалізації.

import * as bip39 from "bip39";
import { HDKey } from "@scure/bip32";
import { keccak256 } from "ethereum-cryptography/keccak";
import { secp256k1 } from "ethereum-cryptography/secp256k1";

function generateMnemonic(strength: 128 | 256 = 128): string {
  return bip39.generateMnemonic(strength);
}

async function mnemonicToSeed(mnemonic: string, passphrase: string = ""): Promise<Uint8Array> {
  if (!bip39.validateMnemonic(mnemonic)) {
    throw new Error("Invalid mnemonic");
  }
  return bip39.mnemonicToSeed(mnemonic, passphrase);
}
Властивість Hardened derivation (') Non-hardened derivation
Захист майстер-ключа Так (через HMAC-SHA512 із закритим ключем) Ні (розкриття дочірнього ключа дозволяє обчислити parent public key)
Індекси >2^31 0..2^31-1
Типове застосування Coin type, account Change, address index

Які мережі підтримуються?

Наші гаманці працюють з Ethereum, Polygon, Arbitrum, Optimism, Base, BNB Chain та Solana. CoinType для кожної мережі задається за стандартом BIP-44: 60 для Ethereum, 501 для Solana тощо. При необхідності додаємо будь-яку EVM-сумісну або кастомну мережу через зміну coin_type та додаткове налаштування RPC.

interface DerivedAccount {
  path: string;
  privateKey: Uint8Array;
  publicKey: Uint8Array;
  address: string;
  xpub: string;
}

function deriveAccount(seed: Uint8Array, accountIndex: number = 0, addressIndex: number = 0, coinType: number = 60): DerivedAccount {
  const hdKey = HDKey.fromMasterSeed(seed);
  const path = `m/44'/${coinType}'/${accountIndex}'/0/${addressIndex}`;
  const derived = hdKey.derive(path);
  if (!derived.privateKey) throw new Error("Failed to derive private key");
  const publicKey = secp256k1.getPublicKey(derived.privateKey, false);
  const address = publicKeyToAddress(publicKey);
  return { path, privateKey: derived.privateKey, publicKey, address, xpub: derived.publicExtendedKey };
}

Безпека ключів: апаратне шифрування

Використовуємо апаратне шифрування: Secure Enclave (iOS) та Android Keystore. Для веб-версій — Web Crypto API з PBKDF2 (600 000 ітерацій) та AES-256-GCM, що відповідає актуальним NIST-рекомендаціям. Приклад шифрування keystore:

async function encryptKeystore(privateKey: Uint8Array, password: string): Promise<EncryptedKeystore> {
  const salt = crypto.getRandomValues(new Uint8Array(32));
  const iv = crypto.getRandomValues(new Uint8Array(16));
  const passwordKey = await crypto.subtle.importKey("raw", new TextEncoder().encode(password), "PBKDF2", false, ["deriveBits", "deriveKey"]);
  const encryptionKey = await crypto.subtle.deriveKey({ name: "PBKDF2", salt, iterations: 600_000, hash: "SHA-256" }, passwordKey, { name: "AES-GCM", length: 256 }, false, ["encrypt", "decrypt"]);
  const encrypted = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, encryptionKey, privateKey);
  return { version: 3, crypto: { ciphertext: Buffer.from(encrypted).toString("hex"), cipher: "aes-256-gcm", kdf: "pbkdf2", kdfparams: { dklen: 32, salt: Buffer.from(salt).toString("hex"), c: 600_000, prf: "hmac-sha256" }, iv: Buffer.from(iv).toString("hex"), mac: "" } };
}

Multi-account та watch-only режим: гаманець підтримує кілька BIP-44 акаунтів (зміна account index) та watch-only доступ через xpub. Це дозволяє показувати баланси без приватних ключів — ідеально для cold storage моніторингу.

class HDWalletManager {
  private hdKey: HDKey;
  constructor(seed: Uint8Array) { this.hdKey = HDKey.fromMasterSeed(seed); }
  getAccount(accountIndex: number): DerivedAccount { /* ... */ }
  getAccountXpub(accountIndex: number): string { return this.hdKey.derive(`m/44'/60'/${accountIndex}'`).publicExtendedKey; }
  static deriveAddressFromXpub(xpub: string, addressIndex: number): string {
    const hdKey = HDKey.fromExtendedKey(xpub);
    const derived = hdKey.derive(`m/0/${addressIndex}`);
    return publicKeyToAddress(derived.publicKey!);
  }
}

Підписання транзакцій: підтримуємо EIP-1559 (Ethereum) та legacy-транзакції. Використовуємо viem для підписання:

async function signTransaction(privateKey: Uint8Array, txParams: { to: string; value: bigint; data: string; chainId: number; nonce: number; maxFeePerGas: bigint; maxPriorityFeePerGas: bigint; gas: bigint }): Promise<string> {
  const account = privateKeyToAccount(`0x${Buffer.from(privateKey).toString("hex")}`);
  return await account.signTransaction({ type: "eip1559", ...txParams });
}

Коли потрібна кастомна розробка HD-гаманця?

Якщо ваш проект вимагає нестандартних crypto-шляхів (наприклад, для NFT-кастодіального зберігання або DeFi-агрегатора), мультичейн-підтримки без зовнішніх мостів або апаратної інтеграції — типові рішення неефективні. Ми будуємо архітектуру з нуля: ви отримуєте код, який працює на всіх L2, не залежить від версій бібліотек і легко розширюється. Приклад: для одного клієнта ми реалізували гаманець з підтримкою 15 мереж та кастомним gas-менеджментом — термін 3 тижні.

Покроковий процес розробки HD-гаманця

  1. Аналіз вимог — визначаємо необхідні мережі, типи транзакцій, рівень безпеки (холодне/гаряче зберігання).
  2. Проектування архітектури — обираємо BIP-шляхи, стек (Foundry/Hardhat), схему шифрування.
  3. Реалізація ядра — генерація мнемоніки, derivation key, підписання транзакцій.
  4. Інтеграція з мережами — налаштування RPC, підтримка EIP-1559, мультичейн-маршрутизація.
  5. Безпека та аудит — статичний аналіз, fuzzing, перевірка на OWASP top10.
  6. Тестування — прогін test vectors, імпорт у MetaMask/Ledger, E2E-тести.
  7. Деплой та документація — CI/CD, API-документація, навчання команди.

Що входить в роботу

При замовленні розробки HD-гаманця під ключ ви отримуєте:

  • Вихідний код з коментарями (TypeScript / React Native)
  • Документацію з інтеграції та API
  • Доступ до закритого репозиторію та CI/CD
  • Тестовий набір (unit, integration, e2e)
  • Консультаційну підтримку на етапі впровадження
  • Гарантію на код (6 місяців безкоштовних доопрацювань за специфікацією)

Сумісність та тестування

Перед релізом прогоняємо офіційні test vectors з BIP-39 та BIP-32. Перевіряємо імпорт мнемоніки в MetaMask, Ledger Live та Trust Wallet.

Тест Перевірка
Імпорт у MetaMask Та ж мнемоніка → ті ж адреси
Імпорт у Ledger Live Через стандартний BIP-44 шлях
Імпорт у Trust Wallet 12/24 слів, перша адреса збігається
Test vectors BIP-39 Офіційні тест-вектори з репозиторію

Вартість розробки розраховується індивідуально, виходячи зі складності та необхідного функціоналу. Зв'яжіться з нами для консультації — ми підготуємо архітектуру та точний кошторис за 2 робочих дні. Замовте розробку HD-гаманця — отримайте готовий продукт, який масштабується під будь-які блокчейн-завдання.

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

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

Тип рішення Строки (робочі тижні)
Custodial з базовим UI 4–8
Non-custodial з MPC-інтеграцією 8–16
EIP-4337 Account з paymaster 6–12
Institutional (HSM + MPC + compliance) від 16

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

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