MPC vs Multisig vs HSM
The engineering decision underneath MiCA custody: MPC threshold signatures, HSM tamper-response hardware and on-chain multi-sig compared on single-point-of-failure resistance, auditability, recovery, cost and chain-agnosticism, with a cold/warm/hot tiering pattern and key ceremony, rotation and disaster-recovery design notes.
14 min read
49 views
Key takeaways: MPC vs Multisig vs HSM 5
How MPC, HSM and on-chain multi-sig compare on single-point-of-failure resistance, auditability, rotation and cost, and how the tier ratios below actually get derived.
- MPC removes the single point of key compromise A complete private key never exists anywhere, even during signing, which is the actual argument for MPC in a custody stack, not raw speed.
- HSM key-in-hardware defense is a graded property, not a blanket claim Tamper-response zeroization only exists at FIPS 140-3 Level 3 and above; a Level 2 module only proves someone opened it, it does not stop them.
- On-chain multi-sig quorum is public, but mechanics are chain-specific Bitcoin uses protocol-native script multi-sig and EVM chains use contract wallets like Safe, so the two behave differently on signer rotation.
- FIPS 140-2 goes historical on 21 September 2026 Every remaining active FIPS 140-2 certificate moves to the CMVP historical list on that date. New procurement language should specify FIPS 140-3.
- Tier ratios are derived from SLA math, not decreed by anyone MiCA sets no cold-storage percentage. A 40-60% cold / 30-50% warm / 5-10% hot split is a trading-active treasury pattern, not a standard.
MPC vs Multisig vs HSM is the engineering decision underneath every MiCA custody architecture: which key-management scheme actually holds, signs and protects the private keys controlling client crypto-assets. Two claims repeat constantly and both deserve scrutiny. One is that MPC is "NIST-certified", it is not, no such certificate exists as of July 2026. The other is that a FIPS 140-2 certificate is still current baseline procurement language, it will not be for much longer. As of 20 July 2026, 207 of 295 active CASPs in the ESMA register (70%) hold custody authorization, so most of that population is making this call now, and in our work building custody infrastructure we see the same three options compared badly more often than compared well.
In short: multi-party computation (MPC, also called threshold signatures or TSS) splits a private key into shares so the complete key never exists anywhere, at the cost of no scheme-level certification to hand a regulator. A hardware security module (HSM) puts the whole key inside one certified physical boundary that detects and responds to tampering and gives a supervisor a government-recognized certificate, but every remaining FIPS 140-2 certificate moves to the historical list on 21 September 2026. On-chain multi-sig requires m-of-n signatures natively and publicly, though mechanics differ between Bitcoin script and EVM contract wallets and rotation behaves differently on each. None of the three wins outright, stacks that pick only one tend to be under-engineered.
The custody engineering decision
Choosing a key-management architecture means choosing three things at once: a security model for how a signature gets produced, an evidence pack a supervisor can inspect and an operating cost that scales with transaction volume. MPC, HSM and on-chain multi-sig answer all three differently, and comparing them without separating those axes ends up comparing a cryptographic protocol against a piece of hardware against a smart-contract pattern as if they were the same kind of thing. Which assets stay segregated, what a custody policy describes and how liability attaches are covered in our companion legal article, not repeated here.
MPC and threshold signatures: no key anywhere
How DKG and key shares work
Multi-party computation removes the single point of key compromise: a complete private key never exists in one place, even during signing. NIST describes threshold cryptography's core idea as splitting a secret across multiple parties so an operation can run without ever reconstructing the key, that property, not raw speed, is the real argument for MPC in custody. A threshold wallet is created through distributed key generation (DKG): each node contributes its own entropy, and the protocol combines those into key shares without any single node ever holding the whole key. Signing works the same way, a threshold number of shares cooperate to produce one valid signature, and compromising fewer shares than the threshold reveals nothing useful. Shares can also be reshared, replaced with fresh shares corresponding to the same public key and address, what makes MPC convenient for routine key hygiene.
Protocols and curves: FROST vs CMP and the GG-family
Not every threshold protocol supports every signature scheme, a detail vendor marketing tends to blur. FROST, standardized as RFC 9591 (IRTF Crypto Forum Research Group, June 2024), is a two-round threshold Schnorr protocol, with ciphersuites for Ed25519, Ed448 and other curves, that produces Schnorr signatures and cannot produce an ECDSA signature. It is an Informational RFC, research consensus rather than a formal Internet Standard, and deliberately non-deterministic, since deterministic nonces enable key-recovery attacks in a multi-party setting. Chains verifying ECDSA need a different protocol family: Fireblocks describes its MPC-CMP as one signing round against nine in the earlier GG18 protocol, roughly eight times faster by its own marketing, and covering both ECDSA and EdDSA, a vendor claim, not a benchmark we ran. The target chain's signature scheme constrains which threshold protocol is even eligible, before any vendor comparison starts.
What MPC cannot give you: certification status in 2026
NIST's threshold cryptography project finalized its first call for multi-party threshold schemes as NIST IR 8214C in January 2026, and the accompanying MPTS 2026 workshop is still collecting submission previews through August 2026, so there is no NIST-standardized, and therefore no NIST-certified, threshold or MPC signing scheme as of this writing. Vendors selling MPC custody cannot point to a government certificate for the protocol itself, only to the certified environment a key share runs inside, plus vendor-level assurance such as SOC 2, ISO 27001 or CCSS-style audits. "Is your MPC certified" has no honest yes answer yet.
HSMs: the key in a box that fights back
A hardware security module keeps the complete private key inside one certified physical boundary and defends it with tamper-resistant hardware, not with mathematics that avoids assembling the key at all. FIPS 140-3, "Security Requirements for Cryptographic Modules", is the current US federal standard, superseding FIPS 140-2 and aligned with ISO/IEC 19790 and ISO/IEC 24759, defining four increasing security levels where the level matters more than the fact of certification itself.
FIPS 140 levels: tamper evidence vs tamper response
The four levels step up from basic production-grade requirements at Level 1 to tamper evidence at Level 2, seals that must be visibly broken to reach key material, role-based authentication only. Level 3 is where the module fights back: tamper detection and response, circuitry that zeroizes plaintext key material when a cover is opened, identity-based authentication. Level 4 adds a full protective envelope plus defense against environmental attacks like voltage or temperature manipulation. Custody deployments should specify Level 3 or above, a Level 2 module only proves someone opened it, it does not stop them.
The 21 September 2026 FIPS 140-2 sunset
The CMVP stopped accepting new FIPS 140-2 submissions on 21 September 2021, and every remaining active FIPS 140-2 certificate moves to the CMVP historical list on 21 September 2026, two months after this article's publication window. Historical status does not retroactively make a deployed module insecure and has no direct EU legal force, but federal procurement can no longer cite it for new acquisitions, and any custody RFP still specifying "FIPS 140-2 Level 3" is about to reference a dead list. New procurement language should specify FIPS 140-3.
HSM tradeoffs for blockchain keys: rotation and curve support
Because the whole key exists as one object inside the module, rotating an HSM-held blockchain key forces a new address and an on-chain migration of funds. Curve support also varies by vendor and firmware version, secp256k1 and EdDSA coverage is not universal across product lines, a qualitative factor rather than something to benchmark.
On-chain multi-sig: transparency as a feature and a cost
On-chain multi-sig requires an m-of-n set of independent signatures natively, so the quorum policy is visible and verifiable by anyone reading the chain, the strongest public-auditability story of the three schemes. It is also chain-specific mechanics rather than one portable pattern, and that specificity is where competitor coverage most often goes wrong.
Bitcoin script vs EVM contract wallets
Multi-sig is chain-specific, not a smart-contract-platform feature. Bitcoin has protocol-native m-of-n multi-sig through OP_CHECKMULTISIG, standardized via BIP-11 in 2011 and made practical through P2SH and later P2WSH, no smart contract involved. Ethereum's externally owned accounts have no native multi-sig equivalent, so m-of-n on EVM chains runs through smart-contract wallets, Safe (formerly Gnosis Safe) being the dominant implementation, reporting more than $60 billion secured, over $1 trillion in volume and over 57 million wallets deployed per its own site as of 21 July 2026. Rotation is where the asymmetry shows: changing a Bitcoin script signer changes the script and the address, so funds must move on-chain, while on Safe and similar EVM wallets the owner set is mutable contract state, so signers swap while the address stays the same. Know which chain family you are on before promising clients an address-stable rotation.
What on-chain visibility buys auditors and costs you
Public quorum policy and signer addresses cut both ways: the strongest third-party-verifiable evidence of the three schemes, since an auditor can confirm the threshold and signer set without trusting internal documentation, but also a disclosed attack surface, an adversary sees exactly what threshold to defeat. Every signature costs gas per transaction, and both cost and mechanics are chain-specific, a Safe on Ethereum covers nothing for a Bitcoin or Solana holding.
The tradeoff matrix
None of the three schemes wins outright, they win on different criteria.
| Criterion | MPC / TSS | HSM | On-chain multi-sig |
|---|---|---|---|
| Single-point-of-failure resistance | Strongest by construction: the complete key never exists anywhere, fewer shares than the threshold yields nothing usable | Key exists complete inside one boundary; mitigated by tamper response and clustering, not eliminated | No single key controls funds, though each signer key is a conventional single key, often hardware-backed |
| Auditability and attestation | Weakest formal story: no scheme-level certification exists yet, assurance comes from vendor audits such as SOC 2 or CCSS | Strongest formal story: a FIPS 140-3 certificate per module, graded by level | Strongest public story: quorum and signers verifiable on-chain by anyone, including auditors and clients |
| Key recovery and disaster recovery | Reshare-in-place, no address change; DR means backing up shares and rehearsing the reshare protocol | Backup via key wrapping or module cloning inside the boundary; losing a module without backup means losing the key, rotation forces migration | Replacing a lost signer via the remaining quorum; EVM wallets rotate in place, Bitcoin script requires address migration |
| Operational complexity | High at vendor/protocol layer, low at chain layer; policy engine off-chain, plus ceremony and node overhead | Mature discipline inherited from traditional custody, but real physical logistics, firmware lifecycle and data-center constraints | Low technical complexity, high process complexity: every transaction needs multiple approvals on-chain, with the latency that implies |
| Chain-agnosticism | High: output is a standard ECDSA or EdDSA signature, but the protocol must match the chain's scheme, FROST covers Schnorr/EdDSA not ECDSA, CMP-family targets ECDSA | Moderate: depends on which curves the firmware supports | Lowest: mechanics are chain-specific and do not port, a Safe on Ethereum does nothing for a Bitcoin or Solana holding |
| Regulatory evidenceability | Vendor attestation plus architecture documentation; no government certificate for the scheme itself | Certificate-shaped evidence a supervisor already understands, specify FIPS 140-3 not the sunsetting 140-2 | On-chain proof and contract code, public and immutable but requiring the reviewer to read chain data |
| Cost profile | Medium to high: vendor licensing or in-house engineering, plus node infrastructure | High upfront hardware and facilities cost, predictable run-rate, established procurement | Low tooling cost, ongoing per-transaction gas and coordination overhead that grows with volume |
| Insider-threat resistance | Strong: no administrator ever holds the whole key, quorum enforced cryptographically off-chain | Depends on procedure: dual control and split knowledge are policy constructs, authentication role or identity-based by level | Strong and publicly provable: no insider below quorum can move funds, any attempt is visible on-chain |
A pattern emerges rather than a single winner: MPC suits hot and warm tiers where velocity and address stability matter, HSM-anchored storage suits the cold tier where a certificate answers a supervisor, and multi-sig earns its place wherever public verifiability outweighs signature-collection friction. Most stacks we build combine at least two, a hybrid architecture is the norm, not a compromise.
Cold, warm and hot: allocating the treasury
MiCA sets no cold-storage percentage anywhere, so the ratio a CASP should target is derived, not a compliance number to look up. Withdrawal SLAs, daily settlement float and venue pre-funding needs determine warm and hot tier size, the remainder goes cold. Public custody guidance skews far colder, commonly 80-95% or higher, because most of it targets custodians without active trading flow, not the pattern below.
| Tier | Share of AUM (design pattern) | Scheme rationale |
|---|---|---|
| Cold | 40-60% for a trading-active book, materially higher toward 90%+ for custody-heavy CASPs | No network path to the keys: air-gapped signing over one-way transport (QR or USB), keys in an offline HSM at Level 3+ or offline MPC shares on powered-down media. Rotation is rare and ceremony-grade |
| Warm | 30-50% for a trading-active book, smaller in custody-heavy setups | Online but human-gated: an MPC quorum requiring co-signers at separate sites, or an m-of-n multi-sig with hardware-backed keys. Replenishes hot on a schedule, not on demand |
| Hot | 5-10% | Automated payouts, gas and settlement. MPC with an off-chain policy engine fits best, velocity and allowlist rules enforced before shares participate. A hard aggregate cap with auto-sweep to warm, for example an internal limit such as EUR 5 million, keeps exposure bounded |
The logic underneath the table is an attack-surface budget: hot accepts online exposure for velocity bounded by a cap, warm removes automation but stays network-reachable, cold removes reachability altogether. No standards body or regulator fixes a ratio, treat these as a starting point for the SLA math, not a standard.
Key ceremonies, rotation and disaster recovery
A key ceremony must be scripted, witnessed and recorded, regardless of scheme. The best publicly documented reference model is IANA's root DNSSEC key-signing-key ceremonies, held roughly four times a year, scripted, with Trusted Community Representatives as independent witnesses and a public per-ceremony record, a pattern any CASP ceremony can borrow: a pre-published script, named roles, an independent witness, video plus signed log as the artifact, in a physically controlled, network-isolated room with equipment pre-checked for tampering. With MPC, each node contributes its own entropy during DKG and no participant ever sees a complete seed. An HSM generates the key inside the module, never imported and backed up only through wrapped export or module-to-module cloning within the boundary. For multi-sig, each signer runs an independent ceremony for their own key, and the quorum setup transaction itself is a witnessed step.
Rotation should follow the cryptoperiod discipline in NIST SP 800-57 Part 1: keys have a defined service life and rotate on a schedule, not only after an incident. Cost differs by scheme: MPC reshares in place with no address change, HSM rotation creates a new address and forces on-chain migration, multi-sig splits by chain family, EVM wallets swap owners in place while Bitcoin script changes the address. Address-preserving rotation also keeps client-facing deposit addresses stable, a real saving in client communication.
Disaster recovery follows the same split. MPC recovers through sharded backup material at remote sites, with drills that restore quorum from backups on a schedule. HSMs recover through geographically separated backup modules holding cloned or wrapped keys, tested with real restores. Multi-sig builds n-minus-m loss tolerance into the quorum design, so one site or person going offline never drops signers below threshold. Across all three, an untested recovery path is the real liability exposure, a DR procedure never rehearsed is a promise, not a control.
Mapping the architecture to MiCA evidence
The scheme a CASP chooses is how the legal requirements covered in our companion article, MiCA Custody Requirements, get implemented in code and hardware. Address-level separation of client and corporate holdings is the wallet architecture and tiering above; operational segregation means client-asset signing paths, whichever quorum, module or share set they use, must be structurally distinct from those controlling the CASP's own treasury. The custody policy and security-systems description a supervisor asks for is largely a technical annex built from the scheme choice, the tiering and the ceremony and DR documentation above, and a tested, rehearsed recovery path turns "attributable incident" into a bounded category. None of that requires re-deriving Article 70 or 75 here, that detail lives in the companion article.
How Pharos Production helps
We design and build this architecture: MPC integrations with policy engines for hot and warm tiers, HSM-anchored cold storage specified against FIPS 140-3, multi-sig quorums matched to the chains a CASP supports and the ceremony, rotation and DR documentation a supervisor can follow. Whether MiCA's custody rules eventually specify a technology or a tiering ratio is a question we track in our MiCA Review 2026 hub. If your platform is choosing between these schemes, or combining them, we can walk through the tradeoffs for your chains and volumes. See our MiCA compliance software development services.
Sources: RFC 9591 (IRTF CFRG, June 2024), rfc-editor.org/rfc/rfc9591.html. NIST threshold cryptography project and NIST IR 8214C, csrc.nist.gov/projects/threshold-cryptography. FIPS 140-3, csrc.nist.gov/pubs/fips/140-3/final, and the FIPS 140-2 to 140-3 transition timeline. NIST SP 800-57 Part 1 Revision 5, csrc.nist.gov/pubs/sp/800/57/pt1/r5/final. IANA root DNSSEC KSK ceremony records, iana.org/dnssec/ceremonies. Fireblocks and Safe product claims cited as vendor statements, fireblocks.com and safe.global, checked 21 July 2026. This article was last reviewed 21 July 2026.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
MPC computes one standard signature off-chain from distributed key shares, so the chain sees an ordinary single-key wallet and the quorum policy stays hidden. Multi-sig collects m-of-n separate approvals natively on-chain, where the quorum itself is public and independently verifiable.
-
Cold-storage custody modules are typically specified at FIPS 140-3 Level 3, where tamper detection zeroizes key material on physical intrusion. Specify 140-3, not 140-2: remaining FIPS 140-2 certificates move to the CMVP historical list on 21 September 2026.
-
The MPC protocol itself cannot. NIST has no threshold-scheme standard yet, its first call for submissions (NIST IR 8214C) only went final in January 2026 and is still collecting submission previews.
What can be certified is the module or enclave each key share runs in, plus vendor-level audits such as SOC 2 or CCSS.
-
MiCA sets no ratio. The split is derived from withdrawal SLAs and settlement float: trading-active CASPs often run roughly 40-60% cold with a 5-10% hot float, while custody-heavy books run 90% or more cold.
The cap on the hot tier matters more than the exact percentage.
-
Depends on the scheme. MPC resharing replaces key shares while keeping the same address.
HSM rotation generates a new key and address, forcing on-chain migration. Multi-sig rotates in place on EVM contract wallets like Safe but changes the address on Bitcoin script multi-sig.
-
None. The legal requirements are outcome-based (segregation, safekeeping, liability, see our companion legal article, MiCA Custody Requirements), and each scheme just produces a different evidence pack: a FIPS certificate for HSMs, a public on-chain quorum for multi-sig, vendor attestations and architecture documentation for MPC.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
