Розробка мультичейн-гаманця: EVM, Solana, Cosmos

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка мультичейн-гаманця: EVM, Solana, Cosmos
Складний
від 2 тижнів до 3 місяців
Часті запитання

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

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

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

  • 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

Розробка криптогаманця, що підтримує кілька мереж, — це не просто «підключити кілька мереж». Це комплексна система, яка має коректно обробляти принципово різні блокчейн-архітектури: EVM-сумісні ланцюги (Ethereum, Arbitrum, Polygon, BSC), EVM-несумісні (Solana, Sui, Aptos), Bitcoin з UTXO-моделлю, Cosmos екосистему з IBC. Кожна має свою криптографію, формат транзакцій, fee-механізм та модель акаунтів. Без грамотної абстракції підтримка кожної нової мережі перетворюється на переписування половини кодової бази — саме так народжуються баги та затягуються терміни. Додатково постають питання gas optimization: в EVM-мережах вартість транзакції залежить від газу, а в Solana — від пріоритету, що потребує різних стратегій оцінки комісії.

Ми вирішуємо цю проблему за допомогою Chain Abstraction Layer — єдиного інтерфейсу для всіх мереж. Це дозволяє додати новий ланцюг за 1-2 тижні замість 2-3 місяців. На практиці це означає економію до $50,000 на проєкті. Такий підхід у 3 рази швидший за ручну реалізацію. Оцінимо ваш проєкт за 2 дні — зв'яжіться з нами.

Як працює деривація ключів у мультичейн гаманці?

Всі сучасні мультичейн гаманці будуються на стандартах BIP-32/BIP-39/BIP-44. Одна seed-фраза (12-24 слова) → один мастер ключ → дерево дочірніх ключів для кожної мережі. Стандарт BIP-44 визначає шлях деривації: m / purpose' / coin_type' / account' / change / index. Шлях складається з 5 рівнів: purpose (фіксований 44'), coin_type (наприклад, 0 для Bitcoin, 60 для Ethereum, 501 для Solana), account, change (0 для зовнішніх, 1 для здачі), index (адреси). Це дозволяє відновлювати всі ключі з однієї seed-фрази.

import { HDNodeWallet, Mnemonic } from 'ethers';
import { derivePath } from 'ed25519-hd-key';
import * as bip39 from 'bip39';

const mnemonic = Mnemonic.fromEntropy(crypto.getRandomValues(new Uint8Array(16)));
const seed = await bip39.mnemonicToSeed(mnemonic.phrase);

const evmWallet = HDNodeWallet.fromSeed(seed).derivePath("m/44'/60'/0'/0/0");
console.log('EVM address:', evmWallet.address);

const solanaPath = "m/44'/501'/0'/0'";
const { key: solanaPrivKey } = derivePath(solanaPath, seed.toString('hex'));

Що таке Chain Abstraction Layer?

Архітектура мультичейн гаманця будується на адаптерах — об'єктах, що одноманітно працюють з різними мережами. Це ключова абстракція, яка приховує відмінності в криптографії, форматах транзакцій та RPC.

interface ChainAdapter {
    chainId: string;
    chainName: string;
    getAddress(publicKey: Uint8Array): string;
    getBalance(address: string): Promise<bigint>;
    buildTransaction(params: TxParams): Promise<UnsignedTx>;
    signTransaction(tx: UnsignedTx, privateKey: Uint8Array): Promise<SignedTx>;
    broadcastTransaction(tx: SignedTx): Promise<string>;
    getTransactionStatus(txHash: string): Promise<TxStatus>;
    estimateFee(tx: UnsignedTx): Promise<FeeEstimate>;
}

class EVMAdapter implements ChainAdapter {
    private client: PublicClient;
    constructor(rpcUrl: string, public chainId: string, public chainName: string) {
        this.client = createPublicClient({ transport: http(rpcUrl) });
    }
    async getBalance(address: string): Promise<bigint> {
        return this.client.getBalance({ address: address as `0x${string}` });
    }
    async buildTransaction(params: TxParams): Promise<UnsignedTx> {
        const nonce = await this.client.getTransactionCount({ address: params.from as `0x${string}` });
        const feeData = await this.client.estimateFeesPerGas();
        return {
            to: params.to,
            value: params.value ?? 0n,
            data: params.data ?? '0x',
            nonce,
            maxFeePerGas: feeData.maxFeePerGas,
            maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
            chainId: BigInt(this.chainId),
        };
    }
}

Як додати новий ланцюг у мультичейн гаманець?

  1. Реалізувати ChainAdapter — описати криву (secp256k1 або ed25519), формат транзакції, fee-модель.
  2. Додати шлях деривації у BIP-44 — призначити coin_type (для Bitcoin — 0, Ethereum — 60, Solana — 501).
  3. Протестувати підпис та відправку — перевірити на testnet, переконатися, що explorer показує транзакцію.
  4. Затвердити через pull request — код-рев'ю та автоматичні тести (Slither, фаззинг).

Цей процес займає 1–2 тижні замість 2–3 місяців при ручній реалізації. Наш Chain Abstraction Layer скорочує час інтеграції в 3 рази.

Порівняння блокчейнів: EVM, Solana, Bitcoin
Параметр EVM (Ethereum) Solana Bitcoin
Крива підпису secp256k1 ed25519 secp256k1
Тип адреси hex (0x...) base58 bc1... (bech32)
Транзакції nonce-based parallel processing UTXO + script
Fee-модель EIP-1559 (base + priority) signature fee + priority sat/byte
DApp підтримка WalletConnect, MetaMask Phantom, Backpack BIP-322 (limited)

Безпечне зберігання та підпис

На мобільних платформах використовуємо Secure Enclave (iOS) або StrongBox (Android). Обмеження: вони не підтримують secp256k1 безпосередньо, тому seed зберігається зашифрованим у Keychain з біометрією. У Web Extension приватні ключі живуть лише в background service worker — content script не має до них доступу. Продуктивність підпису на мобільних пристроях вища, ніж у браузерних розширень, завдяки апаратному прискоренню. Як альтернативу для корпоративних рішень пропонуємо MPC (Multi-Party Computation), що усуває єдину точку відмови.

func storeSeed(_ seed: Data) throws {
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "wallet_seed",
        kSecValueData as String: seed,
        kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
        kSecAttrAccessControl as String: SecAccessControlCreateWithFlags(
            nil,
            kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
            [.biometryAny, .privateKeyUsage],
            nil
        )!
    ]
    let status = SecItemAdd(query as CFDictionary, nil)
    guard status == errSecSuccess else { throw KeychainError.unhandledError(status) }
}

Token discovery та NFT

Автопошук токенів через Etherscan, Covalent або Solana getParsedTokenAccountsByOwner. NFT — Alchemy NFT API з кешуванням IPFS metadata. Користувачеві не потрібно додавати токени вручну.

WalletConnect v2

Стандартний протокол зв'язку з dApp. Підпис транзакцій через eth_sendTransaction та personal_sign. Обробка сесій у background.

Стек та терміни

Таблиця компонентів
Компонент Технології Термін
Core HD wallet bip39 + ethers.js + @solana/web3.js 2–3 тижні
EVM multi-chain viem, 10+ мереж 2–3 тижні
Solana інтеграція @solana/web3.js + Metaplex 2 тижні
Mobile (RN) React Native + Expo SecureStore 4–6 тижнів
Extension (Chrome) MV3 + chrome.storage 3–4 тижні
WalletConnect v2 @walletconnect/web3wallet 1–2 тижні
NFT + token discovery Alchemy/Moralis API 2–3 тижні
UI/UX (повний) React Native / React 6–10 тижнів

Мінімальний production-ready мультичейн гаманець (EVM + Solana, mobile-first) — 4–5 місяців. Додавання Bitcoin (UTXO модель) — ще 4–6 тижнів. Розширення на Cosmos — 3–4 тижні через cosmjs. Вартість розраховується індивідуально, середній бюджет — від $80,000.

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

  • Архітектурна документація та вибір стеку
  • Реалізація HD-гаманця з BIP-44, BIP-39
  • Інтеграція 2+ мереж на вибір
  • Інтерфейс управління токенами та NFT
  • Підключення WalletConnect v2
  • Аудит смарт-контрактів (зовнішній або автоматизований)
  • Тестування на реальних пристроях
  • Передача вихідних кодів та інструкція з деплою
  • Підтримка протягом 30 днів після релізу

Перед публічним релізом обов'язковий зовнішній аудит — гаманець зберігає ключі користувачів безпосередньо. Ми маємо 10+ років досвіду в блокчейн-розробці, сертифіковані фахівці з безпеки та гарантія на код 12 місяців. Замовте розробку мультичейн гаманця з аудитом та підтримкою. Зв'яжіться з нами — оцінимо ваш проєкт за 2 дні. Отримайте консультацію з архітектури та термінів вже сьогодні.

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

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