Threat Model — Deep Dive
Distributed-Control Failure Modes
Twenty-four ways distributed-control custody can fail, compared across MPC / TSS and on-chain . Where the architectures share a risk, where one has the advantage, and where neither wins alone.
| # | Failure mode | MPC / TSS | On-chain multisig | Relative observation |
|---|---|---|---|---|
| 01 | Core security mechanism vulnerability | MPC protocol or implementation flaw can undermine threshold cryptography and, in vulnerable designs, leak key material | Multisig smart-contract flaw can undermine M-of-N enforcement | Both exposedBoth exposed, but different attack surfaces |
| 02 | Complete private-key extraction | Possible where a threshold protocol / implementation leaks enough information to reconstruct the underlying PK | Compromising one independent signer does not reveal the other signer keys | MultisigMultisig advantage |
| 03 | Quorum bypass | Protocol / implementation failure can potentially allow threshold security to be defeated | Contract vulnerability can potentially bypass M-of-N authorization | Both exposedBoth exposed |
| 04 | Single participant compromised | Correctly implemented threshold MPC should tolerate compromise below threshold | 1 compromised signer in a 3-of-5 cannot move funds | ComparableComparable |
| 05 | Threshold participants compromised | Compromise enough MPC participants / shares and threshold security fails | Compromise enough independent signer keys and M-of-N fails | ComparableComparable |
| 06 | Employee / signing device compromised | Malware can manipulate transaction intent before MPC authorization | Malware can manipulate transaction intent before multisig signature | Both exposedSame fundamental risk |
| 07 | Signing UI compromised | Participant can authorize malicious transaction believing it is legitimate | Signer can sign malicious transaction believing it is legitimate | Both exposedSame fundamental risk |
| 08 | Vendor / backend compromise | Can affect orchestration, transaction construction, policy and possibly MPC participation depending on architecture | Backend can propose malicious transactions, but shouldn't be able to satisfy on-chain quorum itself | DependsArchitecture-dependent; independent multisig can reduce dependency |
| 09 | Policy engine compromised | Off-chain policies can potentially be manipulated | Off-chain policies can also be manipulated; critical rules can additionally be enforced on-chain | MultisigPotential multisig advantage if critical controls are on-chain |
| 10 | Recovery mechanism compromised | Some recovery / export designs can ultimately reconstruct a complete wallet PK | Per-signer recovery can reconstruct one signer PK while preserving M-of-N | MultisigMultisig advantage if recovery is per-signer |
| 11 | Recovery collapses threshold | Possible in some hard-recovery designs: recovery → full PK → effectively 1-of-1 | Properly designed recovery: restore Signer A → still only 1-of-N | MultisigMultisig advantage |
| 12 | Insider / collusion attack | Enough MPC participants can authorize a malicious transaction | Enough multisig signers can authorize a malicious transaction | ComparableComparable |
| 13 | Physical / wrench attack | Coerce enough participants, recovery custodians or authorization holders | Coerce enough signers to reach quorum | Both exposedBoth exposed |
| 14 | Supply-chain attack | Compromised MPC client / SDK / software can manipulate signing | Compromised wallet / frontend / signing software can manipulate transactions | Both exposedBoth exposed |
| 15 | Vendor disappears | May require vendor-independent MPC nodes, recovery / export or migration depending on design | Independent signer keys + on-chain contract can potentially continue without the platform vendor | MultisigMultisig advantage when designed for vendor independence |
| 16 | Availability / liveness failure | Enough MPC participants and protocol infrastructure must remain available | Enough multisig signers must remain available | ComparableComparable, although MPC may have additional orchestration requirements |
| 17 | Signer / key replacement | Share refresh / resharing and participant replacement require MPC protocol operations | Signer changes require contract / native multisig operations | ComparableBoth have operational complexity |
| 18 | Auditability of quorum | Blockchain generally sees the resulting conventional signature, not the internal MPC approval structure | On-chain multisig can expose that M-of-N authorization was enforced | MultisigMultisig advantage |
| 19 | Smart-contract vulnerability | Not inherent to MPC itself unless MPC controls a smart contract | Contract-based multisig (EVM Safe, Solana Squads) inherits contract implementation risk. Bitcoin, XRP and Cardano native multisig have no equivalent surface. | MPCMPC advantage on contract-based multisig; no exposure on native chains |
| 20 | Cryptographic protocol complexity | DKG, ZK proofs, threshold ECDSA, nonce generation, resharing and participant interaction increase cryptographic complexity | Independent conventional signatures generally avoid interactive threshold-key cryptography | MultisigMultisig advantage |
| 21 | On-chain footprint / privacy | MPC can appear as an ordinary blockchain signature | Reveals structure on EVM Safe, Solana Squads and Bitcoin P2SH / P2WSH scripts alike: a Bitcoin spend publishes the witness script, so M, N and every signer key are visible on-chain. That is the price of a quorum the chain itself can verify. | MPCMPC advantage on every chain; multisig trades privacy for an on-chain, verifiable quorum |
| 22 | Transaction fees | Usually produces standard signature / transaction characteristics | Higher gas on EVM Safe. On Bitcoin a 2-of-3 P2WSH spend is roughly 150–250 vB against about 110 vB for single-sig, so meaningfully more than an MPC transaction. XRP, Cardano and Solana Squads sit close to single-sig cost — see the Gas Fees page. | MPCMPC advantage on EVM and Bitcoin; near parity on XRP, Cardano and Solana |
| 23 | Cross-chain consistency | MPC can often produce the native signature expected by many chains | Multisig implementation differs substantially between chains | MPCMPC advantage |
| 24 | Transaction-intent attack | MPC can perfectly sign the wrong transaction | Multisig can perfectly sign the wrong transaction | NeitherNeither solves this alone |
Core security mechanism vulnerability
MPC protocol or implementation flaw can undermine threshold cryptography and, in vulnerable designs, leak key material
Multisig smart-contract flaw can undermine M-of-N enforcement
Both exposed, but different attack surfaces
Complete private-key extraction
Possible where a threshold protocol / implementation leaks enough information to reconstruct the underlying PK
Compromising one independent signer does not reveal the other signer keys
Multisig advantage
Quorum bypass
Protocol / implementation failure can potentially allow threshold security to be defeated
Contract vulnerability can potentially bypass M-of-N authorization
Both exposed
Single participant compromised
Correctly implemented threshold MPC should tolerate compromise below threshold
1 compromised signer in a 3-of-5 cannot move funds
Comparable
Threshold participants compromised
Compromise enough MPC participants / shares and threshold security fails
Compromise enough independent signer keys and M-of-N fails
Comparable
Employee / signing device compromised
Malware can manipulate transaction intent before MPC authorization
Malware can manipulate transaction intent before multisig signature
Same fundamental risk
Signing UI compromised
Participant can authorize malicious transaction believing it is legitimate
Signer can sign malicious transaction believing it is legitimate
Same fundamental risk
Vendor / backend compromise
Can affect orchestration, transaction construction, policy and possibly MPC participation depending on architecture
Backend can propose malicious transactions, but shouldn't be able to satisfy on-chain quorum itself
Architecture-dependent; independent multisig can reduce dependency
Policy engine compromised
Off-chain policies can potentially be manipulated
Off-chain policies can also be manipulated; critical rules can additionally be enforced on-chain
Potential multisig advantage if critical controls are on-chain
Recovery mechanism compromised
Some recovery / export designs can ultimately reconstruct a complete wallet PK
Per-signer recovery can reconstruct one signer PK while preserving M-of-N
Multisig advantage if recovery is per-signer
Recovery collapses threshold
Possible in some hard-recovery designs: recovery → full PK → effectively 1-of-1
Properly designed recovery: restore Signer A → still only 1-of-N
Multisig advantage
Insider / collusion attack
Enough MPC participants can authorize a malicious transaction
Enough multisig signers can authorize a malicious transaction
Comparable
Physical / wrench attack
Coerce enough participants, recovery custodians or authorization holders
Coerce enough signers to reach quorum
Both exposed
Supply-chain attack
Compromised MPC client / SDK / software can manipulate signing
Compromised wallet / frontend / signing software can manipulate transactions
Both exposed
Vendor disappears
May require vendor-independent MPC nodes, recovery / export or migration depending on design
Independent signer keys + on-chain contract can potentially continue without the platform vendor
Multisig advantage when designed for vendor independence
Availability / liveness failure
Enough MPC participants and protocol infrastructure must remain available
Enough multisig signers must remain available
Comparable, although MPC may have additional orchestration requirements
Signer / key replacement
Share refresh / resharing and participant replacement require MPC protocol operations
Signer changes require contract / native multisig operations
Both have operational complexity
Auditability of quorum
Blockchain generally sees the resulting conventional signature, not the internal MPC approval structure
On-chain multisig can expose that M-of-N authorization was enforced
Multisig advantage
Smart-contract vulnerability
Not inherent to MPC itself unless MPC controls a smart contract
Contract-based multisig (EVM Safe, Solana Squads) inherits contract implementation risk. Bitcoin, XRP and Cardano native multisig have no equivalent surface.
MPC advantage on contract-based multisig; no exposure on native chains
Cryptographic protocol complexity
DKG, ZK proofs, threshold ECDSA, nonce generation, resharing and participant interaction increase cryptographic complexity
Independent conventional signatures generally avoid interactive threshold-key cryptography
Multisig advantage
On-chain footprint / privacy
MPC can appear as an ordinary blockchain signature
Reveals structure on EVM Safe, Solana Squads and Bitcoin P2SH / P2WSH scripts alike: a Bitcoin spend publishes the witness script, so M, N and every signer key are visible on-chain. That is the price of a quorum the chain itself can verify.
MPC advantage on every chain; multisig trades privacy for an on-chain, verifiable quorum
Transaction fees
Usually produces standard signature / transaction characteristics
Higher gas on EVM Safe. On Bitcoin a 2-of-3 P2WSH spend is roughly 150–250 vB against about 110 vB for single-sig, so meaningfully more than an MPC transaction. XRP, Cardano and Solana Squads sit close to single-sig cost — see the Gas Fees page.
MPC advantage on EVM and Bitcoin; near parity on XRP, Cardano and Solana
Cross-chain consistency
MPC can often produce the native signature expected by many chains
Multisig implementation differs substantially between chains
MPC advantage
Transaction-intent attack
MPC can perfectly sign the wrong transaction
Multisig can perfectly sign the wrong transaction
Neither solves this alone
The fundamental difference
The two architectures distribute different things.
MPC distributes one cryptographic secret. Multisig distributes authority between independent keys. Once you see the difference, every row in the table above stops feeling arbitrary.
MPC / TSS
Split one secret across parties
PK → Share A + Share B + Share C
// signing
Threshold protocol → ONE valid blockchain signature
The benefit: the complete PK normally never exists during ordinary .
The trade-off: the interaction creates a security dependency on the threshold protocol itself.
On-chain multisig
Distribute authority across independent keys
PK-A, PK-B, PK-C, PK-D, PK-E
// signing
A + C + E → 3-of-5 → On-chain execution
The benefit: no shared underlying private key that A can mathematically reconstruct from B and C — they are separate keys.
The trade-off: the multisig contract / native implementation becomes part of the trusted mechanism.
Fair comparison
Closest equivalents
For an apples-to-apples read on the twenty-four rows above, these are the paired failure surfaces.
Distinctive strengths & risks
Where each is strongest — and where each is riskiest
MPC / TSS
A complete private key normally doesn't exist on an individual signing device.
A defect in the interactive threshold cryptography or certain recovery mechanisms can potentially undermine the shared secret itself.
On-chain multisig
Signer keys are cryptographically independent. Compromising one doesn't mathematically reveal the others, and on-chain multisig can make the quorum independently enforceable.
The smart-contract or native multisig implementation becomes part of the trusted security mechanism. A serious contract flaw can potentially bypass quorum even though every signer PK remains secure.
Their shared operational weakness
Both architectures can fail the same way.
Neither MPC nor multisig solves transaction intent by itself. In both, the cryptography works perfectly — and signs the wrong transaction.
MPC
Multisig
The Trustodian architecture
Four independent security boundaries — not one clever cryptographic trick.
A serious custody proposition can't rest on any single mechanism — not MPC, not multisig, not a hardware wallet. Trustodian is designed around four independent boundaries. Compromising one still leaves the other three standing.
Independent Signer Keys
Each signer holds an independent private key. No shared secret, no threshold cryptography defect can leak the others.
On-chain Quorum
The M-of-N rule is enforced by the network — native on Bitcoin, XRP and Cardano; audited smart-contract on EVM and Solana. Not by an off-chain policy engine.
Independent Transaction-Intent Verification
Address Book, forced whitelisting, hardware-wallet signing, business-hours rules and KYT screening — checked outside the signing UI so the payload can't be swapped underneath.
Threshold-Preserving Recovery
Individual signers can be recovered without ever assembling a whole wallet key. The M-of-N requirement survives every recovery path.
No table replaces a full threat model. Real-world security is a defense-in-depth composition of policy, key custody, endpoint hygiene, and organizational controls — the observations above name the primary lever in each row, not the only one.