Разработка институционального кастодиального решения: MPC, Multisig, HSM

Мы разрабатываем институциональные кастодиальные решения для хранения криптоактивов. Представьте: хедж-фонд с $500 млн в крипте не может доверить ключи одному человеку — риск инсайдерской атаки или компрометации. DAO с 10 участниками требует мультиподписи, но безопасного исполнения. MetaMask не подходит так же, как Excel не подходит для банковского учёта. Институциональный кастодий — это система с многоуровневыми политиками, аппаратной защитой и полным аудитом. В этой статье мы разберём архитектуру, компоненты и процесс создания такого решения.

Institutional custody охватывает: hedge funds, DAO treasury, crypto exchanges (internal treasury), family offices, платёжные провайдеры. Общие требования: multi-party authorization, segregation of duties, hardware isolation ключей, полный audit trail, policy enforcement on-chain и off-chain. Наши инженеры имеют 10+ лет опыта в блокчейн-разработке и сертификаты от ведущих платформ. Более 50 реализованных проектов, активы под управлением на сумму свыше $1 млрд.

Институциональное кастодиальное решение: архитектура и компоненты

Как выбрать между MPC и Multisig?

Два доминирующих подхода к хранению institutional ключей — MPC (Multi-Party Computation) и Multisig (on-chain). Выбор между ними определяет всю архитектуру решения.

Multisig (Safe{Wallet} / Gnosis Safe): ключи существуют как отдельные private keys у каждого подписанта. Smart contract требует M-of-N подписей для исполнения транзакции. Всё on-chain, прозрачно, аудируемо.

MPC Threshold Signature Scheme (TSS): единый private key никогда не существует в одном месте. Он генерируется как N шардов через Distributed Key Generation (DKG), каждый шард хранится отдельно. Для подписи каждый шард участвует в вычислении, итоговая подпись — стандартная ECDSA/EdDSA, неотличимая от single-key. On-chain нет признаков multi-party.

Для EVM-only — Safe{Wallet} с кастомными modules удобнее. Для multichain treasury с Bitcoin, Solana, TON — MPC единственный путь. Многие крупные решения (Fireblocks, Copper) используют MPC именно по этой причине.

Как работает Policy Engine?

Policy Engine — набор правил, которые определяют, когда и кто должен авторизовать транзакцию. Это core элемент institutional custody, отличающий его от просто "мультисига".

Типичные правила:

IF transfer.amount < $10,000 AND transfer.asset IN [USDC, USDT] THEN require 1-of-3 (Trader role) IF transfer.amount >= $10,000 AND transfer.amount < $100,000 THEN require 1-of-3 (Trader) AND 1-of-2 (Risk Manager) IF transfer.amount >= $100,000 THEN require 2-of-3 (Executive) + time delay 4h + notification to Compliance IF transfer.destination NOT IN whitelist THEN BLOCK + alert to Security team 

Policy Engine может быть on-chain (как Safe Guard — smart contract, валидирующий каждую транзакцию до исполнения) или off-chain (approval workflow в backend, on-chain только финальная подпись).

Safe Guard — наиболее надёжный вариант для EVM: каждый вызов execTransaction в Safe проходит через checkTransaction guard-контракта. Политики невозможно обойти, даже если все keyholders договорились.

contract InstitutionalPolicyGuard is Guard { mapping(address => bool) public whitelistedRecipients; uint256 public largeTransferThreshold; uint256 public largeTransferDelay; mapping(bytes32 => uint256) public scheduledTransactions; function checkTransaction( address to, uint256 value, bytes memory data, Enum.Operation operation, uint256 safeTxGas, uint256 baseGas, uint256 gasPrice, address gasToken, address payable refundReceiver, bytes memory signatures, address msgSender ) external override { // Проверка whitelist require(whitelistedRecipients[to], "Recipient not whitelisted"); // Проверка large transfer delay if (value > largeTransferThreshold) { bytes32 txHash = keccak256(abi.encode(to, value, data)); require( scheduledTransactions[txHash] != 0 && block.timestamp >= scheduledTransactions[txHash] + largeTransferDelay, "Large transfer: timelock not expired" ); } } } 

Hardware Security Module (HSM) интеграция

В enterprise custody ключи или MPC шарды хранятся в HSM — специализированном аппаратном устройстве, из которого private key никогда не выходит в plaintext. Подпись происходит внутри HSM.

Варианты HSM для crypto:

• AWS CloudHSM / Azure Dedicated HSM — облачный HSM, FIPS 140-2 Level 3. Масштабируем, нет физического устройства у клиента. Fireblocks использует облачный MPC на базе подобных решений.
• Thales Luna / nCipher — физические HSM. Устанавливаются в клиентской инфраструктуре или colocation дата-центре. Регуляторы в ряде юрисдикций (Германия, Швейцария) требуют именно физический HSM.
• YubiHSM2 — бюджетный вариант. Недостаточен для серьёзного institutional, но подходит для MVP или малого фонда.

Интеграция HSM в кастодиальный stack:

[Approval Workflow] → [Policy Engine] → [HSM Signing Service] → [Blockchain] ↑ Private key/MPC shard никогда не покидает HSM 

При MPC: каждый шард хранится в отдельном HSM (разные облачные провайдеры или физически разные локации). DKG и signing protocol запускаются между HSM через secure channel.

Workflow авторизации транзакций

Segregation of Duties

Принцип: тот, кто инициирует транзакцию, не должен иметь возможности её единолично авторизовать. Это не только best practice — это требование многих финансовых регуляторов.

Роли:

• Initiator — создаёт транзакцию в системе, не имеет signing key
• Approver (1st level) — операционный сотрудник, подписывает транзакции до threshold
• Approver (2nd level / Risk Manager) — для крупных сумм
• Executive Approver — для критических операций
• Compliance Officer — только просмотр, получает алерты

interface TransactionRequest { id: string; initiatedBy: string; // email/ID, не имеет ключей to: string; value: bigint; asset: string; chain: string; businessJustification: string; requiredApprovals: ApprovalLevel[]; currentApprovals: Approval[]; status: 'pending' | 'approved' | 'rejected' | 'executed' | 'failed'; createdAt: Date; expiresAt: Date; // транзакция отменяется если не подписана вовремя } 

Approval через HSM-backed подпись

Approver авторизует через hardware device (YubiKey или Ledger в enterprise контексте). Система не принимает программные ключи от approver-ов — только hardware-backed подпись. Это защищает от скомпрометированного рабочего места.

Audit Trail и compliance

Каждое действие логируется неизменяемо: создание запроса, каждое одобрение/отклонение, кто смотрел транзакцию, изменения политик, попытки нарушить политику. Timestamp, IP, user agent.

Для enterprise: интеграция с SIEM системами (Splunk, Elastic) через webhook или API. Аудиторы должны иметь read-only доступ к полному журналу.

On-chain logs автоматически дают часть audit trail. Off-chain approval workflow нужно хранить в append-only log (PostgreSQL + immutable audit table, или Merkle tree структура для tamper evidence).

Travel Rule и compliance

FATF Travel Rule требует передачи информации об originator и beneficiary при переводах выше $1000/$3000 (в зависимости от юрисдикции). Institutional custody должен интегрироваться с Travel Rule протоколами: TRISA, VerifyVASP, Sygna Bridge.

Техническая реализация: перед исполнением перевода система отправляет travel rule data на VASP получателя, получает подтверждение, только потом исполняет транзакцию. Это требует API интеграции с одним из протоколов.

Disaster Recovery

При потере quorum критически важен emergency recovery механизм. Если 2 из 3 keyholders умерли, уволились или потеряли ключи — нужен emergency recovery механизм.

• Safe Dead Man's Switch. Если в течение N дней транзакции не происходит, emergency key получает возможность воздействовать. Emergency key хранится у нотариуса или в аппаратном sealed envelope.
• MPC Key Refresh. При замене участника шарды обновляются через re-sharing protocol без смены публичного ключа (адреса). Новый участник получает новый шард, старый уничтожается.
• Cold Recovery Kit. Зашифрованный backup на физических носителях в разных географических локациях. Расшифровка требует физического присутствия нескольких держателей.

Стек и инструменты

Процесс разработки

1. Аналитика и дизайн (2-3 недели). Regulatory requirements конкретной юрисдикции, роли и segregation of duties, MPC vs multisig decision, HSM выбор, travel rule obligations.
2. Policy Engine и workflow (3-4 недели). Backend авторизационного workflow, policy rules engine, UI для approvals, notification система.
3. Custody layer (3-5 недель). Safe Guard контракт с policy enforcement, MPC/HSM интеграция, on-chain execution.
4. Compliance и audit (2-3 недели). Audit log, travel rule интеграция, reporting для регуляторов.
5. Тестирование и аудит. Security audit контракта, penetration testing backend, disaster recovery drill.

MVP (Safe + базовый approval workflow без HSM) — 8-12 недель. Полное institutional решение с MPC, HSM, travel rule, compliance reporting — 5-8 месяцев. Стоимость рассчитывается после детального scope.

Что входит в разработку

• Документация: архитектурная спецификация, политики безопасности, описание workflow
• Доступы: настройка HSM, cloud инфраструктуры, blockchain nodes
• Обучение: тренинг для команды по работе с системой (admin и end-user)
• Поддержка: 3 месяца технической поддержки после деплоя, включая мониторинг и SLA
• Код и конфиги: full repository, CI/CD pipeline, Terraform для инфраструктуры

Свяжитесь с нами для обсуждения вашего проекта. Закажите консультацию по выбору архитектуры.