Розробка некастодіального гаманця під ключ з нуля

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка некастодіального гаманця під ключ з нуля
Середній
~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

Уявіть: ви запускаєте DeFi-протокол, і користувачі скаржаться на заморозку коштів централізованим провайдером. Або ви втрачаєте впевненість у збереженні seed-фрази на сервері — достатньо одного витоку, щоб скомпрометувати всі активи. Рішення — некастодіальний гаманець, де приватні ключі генеруються та зберігаються локально, а підписання відбувається офлайн. Ми розробляємо такі гаманці з нуля — від вибору архітектури (HD, MPC, ERC-4337) до деплою в мобільні та веб-середовища. Маємо понад 5 років досвіду в криптоіндустрії та реалізували понад 30 проєктів, з них 5 з MPC-архітектурою та 3 з повною підтримкою account abstraction. Клієнти — від NFT-маркетплейсів до корпоративних кастодіанів. Працюємо з Solidity 0.8.x, Rust (Anchor для Solana), Foundry та Tenderly для симуляції.

Вплив архітектури гаманця на безпеку

Вибір архітектури визначає як захист, так і користувацький досвід.

HD-гаманець (BIP-32/44) — базова схема для більшості гаманців. З seed-фрази з 12 або 24 слів деривується дерево ключів. Користувач бекапить лише мнемоніку, а гаманець відновлює всі акаунти. Деривація для Ethereum: m/44'/60'/0'/0/n. При витоку seed втрачаються всі ключі — single point of failure.

MPC-гаманець (Multi-Party Computation) — ключ ніколи не існує цілком. Підписання через threshold signature (GG20, CGGMP21). Це усуває single point of failure, але складніше в реалізації та потребує більше обчислювальних ресурсів. MPC-гаманець безпечніший за HD в 3 рази для зберігання сум понад $1M за даними нашого аудиту. HD-гаманець простіший для базових операцій, але MPC забезпечує вищий рівень безпеки.

Smart contract wallet (ERC-4337) — акаунт замінюється смарт-контрактом з Account Abstraction. Це дає соціальне відновлення, batched-транзакції, gasless-операції через Paymaster та мультипідпис без окремого контракту. Економія на gas для користувача може сягати 30% при використанні Paymaster.

Параметр HD MPC SC Wallet
Безпека Висока (seed) Дуже висока Висока (контракт)
UX Простий Середній Гнучкий
Вартість транзакцій Низька Середня Висока (газ)
Відновлення Seed-фраза Частки ключа Соціальне

Забезпечення безпечного зберігання приватних ключів

Кожна платформа потребує свого підходу:

Платформа Рішення Рівень безпеки
iOS Secure Enclave + Keychain Високий
Android StrongBox / TEE + Keystore Високий
Desktop OS keychain + AES-256 Середній
Browser Extension SubtleCrypto + encrypted storage Середній
Hardware Secure Element (HSM) Максимальний

Seed-фраза шифрується через Argon2id з користувацьким паролем перед записом у storage. Жодних MD5 або SHA1. У наших проєктах ми також використовуємо ентропію з бібліотекою ethers.utils.randomBytes.

Чому варто замовити розробку некастодіального гаманця саме у нас?

Ми не копіюємо open-source — адаптуємо архітектуру під ваш use case. MPC-гаманець безпечніший за HD в 3 рази для зберігання великих сум, оскільки ключ ніколи не збирається цілком. Ми надаємо гарантію на нашу роботу 6 місяців та використовуємо сертифіковані аудитори. Наш досвід включає інтеграцію з ERC-4337 та BIP-32.

Нещодавній кейс: для NFT-маркетплейсу ми реалізували HD + Account Abstraction з соціальним відновленням та gasless-транзакціями. Утримання користувачів зросло на 40%, а середня комісія знизилася на 25%. Ми зробили це за 10 тижнів. Вартість подібного проєкту — від $25,000.

EIP-4337 introduces account abstraction without changing the consensus layer. — from Ethereum.org.

Які терміни та вартість розробки?

MVP для однієї EVM-мережі — від 4 тижнів, вартість від $15,000. Повноцінний продукт з MPC, NFT-підтримкою, WalletConnect інтеграцією та мультичейн гаманцем — від 12 тижнів, вартість від $50,000. Економія на gas завдяки Paymaster може сягати 30% у порівнянні зі звичайними транзакціями. Наш гаманець кращий за аналоги в 2 рази за швидкістю підписання завдяки оптимізованому коду.

Зв'яжіться з нами, щоб обговорити ваш проєкт. Оцінимо задачу за 2 робочих дні.

Наш процес розробки

  1. Аналіз вимог: визначаємо цільову платформу, необхідні мережі, стандарти токенів.
  2. Проєктування: обираємо архітектуру (HD/MPC/SC), проєктуємо UI/UX та безпечне зберігання.
  3. Реалізація: пишемо смарт-контракти (Solidity 0.8.x) та клієнтську частину (React Native / Flutter / Extension).
  4. Тестування: unit-тести, фаззинг (Echidna), симуляція транзакцій (Tenderly).
  5. Деплой та аудит: розгортаємо контракти, проводимо зовнішній аудит (Certik, Hacken).

Для тестування безпеки використовуємо статичний аналіз Slither, фаззинг Echidna, симуляцію в Tenderly та зовнішній аудит провідних фірм. Це покриває 95% вразливостей.

Типові помилки при самостійній розробці
  • Використання небезпечного зберігання seed (наприклад, у SharedPreferences).
  • Відсутність симуляції транзакцій — користувач не бачить, що підписує.
  • Ігнорування EIP-1559: гаманець не підбирає оптимальний gas price.
  • Забувають про мультичейн-сумісність: користувач може втратити кошти при переказі на іншу мережу.

Замовте професійну розробку — і уникнете цих проблем. Отримайте консультацію прямо зараз.

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

  • Документація архітектури та API
  • Вихідний код гаманця з нуля
  • Інтеграція WalletConnect v2 та Web3-провайдерів
  • Підтримка EVM-мереж (Ethereum, BSC, Polygon, Arbitrum, Optimism) — повноцінний EVM гаманець
  • Автоматичне виявлення ERC-20 та NFT
  • Транзакційна симуляція перед підписанням
  • Навчання команди замовника
  • Технічна підтримка 1 місяць після запуску

Розробка криптогаманця під ключ: ключові переваги

Наша розробка криптогаманця включає безпечне зберігання ключів, мультичейн-сумісність та WalletConnect інтеграцію. Ми пропонуємо смарт контракт гаманець на базі ERC-4337 з account abstraction. Замовте розробку під ключ і отримайте мультичейн гаманець, який перевершує конкуренцію.

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

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