There is a pattern I keep seeing in 2026 treasury post-mortems, and it has almost nothing to do with the cryptography. Almost every loss reads the same way at the architecture layer — a respectable threshold scheme, a respectable vendor, and a respectable diagram in the security section of the board deck. The loss happens one level below the diagram. It happens at the failure-mode layer. And the failure-mode layer is what marketing pages do not show you.
I want to be specific. When I sit down to choose between a multisig setup and an MPC setup for a treasury that has to survive 2026 — meaning audit-grade key custody, real signer compromise scenarios, real operational rotation — I do not start at the feature comparison. I start at the question of what happens when the thing breaks. The marketing pages start at "institutional-grade security". The post-mortems start at "the second signer was the founder's personal laptop". The gap between those two starting points is where treasuries die.
I want to walk through the patterns I see, and then close with what I think a sober treasury actually does. The voice register here is mentor, not vendor.
The Marketing-Page Threat Model
Almost every vendor page in this category sells against the same imaginary attacker — the lone hacker with a private key.
The threat model on the page goes like this. One key bad. Two keys good. Three keys distributed. Therefore secure. The math is correct as far as it goes. But the math is also doing about 10% of the work. The attacker who actually drains 2026 treasuries is not the lone hacker with a private key. The attacker is a social-engineering pipeline that aims at the weakest signer, a phishing landing page that imitates the signer's hardware wallet firmware update flow, an insider with one credential and a colleague willing to vouch on Slack, or — most underrated of all — a procedural collapse during recovery where the treasury team rebuilds the wallet under pressure and skips three of the documented checks.
None of those attackers show up in the diagram. The diagram shows a 2-of-3. The diagram does not show that one of the signers is a junior ops engineer who joined eight months ago, has admin access to the email account used for the hardware wallet's purchase confirmation, and lives in a country where SIM-swap takedown timelines are measured in weeks.
When I look at the public post-mortems and group by attacker class, hardware compromise of a single endpoint is a small minority. The dominant class is social or procedural — the attacker convinces a human to sign something the human should not have signed, or the recovery procedure fails under operational stress and exposes a key share. Multisig does not solve that. MPC does not solve that. Choosing between them on the marketing-page threat model is choosing between two answers to the wrong question.
The 2-of-3 That Is Actually 1-of-3
The cleanest pattern I see in multisig post-mortems is signer concentration that the diagram does not show.
A 2-of-3 multisig on Safe (formerly Gnosis Safe) reads as decentralized. Three keys. Two required. Theoretically you survive one compromise. In practice I keep seeing the same architecture in treasury reviews — signer A is the CFO's Ledger, signer B is the CFO's Trezor, signer C is the founder's GridPlus Lattice1. All three devices live in the same physical office. All three are purchased from the same vendor batch. All three have firmware update flows controlled by the same human. The 2-of-3 in the diagram is a 1-of-1 in physical reality, because compromising the human compromising all three devices is a single attack path.
This is the architecture I see when a CFO tells me their treasury is "multisig-secured" and I ask them where the signers physically live. The answer is usually a long pause. The diagram does not have a "physical location" axis. The threat model on the vendor page does not either. But the attacker has that axis. The attacker knows exactly where the office is, who runs the email account, and whether the founder travels with a hardware wallet in a checked bag.
The fix is signer geography, signer vendor diversity, and signer identity diversity — not a higher threshold. Going from 2-of-3 to 3-of-5 inside the same office is mostly theater. Going from 2-of-3 spread across three jurisdictions, two hardware vendors (Ledger and Trezor, say — different supply chains, different firmware audit histories), and three legally distinct identities is a real improvement. The board deck will look the same. The failure surface will not.
The 2-of-3 multisig that lives in one office is a single point of failure with a marketing budget.
The MPC Vendor Trust You Cannot See
MPC moves the math but does not eliminate the trust assumption — it relocates it into a vendor relationship most treasuries do not audit.
The pitch for MPC over multisig is real. The signing is off-chain, the on-chain footprint looks like a normal EOA, the gas cost is lower, you can rotate participants without redeploying a contract, and the key never exists in one place even momentarily. Coinbase Custody, Fidelity Digital Assets, and Anchorage Digital (the OCC-chartered crypto bank) all sit on top of MPC stacks for institutional deposits, and that is not an accident — MPC composes better with regulated workflows than on-chain multisig does. If your treasury needs a qualified custodian under NY DFS Trust Company rules, the answer almost certainly involves MPC under the hood.
But — and this is the failure mode the marketing pages skip — the MPC stack is a software stack. The threshold scheme protects you against the compromise of any single party, including the vendor, only if the implementation is correct. You are trusting the vendor's implementation of the protocol, the vendor's secure enclave (or the absence of one), the vendor's signer-rotation procedures, and the vendor's continuity in the face of regulatory action. None of those are visible in the architecture diagram either. The marketing-page comparison shows you "MPC: distributed key generation, no single key material". It does not show you what happens when the vendor's legal entity gets a court order, or when the vendor's signing service has an outage during a market crash and you cannot move the treasury.
There is also the disclosure gap. Multisig is on-chain. You can read the contract. You can see the signers. Anyone — your auditor, a curious analyst on Dune, a researcher on Etherscan — can verify the threshold and the signer set. MPC custody is opaque by design. You trust the vendor's attestation. For some treasuries that opacity is a feature (counterparties cannot see your signer set). For others it is a recurring audit cost that nobody priced in.
The Recovery Cost That Lives in a Drawer
The last pattern I see is the cost that hits the operations budget, not the security budget — recovery.
Both schemes have recovery procedures. Both procedures are documented. Almost no treasury I have audited can actually execute their recovery procedure cold, on a Saturday, with a key person unreachable. The runbook lives in a drawer. The annual recovery drill that the vendor recommends is the first thing that gets dropped when the team is busy, which is always. The procedure that should take a documented two hours has, in practice, taken weeks — because the seed-phrase backup was in a safe whose combination was held by the COO who is on vacation, because the MPC vendor's recovery contact requires re-verification of the legal entity which takes business days, because the hardware wallet is a model whose firmware was updated three times since the procedure was written and the documented screens no longer match.
This is the cost that does not appear on the procurement comparison. Multisig recovery cost is mostly internal — your team, your procedure, your backups. MPC recovery cost is mostly external — the vendor's process, the vendor's SLA, the vendor's response queue. Neither is cheap. Both get expensive precisely at the moment you need them, because you are recovering during a stressful event by definition. The treasuries that survive 2026 are not the ones with the best architecture diagram. They are the ones that ran the recovery drill in March and again in September, and discovered both times that the runbook was wrong.
Note also the audit-cadence gap that the on-chain side at least exposes — Binance's last proof-of-reserves attestation in the grounding I am working from is dated 2025-03-01, Bybit's 2025-03-12, OKX's 2025-03-01, MEXC's 2024-12-10, the previous public cadence having drifted by roughly a quarter on the slower end. That visible drift is what on-chain custody gives you. With an MPC vendor, the equivalent drift is invisible until you ask.
So What Do You Actually Do
If your treasury is under, roughly, the size where a qualified custodian's compliance overhead is justified, the answer is multisig with the diversity I described — different jurisdictions, different hardware vendors, different humans, and a recovery drill on the calendar twice a year that you actually do. Not Safe with three Ledgers in the same office. Safe with Ledger plus Trezor plus a Lattice1, signers in three places, recovery shards split across legally separate entities, and a drill that has actually been run cold. That is the version that earns the security-budget line item.
If your treasury is over the size where institutional counterparties require a qualified custodian, the answer is MPC through a chartered provider — Coinbase Custody under NY DFS, Fidelity Digital Assets under NY DFS, Anchorage Digital under the OCC charter — and you accept that you are buying vendor risk and audit overhead in exchange for the regulatory wrapper. You should still ask the vendor for their last incident report, their signer rotation cadence, and their recovery SLA in writing. If they will not provide them, walk away regardless of how clean the marketing page reads.
I would reverse this whole analysis if the open-source MPC stacks reached the same audit maturity as Safe's audited contracts — meaning multiple independent audits over multiple years against the same protocol implementation, plus public bug-bounty payout history. Until that maturity exists, on-chain multisig with disciplined operational diversity remains the more honest architecture for self-custodied treasuries, and the regulated custodians remain the answer for everyone above the line. The argument holds until the audit register changes.
FAQ
Is MPC actually more secure than multisig for a 2026 treasury?
Not at the math layer in a way that matters for most treasuries. Both reach a threshold security model. The real differentiator is operational — MPC composes better with regulated custody and off-chain signing workflows; multisig is more transparent and auditable on-chain. If your threat model is "trust the vendor less", multisig wins. If your threat model is "satisfy a qualified-custodian requirement", MPC inside a chartered provider wins. Picking on cryptographic strength alone is the wrong axis.
Why do most multisig losses involve "good" 2-of-3 setups?
Because the diagram counts keys, not failure surface. A 2-of-3 with all three signers in the same office, same hardware vendor batch, same person controlling firmware updates is a single point of failure dressed as three. The losses I read about cluster around signer concentration, social engineering of the weakest signer, and recovery-procedure collapse — not the cryptography. Diversity of jurisdiction, hardware vendor, and human identity matters more than raising the threshold from 2-of-3 to 3-of-5.
Can I run multisig with mixed hardware wallets like Ledger plus Trezor plus Lattice1?
Yes, and you should if you are going the multisig route. Safe and similar setups support mixed signer hardware. The reason to mix is supply-chain and firmware-audit-history diversity — Ledger, Trezor (SatoshiLabs), and GridPlus Lattice1 have different audit histories, different secure-element approaches, and different firmware update flows. A single firmware-flow compromise then cannot take all three. The operational cost is teaching the signers to use three different interfaces, which is real but worth it.
Is using Coinbase Custody, Fidelity Digital Assets, or Anchorage Digital "real" self-custody?
No, and it is important to be honest about this. Those are qualified custodians under NY DFS Trust Company rules (Coinbase, Fidelity) and OCC Federal Trust Charter (Anchorage) respectively. They hold the keys; you have a legal claim. That is a custody arrangement, not self-custody. The reason a treasury chooses them anyway is regulatory — qualified custodian status unlocks counterparties and audits that self-custody cannot. The tradeoff is explicit vendor and regulatory dependence.
What does a real recovery drill look like in practice?
You pick a day, you assume one signer is unreachable, you execute the documented runbook end-to-end on a low-value test address, and you time it. Almost every first drill I have seen turns up something broken — a seed-phrase backup in an inaccessible safe, a documented hardware screen that no longer matches current firmware, an MPC vendor contact who no longer works there. Twice a year, on the calendar, not skipped because the team is busy. The drill is the point — the runbook is a starting hypothesis.
How does proof-of-reserves cadence relate to custody choice?
It does not directly govern self-custody, but it tells you how seriously a custody-adjacent provider takes attestation discipline. The grounding I work from shows Binance's last attestation dated 2025-03-01, Bybit's 2025-03-12, OKX's 2025-03-01, and MEXC's 2024-12-10 — a visible cadence drift on the slower entry. That on-chain visibility is the whole point. With an MPC vendor, equivalent slippage is invisible until you ask. If you choose a vendor, ask for the attestation cadence in writing.
What treasury size justifies moving from multisig to a qualified custodian?
There is no single number, but the practical inflection is when counterparties, auditors, or banking partners start requiring a qualified custodian as a condition of doing business — typically institutional LP capital, public reporting, or a regulated banking relationship. Below that line, disciplined multisig is usually cheaper, more transparent, and operationally lighter. Above that line, the regulatory wrapper is what you are paying for, and the MPC architecture underneath is incidental to the legal status.
What single change has the biggest impact on multisig safety?
Signer diversity across jurisdiction, hardware vendor, and human identity — in that order. Raising the threshold from 2-of-3 to 3-of-5 inside the same office is mostly theater. Spreading 2-of-3 across three jurisdictions, two hardware vendors, and three legally distinct humans changes the failure surface materially. Every other improvement — better runbooks, recovery drills, signer rotation — compounds on top of that diversity. Without it, the other improvements are decorating a single point of failure.