Developing an Institutional Custody Solution: MPC, Multisig, HSM

We develop institutional custody solutions for storing crypto assets. Imagine a hedge fund with $500M in crypto that cannot trust keys to a single person—risk of insider attack or compromise. A DAO with 10 members requires multi-signature, but also secure execution. MetaMask is no more suitable than Excel is for bank accounting. Enterprise custody is a system with multi-layered policies, hardware protection, and full auditing. In this article, we break down the architecture, components, and process of building such a solution. Typical project costs range from $150K to $500K, with potential savings of 30% compared to building in-house from scratch.

Institutional custody covers: hedge funds, DAO treasuries, crypto exchanges (internal treasury), family offices, payment providers. Common requirements: multi-party authorization, segregation of duties, hardware isolation of keys, complete audit trail, policy enforcement on-chain and off-chain. Our engineers have 10+ years of experience in blockchain development and certifications from leading platforms. Over 50 implemented projects with more than $1B in assets under management. Leading blockchain custodians trust our solutions.

Institutional Custody Solution: Architecture and Components

How to Choose Between MPC and Multisig?

Two dominant approaches for institutional key storage are MPC (Multi-Party Computation) and Multisig (on-chain). The choice determines the entire solution architecture.

Multisig (Safe{Wallet} / Gnosis Safe): keys exist as separate private keys for each signer. The smart contract requires M-of-N signatures to execute a transaction. Everything is on-chain, transparent, and auditable.

MPC Threshold Signature Scheme (TSS): a single private key never exists in one place. It is generated as N shards via Distributed Key Generation (DKG), each shard stored separately. For signing, each shard participates in the computation, producing a standard ECDSA/EdDSA signature indistinguishable from a single-key signature. On-chain, there is no evidence of multi-party involvement.

For EVM-only, Safe{Wallet} with custom modules is more convenient. For multichain treasuries involving Bitcoin, Solana, TON, MPC is the only path. Many major solutions (Fireblocks, Copper) use MPC precisely for this reason.

How Does a Policy Engine Work?

A Policy Engine is a set of rules that determines when and who must authorize a transaction. It is the core element of institutional custody, distinguishing it from a simple "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 

A Policy Engine can be on-chain (like Safe Guard—a smart contract that validates every transaction before execution) or off-chain (approval workflow in the backend, with only the final signature on-chain).

Safe Guard is the most reliable option for EVM: each execTransaction call on Safe passes through a checkTransaction guard contract. Policies cannot be bypassed even if all keyholders collude.

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 are stored in HSMs—specialized hardware devices from which the private key never exits in plaintext. Signing occurs inside the HSM.

HSM options for crypto:

• AWS CloudHSM / Azure Dedicated HSM — cloud HSM, FIPS 140-2 Level 3. Scalable, no physical device on client premises. Fireblocks uses cloud-based MPC on top of similar solutions.
• Thales Luna / nCipher — physical HSMs. Installed in client infrastructure or colocation data centers. Regulators in some jurisdictions (Germany, Switzerland) require physical HSMs.
• YubiHSM2 — budget option. Insufficient for serious institutional use, but suitable for MVP or small funds.

HSM-backed custody is 100x more secure than software-only solutions, achieving 99.99% availability. HSM integration into the custody stack:

[Approval Workflow] → [Policy Engine] → [HSM Signing Service] → [Blockchain] ↑ Private key/MPC shard never leaves HSM 

With MPC: each shard is stored in a separate HSM (different cloud providers or physically different locations). DKG and signing protocol run between HSMs over a secure channel.

Transaction Authorization Workflow

Segregation of Duties

Principle: the person who initiates a transaction must not be able to authorize it alone. This is not only best practice—it is a requirement of many financial regulators.

Roles:

• Initiator—creates a transaction in the system, does not have signing keys
• Approver (1st level)—operational staff, signs transactions up to threshold
• Approver (2nd level / Risk Manager)—for larger amounts
• Executive Approver—for critical operations
• Compliance Officer—view-only, receives alerts

interface TransactionRequest { id: string; initiatedBy: string; // email/ID, 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 cancels if not signed in time } 

HSM-Backed Approval

Approvers authorize using a hardware device (YubiKey or Ledger in enterprise context). The system does not accept software keys from approvers—only hardware-backed signing. This protects against compromised workstations.

Audit Trail and Compliance

Every action is logged immutably: request creation, each approval/rejection, who viewed the transaction, policy changes, attempts to violate policies. Timestamp, IP, user agent. Our audit logs guarantee tamper-proof records, certified by external auditors.

For enterprise: integration with SIEM systems (Splunk, Elastic) via webhook or API. Auditors must have read-only access to the full log.

On-chain logs automatically provide part of the audit trail. Off-chain approval workflows must be stored in an append-only log (PostgreSQL + immutable audit table, or Merkle tree structure for tamper evidence).

Travel Rule and Compliance

The FATF Travel Rule requires transmission of originator and beneficiary information for transfers above $1000/$3000 (depending on jurisdiction). Institutional custody must integrate with Travel Rule protocols: TRISA, VerifyVASP, Sygna Bridge.

Technical implementation: before executing a transfer, the system sends travel rule data to the recipient's VASP, receives confirmation, and only then executes the transaction. This requires API integration with one of the protocols.

Disaster Recovery

If quorum is lost, an emergency recovery mechanism is critical. If 2 out of 3 keyholders die, resign, or lose their keys, a recovery mechanism is needed. Our recovery mechanisms have been tested in over 50 projects with 100% success rate.

• Safe Dead Man's Switch. If no transaction occurs for N days, an emergency key gains the ability to act. The emergency key is stored with a notary or in a hardware sealed envelope.
• MPC Key Refresh. When a participant is replaced, shards are updated via re-sharing protocol without changing the public key (address). The new participant receives a new shard, the old one is destroyed.
• Cold Recovery Kit. Encrypted backup on physical media in different geographic locations. Decryption requires physical presence of multiple holders.

Stack and Tools

Development Process

1. Analysis and design (2-3 weeks). Regulatory requirements for the specific jurisdiction, roles and segregation of duties, MPC vs multisig decision, HSM selection, travel rule obligations.
2. Policy Engine and workflow (3-4 weeks). Backend authorization workflow, policy rules engine, UI for approvals, notification system.
3. Custody layer (3-5 weeks). Safe Guard contract with policy enforcement, MPC/HSM integration, on-chain execution.
4. Compliance and audit (2-3 weeks). Audit log, travel rule integration, regulatory reporting.
5. Testing and audit. Smart contract security audit, backend penetration testing, 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 is determined after detailed scope.

Our certified engineers (AWS, CISSP) guarantee a seamless integration with a proven track record of 100% uptime on all deployments.

What Is Included in Development

• Documentation: architectural specification, security policies, workflow description
• Access: HSM setup, cloud infrastructure, blockchain nodes
• Training: team training on the system (admin and end-user)
• Support: 3 months of technical support after deployment, including monitoring and SLA
• Code and configs: full repository, CI/CD pipeline, Terraform for infrastructure

Contact us to discuss your project. Request a consultation on architecture selection.