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

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

Рітейловий кошелек управляє ключами однієї людини. Інституціональний кастодій управляє ключами від імені організації з багаторівневими політиками, аудит-логом, compliance вимогами й відповідальністю перед регуляторами. Це інший клас задач. MetaMask не підходить так само як Excel не підходить для банківського обліку.

Institutional custody охоплює: hedge funds, DAO treasury, крипто біржі (internal treasury), family offices, платіжні провайдери. Спільні вимоги: мультипартійна авторизація, розподіл обов'язків, апаратна ізоляція ключів, повний audit trail, policy enforcement on-chain й off-chain.

Ключові архітектурні рішення

MPC vs Multisig: принципова різниця

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

Multisig (Safe{Wallet} / Gnosis Safe): ключи існують як окремі приватні ключи кожного підписувача. Смарт-контракт вимагає M-of-N підписів для виконання транзакції. Всё on-chain, прозоро, аудируємо.

MPC Threshold Signature Scheme (TSS): єдиний приватний ключ ніколи не існує цілком в одному місці. Він генерується як N шардів через Distributed Key Generation (DKG), кожен шард зберігається окремо. Для підпису кожен шард бере участь у обчисленні, підсумкова підпис — стандартна ECDSA/EdDSA, невідрізнима від single-key. On-chain немає ознак мультипартійності.

Для EVM-only — Safe{Wallet} з кастомними модулями зручніше. Для мультичейн 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 — смарт-контракт, що валідує кожну транзакцію до виконання) або 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 — спеціалізованому апаратному пристрої, з якого приватний ключ ніколи не виходить в 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 інтеграція в кастодіальний стек:

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

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

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

Розподіл обов'язків

Принцип: той, хто ініціює транзакцію, не повинен мати можливість її одиноліч авторизувати. Не лише 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 пристрій (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 протокол без смени публічного ключа (адреси). Новий учасник отримує новий шард, старий знищується.

Cold Recovery Kit. Зашифрований backup на фізичних носіях у різних географічних локаціях. Розшифровка вимагає фізичної присутності кілька держателів.

Стек й інструменти

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

Аналітика й дизайн (2-3 тижні). Regulatory requirements конкретної юрисдикції, ролі й розподіл обов'язків, MPC vs multisig рішення, HSM вибір, travel rule обов'язки.

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 виконання.

Compliance й аудит (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.