Ми розробляємо інституційні кастодіальні рішення для зберігання криптоактивів. Уявіть: хедж-фонд із $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 млрд. Ми гарантуємо відповідність найвищим стандартам безпеки, включаючи сертифікацію FIPS 140-2 Level 3. Ми є провідним блокчейн-кастодіаном для інституційних клієнтів.
Інституційне кастодіальне рішення: архітектура та компоненти
Як вибрати між MPC та Multisig?
Два домінуючі підходи до зберігання institutional ключів — MPC (Multi-Party Computation) та Multisig (on-chain). Вибір між ними визначає всю архітектуру рішення. За нашими оцінками, MPC рішення на 40% економніше в експлуатації для multichain середовищ, ніж multisig, а також у 3 рази швидше розгортається.
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 саме з цієї причини. Наші рішення підтримують MPC мультипідпис для будь-яких блокчейнів, включаючи Bitcoin, Solana та TON.
Як працює 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. Ми маємо сертифікацію FIPS 140-2 Level 3 для 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 для відповідності регуляторам.
Технічна реалізація: перед виконанням переказу система надсилає 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. Ми гарантуємо безпеку вашого рішення.
Приклад з практики: хедж-фонд із $200M AUM
Для одного хедж-фонду з $200 млн активів під управлінням ми розробили кастодіальне рішення на базі Safe та MPC з апаратними ключами. До впровадження авторизація транзакцій займала близько 30 хвилин через ручне узгодження по email. Після інтеграції Policy Engine та approval workflow час скоротився до 2 хвилин, а операційні ризики зменшилися на 95%. Система забезпечила повну відповідність вимогам FINRA та SEC, включно з Travel Rule через Sygna Bridge. Цей приклад підтверджує наш досвід та гарантії якості.
Що входить у розробку
- Документація: архітектурна специфікація, політики безпеки, опис workflow
- Доступи: налаштування HSM, хмарної інфраструктури, blockchain nodes
- Навчання: тренінг для команди з роботи з системою (admin та end-user)
- Підтримка: 3 місяці технічної підтримки після деплою, включаючи моніторинг та SLA
- Код та конфіги: full repository, CI/CD pipeline, Terraform для інфраструктури
Зв'яжіться з нами для обговорення вашого проєкту. Замовте консультацію з вибору архітектури.