Institutional Custody Solution Development
Retail wallet manages keys for one person. Institutional custodian manages keys on behalf of organization with multi-level policies, audit log, compliance requirements, and responsibility to regulators. This is different class of problems. MetaMask doesn't fit like Excel doesn't fit banking accounting.
Institutional custody covers: hedge funds, DAO treasury, crypto exchanges (internal treasury), family offices, payment providers. Common requirements: multi-party authorization, segregation of duties, hardware key isolation, complete audit trail, policy enforcement on-chain and off-chain.
Key Architectural Decisions
MPC vs Multisig: Fundamental Difference
Two dominant approaches to institutional key storage — MPC (Multi-Party Computation) and Multisig (on-chain). Choice between them determines entire solution architecture.
Multisig (Safe{Wallet} / Gnosis Safe): keys exist as separate private keys held by each signer. Smart contract requires M-of-N signatures for transaction execution. All on-chain, transparent, auditable.
MPC Threshold Signature Scheme (TSS): single private key never exists wholly in one place. Generated as N shards via Distributed Key Generation (DKG), each shard stored separately. For signing each shard participates in computation, resulting signature is standard ECDSA/EdDSA, indistinguishable from single-key. On-chain no indication of multi-party.
| Parameter | Multisig (Safe) | MPC (TSS) |
|---|---|---|
| On-chain privacy | Public M-of-N | Standard signature, unnoticed |
| Gas cost | Higher (contract call) | Standard (EOA-like) |
| Chain support | EVM-only natively | Any chain (Bitcoin, Solana, TON) |
| Key recovery | Difficult without quorum | Possible via key refresh |
| Smart contract risk | Yes (contract bugs) | No |
| Regulatory familiarity | High (auditable) | Low (less understood by auditors) |
For EVM-only — Safe{Wallet} with custom modules more convenient. For multichain treasury with Bitcoin, Solana, TON — MPC only path. Many large solutions (Fireblocks, Copper) use MPC for this reason.
Policy Engine
Policy Engine is set of rules determining when and who must authorize transaction. This is core element of institutional custody, distinguishing it from just "multisig."
Typical rules:
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 can be on-chain (like Safe Guard — smart contract validating each transaction before execution) or off-chain (approval workflow in backend, on-chain only final signature).
Safe Guard — most reliable option for EVM: each execTransaction call in Safe passes through checkTransaction guard-contract. Policies impossible to bypass even if all keyholders agreed.
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 check
require(whitelistedRecipients[to], "Recipient not whitelisted");
// Large transfer delay check
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) Integration
In enterprise custody keys or MPC shards stored in HSM — specialized hardware device from which private key never exits in plaintext. Signing happens inside HSM.
HSM options for crypto:
AWS CloudHSM / Azure Dedicated HSM — cloud HSM, FIPS 140-2 Level 3. Scalable, no physical device at customer. Fireblocks uses cloud MPC based on similar solutions.
Thales Luna / nCipher — physical HSM. Installed in customer infrastructure or colocation data center. Regulators in some jurisdictions (Germany, Switzerland) require physical HSM.
YubiHSM2 — budget option ($650). Insufficient for serious institutional but suitable for MVP or small fund.
HSM integration into custody stack:
[Approval Workflow] → [Policy Engine] → [HSM Signing Service] → [Blockchain]
↑
Private key/MPC shard never leaves HSM
With MPC: each shard stored in separate HSM (different cloud providers or physically different locations). DKG and signing protocol run between HSMs via secure channel.
Transaction Authorization Workflow
Segregation of Duties
Principle: person initiating transaction shouldn't be able to authorize it alone. Not only best practice — requirement of many financial regulators.
Roles:
- Initiator — creates transaction in system, has no signing key
- Approver (1st level) — operations person, signs transactions below threshold
- Approver (2nd level / Risk Manager) — for large amounts
- Executive Approver — for critical operations
- Compliance Officer — view only, receives alerts
interface TransactionRequest {
id: string;
initiatedBy: string; // email/ID, has no keys
to: string;
value: bigint;
asset: string;
chain: string;
businessJustification: string;
requiredApprovals: ApprovalLevel[];
currentApprovals: Approval[];
status: 'pending' | 'approved' | 'rejected' | 'executed' | 'failed';
createdAt: Date;
expiresAt: Date; // transaction cancelled if not signed in time
}
Approval via HSM-backed Signature
Approver authorizes via hardware device (YubiKey or Ledger in enterprise context). System doesn't accept software keys from approvers — only hardware-backed signature. Protects from compromised workstation.
Audit Trail and Compliance
Every action logged immutably: request creation, each approval/rejection, who viewed transaction, policy changes, policy violation attempts. Timestamp, IP, user agent.
For enterprise: SIEM system integration (Splunk, Elastic) via webhook or API. Auditors must have read-only access to complete log.
On-chain logs automatically provide part of audit trail. Off-chain approval workflow needs append-only log storage (PostgreSQL + immutable audit table, or Merkle tree structure for tamper evidence).
Travel Rule and Compliance
FATF Travel Rule requires transmission of originator and beneficiary info on transfers above $1000/$3000 (depending on jurisdiction). Institutional custody must integrate with Travel Rule protocols: TRISA, VerifyVASP, Sygna Bridge.
Technical implementation: before executing transfer system sends travel rule data to receiver's VASP, receives confirmation, only then executes transaction. Requires API integration with one of protocols.
Disaster Recovery
What happens if quorum lost? If 2 of 3 keyholders died, quit, or lost keys — need emergency recovery mechanism.
Safe Dead Man's Switch. If no transactions happen for N days, emergency key gets ability to take action. Emergency key stored with notary or in hardware sealed envelope.
MPC Key Refresh. On participant replacement shards updated via re-sharing protocol without changing public key (address). New participant gets new shard, old destroyed.
Cold Recovery Kit. Encrypted backup on physical media in different geographic locations. Decryption requires physical presence of multiple holders.
Stack and Tools
| Component | Technologies |
|---|---|
| On-chain custody | Safe{Wallet} + Safe Guard + Safe Modules |
| MPC (if needed) | Fireblocks SDK / Tss-lib (Binance) / ZenGo MPC |
| HSM integration | AWS CloudHSM SDK / PKCS#11 for physical HSM |
| Policy Engine | Custom 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 for approvals |
Development Process
Analytics and Design (2-3 weeks). Regulatory requirements of specific jurisdiction, roles and segregation of duties, MPC vs multisig decision, HSM choice, travel rule obligations.
Policy Engine and Workflow (3-4 weeks). Authorization workflow backend, policy rules engine, approval UI, notification system.
Custody Layer (3-5 weeks). Safe Guard contract with policy enforcement, MPC/HSM integration, on-chain execution.
Compliance and Audit (2-3 weeks). Audit log, travel rule integration, reporting for regulators.
Testing and Audit. Security audit of contract, penetration testing backend, disaster recovery drill.
MVP (Safe + basic approval workflow without HSM) — 8-12 weeks. Full institutional solution with MPC, HSM, travel rule, compliance reporting — 5-8 months. Cost calculated after detailed scope.







