Мы разрабатываем институциональные кастодиальные решения для хранения криптоактивов. Представьте: хедж-фонд с $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.
| Параметр | Multisig (Safe) | MPC (TSS) |
|---|---|---|
| On-chain privacy | Публичный M-of-N | Стандартная подпись, незаметно |
| Gas cost | Выше (contract call) | Стандартный (EOA-like) |
| Chain support | EVM-only нативно | Любая цепь (Bitcoin, Solana, TON) |
| Key recovery | Сложно без quorum | Возможен через key refresh |
| Smart contract risk | Есть (contract bugs) | Нет |
| Regulatory familiarity | Высокая (auditable) | Низкая (менее понятен аудиторам) |
Для 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 интеграции с одним из протоколов.
Подробнее о Travel Rule
После интеграции с TRISA или Sygna Bridge каждая транзакция сопровождается структурированными данными об отправителе и получателе. Система хранит эти данные в зашифрованном виде для последующего предоставления регуляторам.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 на физических носителях в разных географических локациях. Расшифровка требует физического присутствия нескольких держателей.
Стек и инструменты
| Компонент | Технологии |
|---|---|
| On-chain custody | Safe{Wallet} + Safe Guard + Safe Modules |
| MPC (если нужен) | Fireblocks SDK / Tss-lib (Binance) / ZenGo MPC |
| HSM интеграция | AWS CloudHSM SDK / PKCS#11 для физических HSM |
| Policy Engine | Кастомный backend (Node.js/Go) + Safe Guard (on-chain) |
| Approval workflow | React admin UI + WebSocket real-time notifications |
| Audit log | PostgreSQL + immutable audit table / Apache Kafka |
| Travel Rule | TRISA SDK / Notabene API |
| Notifications | Slack/Telegram bot + email для approvals |
Процесс разработки
- Аналитика и дизайн (2-3 недели). Regulatory requirements конкретной юрисдикции, роли и segregation of duties, MPC vs multisig decision, HSM выбор, travel rule obligations.
- Policy Engine и workflow (3-4 недели). Backend авторизационного workflow, policy rules engine, UI для approvals, notification система.
- Custody layer (3-5 недель). Safe Guard контракт с policy enforcement, MPC/HSM интеграция, on-chain execution.
- Compliance и audit (2-3 недели). Audit log, travel rule интеграция, reporting для регуляторов.
- Тестирование и аудит. 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 для инфраструктуры
Свяжитесь с нами для обсуждения вашего проекта. Закажите консультацию по выбору архитектуры.