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

Представьте: у кастодиана миллионы клиентов, все активы в одном горячем кошельке. При банкротстве — суды, клиенты не могут доказать свои доли. По данным 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% случаев.