This article explores how the MPA Wallet stands up in terms of security to other wallet types, excluding hardware wallets for now (this is a separate analysis).
MPA Wallet uses the MPC algorithm with key shares on different nodes (computers) to make signatures that can be broadcast on-chain. These nodes could be run by humans, by AI agents or both. The Agreement ceremony generating the Private Key happens off-chain. No other entity, company or database is involved in this process.
The main other types of wallet are:
- On-chain multi-sig (e.g. Safe) puts the policy in a contract. Every signer still holds a complete private key, usually in a hot wallet.
- MPC browser extensions with a vendor share (the 2-of-2 cloud co-signer model) never give you a full key, and never let you sign without the vendor. The second share could be OAUTH, like email, or sit in a vendors database.
- Simple browser extensions that hold the Private Key (MetaMask, Rabby, Phantom, and the same pattern) put the entire wallet in one browser profile.
- Paper wallets put that same entire key on paper. Spending means typing it into software.
Before we start, let's define 'parties', 'threshold', 'shares' and 'batch sign requests'.
For MPA Wallet and for multi-sig wallets, we talk about 'parties'. This means nodes for MPA Wallet, but simply different signers in the case of a multi-sig. For MPA Wallet, each party has a 'share' of the Private Key, or more accurately, the ability to generate it. For multi-sig, each party needs a Private Key. We also talk about 'batch sign-requests' for MPA Wallet. DeFi rarely wants one signature. These are collections of multiple signatures to be signed at the same time, as is a common requirement when interacting with a web3 protocol. The 'threshold' is the number of parties that must 'Agree' to signature or batch sign-request before it can be executed on-chain, so a threshold of '2/3' means that 2 parties must Agree out of a possible 3.
This article compares the different wallet types in terms of security in interacting with DeFi. Let's take it step by step.
Where the secret lives
MPA. Threshold shares on nodes you deploy. No full Private Key on any machine.
Multisig. Each signer holds a complete Private Key. The payload is in a contract.
Vendor MPC. You hold one share. The vendor holds another in their infrastructure.
Extension. The full private key lives in the browser profile.
Paper. The full private key is on the paper, or in a photo of it.
Who can spend alone
MPA. Only if they already meet the threshold you chose (2/2, 2/3, 3/5, …).
Multisig. Only if they meet the contract threshold. A stolen signer key is still a complete secret.
Vendor MPC. You cannot. The vendor co-signs every spend, and can refuse.
Extension. Yes. The key, the seed, or an unlocked session spends the wallet.
Paper. Yes. Anyone holding the paper spends the wallet.
Is a company on the signing path?
MPA. No. ContinuumDAO does not hold a share. It is decentralized.
Multisig. No, inside the contract. Each signature still comes from a hot wallet. Also decentralized.
Vendor MPC. Yes. Every signature needs the vendor. Not decentralized.
Extension. The extension is the signer. A bad update or a malicious lookalike build is the wallet.
Paper. No, until the key is typed into software.
If that company ceases operation
MPA. Nodes you already run keep signing. No more software updates. Can Eject to a full Private Key.
Multisig. The contract remains. You still need the signer keys and a way to submit.
Vendor MPC. Signing stops. The share you hold is not a wallet.
Extension. The seed imports into another wallet.
Paper. The paper still spends, once imported.
What the chain sees
MPA. One ordinary signature from the shared address.
Multisig. A contract wallet. Signer set, threshold, and approvals are public, and every call costs extra gas.
Vendor MPC. One ordinary signature.
Extension. One ordinary signature.
Paper. One ordinary signature, after import.
Protocols that expect a normal account
MPA. The address is a normal account.
Multisig. Some protocols reject contract wallets or price them differently.
Vendor MPC. The address is a normal account.
Extension. The address is a normal account.
Paper. The address is a normal account, after import.
Who approved
MPA. Proposals, Accepts, and Rejects stay on your nodes. The chain sees the transaction.
Multisig. The signer set is public. Executed approvals are often public too.
Vendor MPC. The vendor sees every signature. The chain sees a single signature.
Extension. There is no second approver.
Paper. There is no second approver.
One review for a batch
DeFi rarely wants one signature. It wants an allowance and then the call that spends it, or a deposit and then a stake.
MPA. One multi-sign request holds the whole sequence. Co-signers can only Accept the whole batch, then MPC signs that payload. Broadcast sends the transactions in order, as ordinary account transactions.
Multisig. Safe-style wallets can pack calls into one atomic contract execution, so a revert rolls the whole bundle back. That atomicity is real. It is also a contract call, paid for in gas and in protocol support, and each signer still approves with a hot key.
Vendor MPC. One prompt per transaction. Approve and the next call are separate clicks.
Extension. One prompt per transaction. The dApp can change calldata between the screen and the signature. The gap between the approval and the following call is the dangerous part.
Paper. Not a workflow. Each spend imports the key.
Checked before anyone is bound
MPA. Per leg: function signature, parameter types, names, destination, and chain. The request is posted only after that check.
Multisig. Whatever the UI or a script checked. A bad call reverts on-chain after signers have approved.
Vendor MPC. A vendor warning on a single transaction, if they built one.
Extension. A single-transaction check inside the popup, in wallets that offer one.
Paper. None, until import.
Simulated on the live chain
MPA. Each leg is simulated from the MPC address against the chain you named. Later legs run on top of earlier legs in the same batch, so a revert in leg two shows up before anyone signs. At signature generation time, sequential eth_simulateV1 is what the gas figure follows.
Multisig. Some UIs simulate. Atomic execution rolls a failing bundle back after signatures are collected.
Vendor MPC. A preview of one transaction, if the vendor built one.
Extension. A preview of one transaction, in wallets that offer it. No co-signer re-checks a batch.
Paper. None.
Accept is bound to the exact payload
MPA. Co-signers Accept the published batch: calldata, recipients, amounts, Purpose. Agreeing nodes recompute EIP-712 digests and reject a mismatch. MPC runs only for that payload, which cannot be altered.
Multisig. The contract executes the approved hash. The member key that produced the approval is still phishable.
Vendor MPC. The vendor co-signs what the extension submitted. The extension screen is the trust boundary.
Extension. The screen and the signed bytes can diverge: permits, typed data, a swapped recipient.
Paper. The import step is the trust boundary. After that, software holds the key.
An AI agent, without a spendable key
The harness is a node, not a key. It can draft a trade, pull a protocol tool, post a multi-sign request with a Purpose, and read Thoughts from the other nodes. Purpose, Thoughts, and the transcript stay encrypted on the nodes you run, so the next AI agent on other nodes reads your history.
MPA. The harness runs on your node. It proposes with Purpose. Co-signers answer with Thoughts. MCP and the node API are the interface. History stays encrypted on your nodes.
Multisig. An agent that can act must hold a signer key, a module, or a session key. That key is a full secret.
Vendor MPC. An agent credential is co-signed by the vendor. Policy and uptime belong to the vendor. They can freeze it.
Extension. An agent with the key is the wallet.
Paper. It cannot propose, sign, or trade.
A human gate on every agent action
A typical personal group is 2/2. The agent can be fast. It cannot finish a signature alone. The same gate covers trades, governance votes, and treasury moves.
MPA. The threshold is the gate. A 2/2 group lets the agent propose and requires your other node to Accept. The frontend app still works with the agent turned off.
Multisig. Possible when signers are different people who read the payload. Easy to collapse into one person with several hot keys.
Vendor MPC. The vendor’s policy engine, not a co-signer you chose.
Extension. A popup.
Paper. A person holding the paper.
DeFi without exporting the key
MPA. Built-in flows for Uniswap, Aave, Curve, Aerodrome, Compound, Morpho, GMX, Hyperliquid, Derive, Lido, and others, under the same Accept loop.
Multisig. Safe apps and WalletConnect, signed by member keys.
Vendor MPC. The extension’s dapp browser. The vendor co-signs.
Extension. Native, and the widest dapp list. Every site can request a signature.
Paper. Sweep into a hot wallet first.
Bitcoin and EVM, same custody
MPA. Bitcoin (SegWit and Taproot) and EVM from the same group. ECDSA uses CGGMP24. Ed25519 chains (Solana, NEAR, and others) via FROST are on the rollout. MPA can work with almost any blockchain. Works with any EVM automatically.
Multisig. A different contract, or a different tool, per blockchain.
Vendor MPC. The chains the vendor shipped.
Extension. A different extension, and a different key, per ecosystem.
Paper. One chain and one address format.
One lost device, or one person
MPA. Extra nodes and a threshold you choose. Encrypted node backups restore a node onto new hardware. Family or friends can hold shares.
Multisig. Works when the signers are actually independent.
Vendor MPC. Recovery is the vendor account: email, phone, or KYC. A lock on that account freezes the wallet.
Extension. The seed is the whole wallet.
Paper. Fire, loss, or an heir who cannot find it. An heir who finds it can take all of it.
Phishing when you spend
MPA. Reviewers see a request already published to the group. They are not connected to the dApp. All off-chain.
Multisig. Each signer’s hot wallet is a target. One compromised signer lowers what remains of the threshold.
Vendor MPC. The extension and the vendor account.
Extension. The product itself: every site, every permit, every blind sign.
Paper. Low in a drawer. Total at the moment of use.
What you actually run
MPA. One or more nodes, on a machine or a VPS you control.
Multisig. A contract, plus a hot wallet per signer.
Vendor MPC. An extension and a vendor account.
Extension. An extension.
Paper. Paper, then a hot wallet whenever you spend.
I think that it is worth acknowledging that on-chain multi-sig can do something MPA Wallet does not: pack the same calls into one atomic contract execution, so a revert rolls the whole bundle back. That atomicity is real. It is also a contract call, paid for in gas and in protocol support (someone has to write and deploy this function), and each member still approves it with a hot key.
MPC wallets that are browser extensions and that have a vendor-share and private-key extensions ask once per transaction. The dangerous gap, where attacks can happen, sits between the approval and the following function calls. Paper wallets simply cannot have such a problem, since they have no batch of signatures at all.
Multi-sig wallets still leave a full private key with every signer, and they publish the policy on-chain. MPC extensions that keep a vendor share cannot sign, recover, or survive without that vendor. Browser extensions that hold the private key, and paper wallets, put the entire wallet in one secret. MPA Wallet keeps threshold shares on nodes you deploy, reviews a whole batch before anyone signs, simulates that batch against live chain state, and lets an agent propose through a harness that cannot spend unless your other node(s), whether they are run by humans or AI agents, Accept. Maintaining a cryptographic break between what an AI agent can sign without Agreement from other nodes is the defence in depth that is most sorely needed today as we see AI agents breaking out of their jails.
The price you pay for MPA Wallet security?
You must run multiple nodes on different machines.
