Every treasury conversation about custody eventually collapses into the same false binary. Someone asks whether we should use MPC or multisig, as if picking one settles the question, and the honest answer is that they solve the same headline problem in ways that create very different second problems. Both get you off a single private key. Both spread signing authority so that one compromised laptop or one bribed employee cannot move the funds alone. Where they part ways is everything downstream of that, and downstream is where custody actually lives once you have money on the line.
So it helps to be precise about what each one is before comparing them. Multisig is an on-chain construct. The blockchain itself knows there are, say, three keys and that any two of them have to sign before a transaction is valid. The rule lives in a smart contract or in the chain's native scripting, and the chain enforces it. MPC, or multi-party computation with threshold signatures, moves that logic off-chain. The key is never assembled in one place. Instead it exists as shards held by different parties, and those parties run a cryptographic protocol that produces one ordinary signature without any shard ever seeing the others. The chain sees a single normal signature and has no idea a committee was involved.
What the chain sees, and why that matters
That distinction sounds academic until you look at the operational consequences, and there are a lot of them. Because MPC produces a standard single signature, an MPC wallet looks like a plain externally owned account on-chain. Nobody watching the ledger can tell your two-of-three signing policy from a guy with a single seed phrase. That is good for privacy and it means the same wallet works identically on Bitcoin, Ethereum, Solana, and basically any chain that supports the underlying signature scheme, because there is no on-chain contract to deploy.
Multisig wears its policy in public. On Ethereum, a Safe contract's owners and threshold are readable by anyone, which is either a feature or a leak depending on your threat model. A public multisig invites targeted social engineering against the named signers, but it also gives you something MPC struggles to match, which is that the enforcement is verifiable by the chain rather than by trusting a vendor's off-chain code. And multisig support is chain-specific. Bitcoin has native multisig, Ethereum has Safe and similar contracts, but plenty of chains have weak or nonexistent multisig tooling, so a multi-chain treasury on native multisig ends up running a patchwork of different setups.
Recovery, and the failure mode nobody plans for
Here is the part that gets under-discussed and then ruins someone's quarter. The two designs fail in different directions, and you should pick your poison deliberately.
With native multisig, if you lose one key, you are usually fine, because you set a threshold below the total for exactly this reason. Two-of-three means one signer can vanish and you still transact. The keys are independent, so a lost or dead signer is a governance event, not a catastrophe. The catastrophe with multisig is a buggy or upgradeable contract, or an admin key on the contract that quietly holds more power than the signing policy implies. Read the contract, not the marketing.
With MPC, the shards are pieces of one key, so recovery depends entirely on the vendor's re-sharing protocol and their key-generation ceremony. If the vendor's software has a flaw in how shards are refreshed, or if the company disappears, you can be in a much worse spot than a lost multisig signer, because there may be no way to reconstruct signing authority outside their system. This is where vendor lock-in stops being a procurement complaint and becomes a survival question. Ask any MPC provider two things directly. Can you export or reconstruct signing capability if we leave, and what happens to our ability to sign if your service is down for a week. If the answers are vague, that is your answer.
Governance, auditability, and lock-in
Policy enforcement is where teams often assume more than they have. With multisig, spending rules beyond the raw threshold, things like daily limits, whitelisted destinations, or time delays, have to be added as extra contract logic, and each addition is more surface area to audit. With MPC, those policies typically live in the vendor's off-chain policy engine, which is flexible and fast to change but only as trustworthy as the vendor's access controls and logging. A policy that a chain enforces is one you can prove. A policy an admin dashboard enforces is one you have to audit their logs to believe.
For auditability, multisig has a real edge that treasury and compliance people tend to appreciate once they see it. Every approval is an on-chain event with a timestamped signature tied to a known key, so the approval trail is public and immutable. You can reconstruct who signed what without asking anyone. MPC's approval trail lives in the vendor's system, so your audit quality is bounded by their logging and retention. Neither is disqualifying, but if you answer to auditors or regulators, an on-chain trail is easier to defend.
A rough way to match architecture to your situation:
- Small treasury, single chain, want maximum verifiability and do not mind managing keys yourself: native multisig, and read the contract source before funding it.
- Multi-chain treasury, high transaction volume, need fast policy changes and clean UX for non-technical signers: MPC, and negotiate exit and downtime terms hard.
- Large treasury with real regulatory exposure: often a hybrid, MPC for hot operational wallets where speed matters, native multisig or a qualified custodian for the cold reserve where verifiability matters more than convenience.
The rule of thumb I keep coming back to is that MPC optimizes for operational flexibility and multi-chain reach, while native multisig optimizes for verifiability and independence from any single vendor. Neither removes trust. MPC asks you to trust a vendor's cryptography and their off-chain policy engine. Multisig asks you to trust a smart contract's code and your own key management. Decide which one you are more comfortable auditing, because that is the trust you are actually buying.
Whatever you land on, treat the signing setup as something you monitor, not something you configure once and forget. Watch the wallets, alert on any transaction that touches the treasury, and know within seconds when funds move rather than finding out at the next reconciliation. We built a lot of Blockcircle's wallet-tracking around that exact instinct, because the custody design only protects you if someone is actually looking when it gets tested. Run a full recovery drill before you need one, on a small funded wallet, so the first time you exercise the recovery path is not the day something has already gone wrong.