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

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

Розничный кошелёк управляет ключами одного человека. Институциональный кастодий управляет ключами от имени организации с многоуровневыми policy, аудит-логом, compliance требованиями и ответственностью перед регуляторами. Это другой класс задач. 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.

Ключевые архитектурные решения

MPC vs 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 — бюджетный вариант ($650). Недостаточен для серьёзного 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? Если 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 на физических носителях в разных географических локациях. Расшифровка требует физического присутствия нескольких держателей.

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

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

Аналитика и дизайн (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.