Розробка кастодіального мобільного криптокошелька
У кастодіальному кошельку приватні ключі користувачів зберігаються на стороні оператора. Це фундаментальне розрізнення від некастодіального: користувач довіряє оператору управління своїми активами, оператор бере на себе відповідальність за безпеку. Саме таку модель використовують більшість централізованих бірж (Coinbase, Binance) та корпоративних крипто-рішень.
Технічно простіше для користувача — не потрібно берегти seed-фразу, звичне відновлення через email. Але вимоги до безпеки серверної інфраструктури та регуляторне навантаження — несвідомість вищі.
Архітектура зберігання ключів
Зберігання приватних ключів користувачів у звичайній базі даних — це вирок при першому ж взломі. Правильна архітектура:
HSM (Hardware Security Module). Фізичний пристрій, який генерує, зберігає та використовує ключі — вони ніколи не виходять за межі HSM. Підписання транзакцій відбувається всередині HSM: програма відправляє транзакцію, HSM повертає підписану транзакцію, ключ не експортується. Популярні рішення: Thales Luna, AWS CloudHSM, Azure Dedicated HSM.
KMS (Key Management Service). Хмарний аналог: AWS KMS, Google Cloud KMS, Azure Key Vault. Ключи не експортуються, операції підписання через API. Дешевше HSM, простіше масштабується, але ключі в хмарі провайдера — регуляторні обмеження для деяких юрисдикцій.
MPC (Multi-Party Computation). Сучасний підхід: приватний ключ ніколи не існує цілком в одному місці. Кілька учасників (серверні вузли) мають шарди ключа, підписання відбувається через MPC-протокол без реконструкції ключа. Стійко до компрометації одного вузла. Fireblocks, Fordefi, ZenGo використовують цей підхід.
Схема холодного/гарячого зберігання. Більшість коштів — у холодному сховище (offline HSM, hardware wallets). Гарячий кошелек (online) — тільки операційний запас для обробки поточних виводів. Співвідношення 95/5 або 98/2 — стандарт відрасті для бірж.
Серверна архітектура транзакцій
Клієнтська програма не підписує транзакції — тільки ініціює запит. Потік:
- Користувач вводить параметри виводу в мобільній програмі
- Програма відправляє запит на бекенд з аутентифікацією (JWT + 2FA)
- Бекенд валідує: достатньо коштів, не перевищені ліміти, адреса у whitelist
- Запит ставиться у чергу на підписання (не автоматично — може вимагати ручної або автоматичної апробації)
- Signing service запитує HSM/KMS підписати транзакцію
- Підписана транзакція уходит на blockchain-ноду
- Мониторинг підтвердження, повідомлення користувачу
Черга транзакцій — не просто async processing. Це захист від паралельних атак: два запити на вивід одного балансу не повинні обидва пройти. Оптимістична або песимістична блокування на рівні акаунту при ініціації виводу.
Облік: UTXO проти account-based
Для мереж, сумісних з Ethereum — account-based модель. Один адрес на користувача або пулу адресів з маппінгом:
- Dedicated address: кожен користувач отримує унікальну адресу депозиту → простіша ідентифікація вхідних, дороговартісна в газу при консолідації
- Shared address + memo/tag: один адрес депозиту, ідентифікація через memo (як XRP, TON) або calldata
Для Bitcoin — UTXO. Кожен UTXO належить конкретному користувачу або вимагає адресно-трансакційного маппінгу. Конкретна адреса Bitcoin для кожного депозиту, sweep UTXO на холодний кошелек за розписанням.
Внутрішня база обліку повинна давати миттєві баланси без blockchain-запиту. Всі операції — у внутрішній БД, blockchain — фінальне підтвердження. Як у банку: внутрішня бухгалтерська система не чекає Fedwire для кожного запиту балансу.
Мобільний клієнт: особливості кастодіальної моделі
Для користувача кастодіальний кошелек ближче до банківської програми, ніж до MetaMask. Функціональність:
- Реєстрація/логін з KYC (якщо вимагає регулятор)
- Баланси по активам у реальному часі (WebSocket для live updates)
- Історія транзакцій з фільтрами
- Відправка (з адресною книгою, QR-сканером, whitelist адресів)
- Отримання (QR з адресою, мониторинг вхідних)
- Swap між активами (через внутрішній мотор або агрегатор)
Біометрична аутентифікація на пристрої — для підтвердження операцій, але сам ключ вона не захищає (ключи на сервері). Тут біометрія захищає сесію програми.
KYC та AML — регуляторна обов'язок
Кастодіальний кошелек у більшості юрисдикцій — фінансовий сервіс. VASP (Virtual Asset Service Provider) за FATF Recommendations. Це означає:
- KYC (Know Your Customer): верифікація особистості, документи, selfie liveness check. Інтеграція з провайдерами: Sumsub, Onfido, Jumio, Veriff
- AML screening: перевірка транзакцій проти санкційних списків (OFAC, EU), блокування відомих миксерів та darknet адресів. Провайдери: Chainalysis, Elliptic, TRM Labs
- Travel Rule (FATF Recommendation 16): при переводах > $1000 потрібно передавати дані відправника/одержувача між VASP. Протоколи: TRP, OpenVASP, TRISA
Без цього в ЄС, США, більшості розвинених країнах — неможливо законно працювати. Інтеграція KYC/AML — обов'язковий етап, не опціональний.
Push-повідомлення та мониторинг
Мониторинг вхідних транзакцій — через webhook від blockchain-провайдера (Alchemy Webhooks, Moralis Streams, QuickNode Streams) або власний event listener. При підтвердженні депозиту — зарахувати на внутрішній баланс, відправити push через FCM/APNs.
Повідомлення про підозрілу активність: вхід з нового пристрою, вивід великої суми, зміна email — негайний push + email.
Етапи та часова шкала
MVP кастодіального кошелька (один блокчейн, базові операції, KMS замість HSM, спрощений KYC) — 2–3 місяці. Повноцінна система з HSM/MPC, мультичейн підтримкою, AML інтеграцією, регуляторною звітністю — 6–12 місяців командою. Регуляторна частина (отримання ліцензії VASP) — паралельний процес, сроки залежать від юрисдикції. Вартість рассчітується після аналізу вимог: кількість блокчейнів, юрисдикцій, обсяг KYC/AML, вимоги до інфраструктури безпеки.