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

Уявіть: у кастодіана мільйони клієнтів, всі активи в одному гарячому гаманці. При банкрутстві — суди, клієнти не можуть довести свої частки. За даними Chainalysis, втрати від подібних інцидентів сягають $2 млрд на рік. Знайома ситуація? Ми розробляємо кастодіальні системи зі строгою сегрегацією активів, щоб такого не сталося. Кожен клієнт бачить свої кошти на унікальній адресі або в зашифрованому обліку. За 20+ проєктів накопичили досвід, який дозволяє зробити систему надійною та прохідною для аудиту.

Отримайте консультацію інженера — оцінимо проєкт за 2 дні.

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

Регулятори (MiCA в EU, FCA в UK) прямо вимагають відокремлення клієнтських активів від власних. Згідно з Article 36 of MiCA Regulation, кастодіани зобов'язані забезпечувати сегрегацію активів. Для крипто-кастодіанів у США поки немає єдиного стандарту, але BitLicense вже містить вимоги до сегрегації. Аудитор у будь-який момент повинен зіставити on-chain адреси із записами про клієнтів — активи клієнта A не повинні бути перемішані з активами клієнта B. Порушення веде до втрати ліцензії та судових позовів.

Архітектурні моделі: порівняння — розробка системи сегрегації

Гібридна модель забезпечує баланс безпеки та витрат у 3 рази ефективніше за чисто віртуальну. Для великих клієнтів — виділені адреси, для роздрібних — віртуальна сегрегація з можливістю переходу на dedicated address за запитом. Зниження operational costs на 30-40% порівняно з повною сегрегацією.

Як влаштована система сегрегації активів?

Повна сегрегація (Full Segregation)

Кожен клієнт отримує унікальну on-chain адресу (або набір — по одній на кожен blockchain). Активи фізично розділені на рівні блокчейну. Це максимальна прозорість для клієнта та аудитора, простий доказ права власності та ізоляція ризиків. Недолік — високі operational costs при великій кількості клієнтів.

Управління адресами

Ключі зберігаються в HSM. Адреси генеруються детерміновано через HD-derivation:

m/44'/60'/{clientId}'/0/0 → основна адреса клієнта
m/44'/60'/{clientId}'/0/1 → адреса для конкретного активу
m/44'/60'/{clientId}'/1/0 → change адреса

Це дозволяє відновити всі адреси з master seed без додаткового сховища.

Бухгалтерський облік (Ledger)

Подвійний запис обов'язковий. Кожен рух активів балансується:

CREATE TABLE ledger_entries (
    id BIGSERIAL PRIMARY KEY,
    entry_type VARCHAR(32) NOT NULL,
    client_id UUID NOT NULL REFERENCES clients(id),
    asset VARCHAR(64) NOT NULL,
    blockchain VARCHAR(32) NOT NULL,
    amount NUMERIC(36, 18) NOT NULL CHECK (amount > 0),
    balance_after NUMERIC(36, 18) NOT NULL,
    reference_type VARCHAR(32),
    reference_id UUID,
    tx_hash VARCHAR(66),
    block_number BIGINT,
    created_at TIMESTAMPTZ DEFAULT NOW() NOT NULL,
    created_by VARCHAR(64) NOT NULL,
    CONSTRAINT no_negative_balance CHECK (balance_after >= 0)
);

Reconciliation — щоденна звірка on-chain балансів із записами в ledger. Якщо розбіжність перевищує допустимий поріг (0.1% від загального балансу), система надсилає alert.

Моніторинг вхідних депозитів

Система відстежує всі вхідні транзакції на адреси клієнтів через WebSocket-підписку на нові блоки. Для ERC-20 відстежуються Transfer події. Після підтвердження (12-20 блоків) кошти зараховуються в ledger. Обробляємо до 10 000 депозитів на годину на один blockchain.

Виведення коштів

Виведення вимагає multi-approval workflow. Після схвалення: перевірка балансу, резервування, підпис в HSM, broadcast, очікування підтвердження (6-12 блоків), фінальне списання. Кожен запит має унікальний idempotency key — повтор із тим самим ключем не створює нове виведення.

Як реалізувати Proof of Reserves?

Для публічного підтвердження платоспроможності будуємо Merkle tree на основі client balances:

async function generateProofOfReserves(): Promise<ProofOfReserves> {
  const balances = await db.getAllClientBalances();
  const leaves = balances.map(b => 
    keccak256(encode(['address', 'uint256'], [b.address, b.balance]))
  );
  const tree = new MerkleTree(leaves, keccak256, { sort: true });
  await proofOfReservesContract.updateRoot(tree.getRoot());
  return {
    root: tree.getRoot(),
    totalBalance: balances.reduce((sum, b) => sum + b.balance, 0n),
    timestamp: Date.now(),
    proofs: balances.map((b, i) => ({
      clientId: b.clientId,
      proof: tree.getProof(leaves[i]),
    })),
  };
}

Кожен клієнт отримує доказ включення свого балансу в дерево без розкриття даних інших клієнтів. Корінь публікується on-chain, що дозволяє проводити незалежний аудит. Гарантуємо прохідність аудиту в 99.9% випадків.

Compliance, аудит та звітність

Audit trail — всі операції з незмінною історією. Логи зберігаються в append-only сховищі (PostgreSQL з audit triggers або AWS QLDB). Щомісячні звіти для клієнтів, щоквартальні для аудиторів: reconciliation reports, proof of reserves.

KYT (Know Your Transaction) — інтеграція з Chainalysis Reactor API для перевірки вхідних транзакцій на зв'язок із санкційними адресами та mixer-ами. Це обов'язкова вимога для проходження compliance-перевірок.

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

1. Архітектурна документація (HLD, LLD, ER-діаграми)
2. Вихідний код системи (ledger, моніторинг, API, адміністрування)
3. HSM-конфігурації та політики доступу
4. CI/CD пайплайни (GitHub Actions + Docker)
5. Тести безпеки (penetration testing, smart contract audit)
6. Навчання команди (2 тижні)
7. Підтримка 3 місяці після запуску

Стек технологій

Терміни та вартість

• Core ledger + address management: 6–8 тижнів
• Deposit monitoring + withdrawal flow: 4–6 тижнів
• Reconciliation + proof of reserves: 3–4 тижні
• KYT інтеграція + compliance reporting: 3–4 тижні
• Security audit: обов'язковий, 4–8 тижнів

Оцінимо ваш проєкт за 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 місяць

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

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

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