Custody Architectures Compared: HSM, MPC and Multisig

Custody design is the place where cryptography, operations and organisational trust meet. The three building blocks most teams evaluate are hardware security modules, multi-party computation and on-chain multisig. They are frequently presented as competitors. They are better understood as answers to different questions: where does the key material live, who must cooperate to sign, and what happens when a person, a device or a vendor fails.

This comparison is written for teams choosing an architecture for an exchange, a treasury or a wallet product. It avoids vendor claims and focuses on the trust assumptions each model asks you to accept and the operational burden each one creates.

Hardware security modules

An HSM holds a complete private key inside tamper-resistant hardware and signs on request without ever exporting the key. Trust concentrates in three places: the device and its firmware, the physical and network controls around it, and the application that is authorised to call it. The key exists in one place, so the security question is entirely about who can reach that place and what they can make it do.

Operationally, HSMs are mature. Backup and restore ceremonies, quorum-based administration and audit logs are well understood, and cloud providers offer managed variants. The weakness is that the HSM will sign anything a legitimately authenticated caller asks it to sign. Compromise of the signing service, or of the credentials it uses, is compromise of the funds. That pushes most of the real security work into the policy layer that decides which requests reach the HSM at all.

Multi-party computation

With threshold signature schemes, no complete private key ever exists. Key shares are generated and held by separate parties, and a signature is produced by a protocol in which a threshold of parties cooperate without reconstructing the key. Shares can live on different machines, in different clouds, on user devices or with a co-signing service, and shares can be refreshed without changing the on-chain address.

The trust assumption shifts from "the device is secure" to "fewer than the threshold of parties are compromised at the same time, and the protocol implementation is correct". The second clause deserves weight. MPC libraries are complex, the protocols have had real vulnerabilities, and the behaviour of a broken implementation is often silent. You are also trusting the availability of enough parties; a co-signer outage is a signing outage.

What MPC buys you

The advantages are real: chain-agnostic signing for any curve the protocol supports, no on-chain footprint or extra gas, flexible policies enforced by co-signers before they participate, and the ability to give end users a share so the operator can never sign alone.

On-chain multisig

Multisig moves the quorum rule onto the chain. A smart contract or native multisig script holds the funds and executes only when M of N configured keys have approved a transaction. The chain enforces the policy, so it is transparent, verifiable and independent of any vendor. Each signer can use whatever key storage they like, including an HSM or an MPC wallet.

Costs are practical. Multisig is chain-specific, transactions are visible before execution, every approval is a signature that someone has to produce, and gas and latency are higher. Contract multisigs also inherit contract risk: upgradeability, module systems and signature-encoding details have all been exploited in the wild. Native multisig on chains that support it removes contract risk but limits flexibility.

Comparing the trust assumptions

• HSM: trust the hardware, the vendor firmware and the policy service in front of it. There is a single point of signing.
• MPC: trust that no threshold coalition is compromised and that the protocol code is correct. Signing needs enough parties online.
• Multisig: trust the chain and the contract code. Policy is public and enforced by consensus.
• All three: trust the process that authorises a transaction before any key is touched.

Approval workflows do most of the work

In every architecture, the layer that decides whether a withdrawal should be signed matters more than the signing primitive. A sound workflow has explicit policy: destination allow-lists, per-asset and per-period limits, velocity checks, separation between the person who initiates and the people who approve, and mandatory delays above a threshold. Approvals should be bound to the exact transaction payload so an approver cannot be tricked into signing something other than what they reviewed. Every decision, including rejections, is logged to an append-only store.

policy: treasury-withdrawals
rules:
  - match: { asset: "*", amount_usd: { lte: 25000 } }
    approvals: 1
    destination: allowlist
  - match: { asset: "*", amount_usd: { gt: 25000 } }
    approvals: 2
    delay_minutes: 60
    destination: allowlist
    notify: [security-oncall, treasury-lead]

The thresholds in a policy like this are the business's decision, not ours. What we insist on is that the policy is declarative, versioned, reviewed like code and enforced by a component that cannot be bypassed by the initiating application.

Key ceremonies

Whether you are generating an HSM master key, running distributed key generation for MPC or configuring signers for a multisig, the ceremony is the root of trust. Treat it as a controlled event: a written script rehearsed in advance, named participants with defined roles, air-gapped or freshly provisioned devices, independent witnesses, recorded verification of public keys and backup material, and a dated record signed by participants. Recovery material should be split so no individual can reconstruct it and stored under separate controls. The ceremony is also the moment to test recovery. A backup that has never been restored is a hypothesis.

When to combine them

Most production systems we design use more than one primitive. The combinations that come up most often:

1. MPC for hot operational wallets, with one share held by a policy engine that refuses to participate outside policy, plus an HSM-backed cold reserve reached only through a ceremony.
2. A multisig treasury where individual signer keys are protected by HSMs or MPC wallets, so on-chain transparency is combined with strong per-signer key hygiene.
3. User-facing wallets where the user holds one MPC share and the operator holds another, with a recovery share escrowed under a separate policy.

The primitive you choose determines what a compromise looks like. The workflow you build around it determines how likely a compromise is.

Choose the primitive by asking what failure you can tolerate: a vendor outage, an insider, a contract bug or a lost device. Then build the approval and ceremony process around it with the same discipline you apply to the code that moves the money. The teams that get custody right are rarely the ones with the most exotic cryptography; they are the ones whose runbooks have been rehearsed.