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

Уявіть: у кастодіана мільйони клієнтів, всі активи в одному гарячому гаманці. При банкрутстві — суди, клієнти не можуть довести свої частки. За даними 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% випадків.