Designing Institutional-Grade
Custody Architecture

Before evaluating any custody technology, a firm must specify what it is defending against. The threat landscape for institutional digital asset custody is broader than it first appears, and different custody architectures optimise for different subsets of it.

The first architectural decision is whether multi-party control of assets will be implemented via threshold signature schemes (TSS), a cryptographic technique, or on-chain multisig, a smart contract or protocol-level construct.

The institutional consensus has moved decisively toward TSS/MPC for most use cases. The combination of no single point of cryptographic failure, chain-agnosticism, and on-chain indistinguishability makes it the superior architecture for firms managing diverse asset portfolios under regulatory scrutiny.

The cryptographic engine underneath modern institutional MPC custody is typically an implementation of MPC-CMP (Multi-Party Computation for ECDSA, CMP variant), published by Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyannis, and Udi Peled in 2020. MPC-CMP replaced earlier ECDSA threshold protocols that required a preprocessing round and were vulnerable to certain abort attacks.

Key Generation (Distributed Key Generation — DKG)

The protocol begins with distributed key generation: a process by which n parties jointly compute a public key and receive individual secret shares — without any party or external coordinator ever seeing the full private key. The DKG procedure in MPC-CMP uses Feldman's verifiable secret sharing, ensuring that each party's share is consistent with the others and that the resulting public key is verifiable without revealing the private key.

// n parties jointly generate keypair. No party sees sk.
// Feldman VSS + Schnorr commitment scheme

Round 1  →  Each party Pᵢ samples secret sᵢ ← ℤₙ
           Commits to polynomial fᵢ(x) where fᵢ(0) = sᵢ
           Broadcasts Pedersen commitment Cᵢ + Schnorr proof

Round 2  →  Each Pᵢ sends share fᵢ(j) to party Pⱼ (encrypted)
           Parties verify shares against commitments
           Abort if verification fails → reshare with honest parties

Output   →  Party Pᵢ holds secret share xᵢ = Σⱼ fⱼ(i) mod n
           Public key pk = g^(Σ xᵢ) is known to all
           sk = Σ xᵢ is NEVER assembled by any party

Threshold Signing — The CMP Improvement

The signing protocol in MPC-CMP achieves ECDSA threshold signing in 4 rounds (reduced from earlier protocols requiring preprocessing). The key innovation is the use of Paillier encryption for the randomness multiplication step — the part of ECDSA generation that previously required either a trusted dealer or expensive zero-knowledge proofs.

// t parties (of n) sign message m without exposing key shares
// Paillier homomorphic encryption used for nonce multiplication

Round 1  →  Each signer samples nonce share kᵢ, γᵢ ← ℤₙ
           Broadcasts Paillier encryption: Enc(kᵢ), Enc(γᵢ)
           Commits to elliptic curve points Γᵢ = γᵢ·G

Round 2  →  Parties compute MtA (Multiplicative-to-Additive) shares
           kᵢ · γⱼ computed via Paillier without revealing kᵢ or γⱼ
           ZK proofs verify correct Paillier computation

Round 3  →  Parties reveal Γᵢ, compute R = k⁻¹·G
           Each party computes partial signature σᵢ
           Broadcasts σᵢ with ZK consistency proof

Output   →  Any party aggregates: σ = Σ σᵢ mod n
           ECDSA signature (r, s) is valid for pk over m
           No party's key share xᵢ was ever revealed

Proactive Secret Sharing and Key Refresh

MPC-CMP supports proactive secret sharing: periodic refresh of all key shares such that the new shares are mathematically unrelated to the old ones (while the underlying key remains unchanged). This is critical for institutional security: key shares exfiltrated before a refresh are useless after it. Production systems should run proactive refresh on a schedule — daily or weekly for hot wallets, monthly for warm, on-demand for cold.

MPC alone is a cryptographic protocol running on general-purpose compute. Without hardware roots of trust, the security boundary of each MPC node extends to the entire software stack — operating system, hypervisor, cloud provider infrastructure, and every library in the dependency chain. Hardware Security Modules (HSMs) establish a hardware-enforced boundary within which key material cannot be extracted regardless of software compromise.

HSM Selection Criteria for MPC Nodes

Not all HSMs are equal, and the MPC use case creates specific requirements that differ from traditional HSM deployments:

The key ceremony — the procedure by which the distributed key generation protocol is executed to create a new custody key — is the single most consequential operational event in a custody firm's lifecycle. A ceremony executed correctly creates a key whose security is mathematically guaranteed by the MPC protocol. A ceremony with procedural flaws can create attack vectors that persist for the lifetime of the key.

Disaster recovery in custody is not a single procedure — it is a tiered set of procedures corresponding to failure scenarios of different severity. A firm that plans only for "one node goes down" has not planned for disaster recovery. True DR planning must include scenarios that no individual within the organisation wants to contemplate: simultaneous destruction of multiple facilities, death or incapacitation of key personnel, catastrophic infrastructure failure, and hostile legal actions in multiple jurisdictions.

Fireblocks represents the dominant institutional MPC custody infrastructure provider, with over 1,800 institutional clients and $4 trillion in annualised transfer volume. Its architecture makes specific engineering choices that reflect its target market — active trading institutions requiring high-throughput, low-latency signing across hundreds of blockchains.

The MPC-CMP Implementation

Fireblocks implements MPC-CMP with a 2-of-3 default threshold scheme: one share held by the Fireblocks cloud infrastructure, one by the client's mobile device (protected by the device's secure enclave), and one in cold backup storage. This design creates a specific security model: any signing operation requires Fireblocks infrastructure cooperation, which is simultaneously its primary security guarantee and its primary regulatory concern.

Intel SGX as Software HSM

Fireblocks uses Intel SGX (Software Guard Extensions) as the hardware root of trust for its cloud-hosted key share, rather than traditional HSMs. SGX enclaves provide memory encryption and attestation — code running inside an enclave cannot be inspected by the host OS, hypervisor, or cloud provider. This is a pragmatic choice for a cloud-native architecture.

The tradeoff is that SGX has a documented history of side-channel vulnerabilities (Spectre, Meltdown, Plundervolt, SGAxe) that have periodically allowed enclave memory to be read by local attackers. Fireblocks mitigates this through SGX mitigations, regular patching, and the structural guarantee that the SGX share alone is insufficient to sign — but it represents a genuine divergence from the physical tamper-resistance model of FIPS 140-2 Level 3 HSMs.

Policy Engine and Network Architecture

Fireblocks operates a dedicated Fireblocks Network — a permissioned network for inter-institution transfers that allows direct asset movement between Fireblocks clients without on-chain settlement, settling net positions periodically. The policy engine supports complex governance rules: withdrawal limits by asset and amount, whitelisted destination addresses, multi-approver workflows with biometric authentication, and time-lock conditions. These policy rules are enforced at the MPC signing layer — a transaction that violates policy cannot be signed, not merely rejected at the application layer.

Anchorage Digital, the first federally chartered digital asset bank in the United States (OCC charter, 2021), represents a fundamentally different architectural philosophy from Fireblocks: rather than a software-first MPC platform with cloud HSMs, Anchorage is built around physical infrastructure designed to satisfy the most stringent banking regulators in the world.

The Biometric-MPC Hybrid Model

Anchorage's signature architectural innovation is the integration of biometric authentication directly into the MPC signing quorum. Rather than relying solely on device possession, Anchorage requires biometric verification (fingerprint or face) from designated human approvers, whose biometric data is stored in an on-device secure enclave and never transmitted to Anchorage's servers. The biometric verification unlocks the approver's key share for the duration of the signing session only.

This architecture satisfies a specific regulatory requirement: human intentionality in the signing process. A rogue automated system cannot satisfy the biometric threshold without physical human cooperation — directly addressing the coercion and rogue employee scenarios that concern banking regulators most acutely.

Physical Infrastructure and Regulatory Design

As a nationally chartered bank, Anchorage's custody infrastructure is designed to satisfy OCC Handbook requirements for custodial services, NIST SP 800-57 key management standards, and the examination expectations of federal bank examiners. This creates a design constraint that differs fundamentally from non-bank MPC vendors: every component must be documentable, examinable, and explainable to a non-technical regulatory audience.

Concretely, this means: physical HSMs in OCC-examinable facilities rather than cloud SGX enclaves; documented key ceremonies with notarised witness attestations; explicit chains of custody for all cryptographic material; and signing workflows that map to traditional banking dual-control concepts that regulators already understand.

The cryptographic layer — MPC signing, HSM protection — solves the key security problem. The governance layer solves the authorisation problem: even if an attacker cannot steal a key, they may be able to manipulate the signing process into authorising a fraudulent transaction. A well-designed policy engine makes the signing infrastructure useless to an attacker who has not also compromised the governance layer.