The Security Case for Multi-Party Agent Wallet

[Selqui]

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 algoithm 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.
• 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.

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.

Let's make the comparison

	MPA Wallet	On-chain multi-sig	MPC extension, vendor holds a share	Extension that holds the Private Key	Paper wallet
Where the secret lives	Threshold shares on nodes you deploy. No full Private Key on any machine.	Each signer holds a complete Private Key. The rule is a contract.	You hold one share. The vendor holds another in their infrastructure.	The full Private Key lives in the browser profile.	The full Private Key is on the paper, or in a photo of it.
One party can spend	Only if they already meet the threshold you chose (2/2, 2/3, 3/5, …).	Only if they meet the contract threshold. A stolen signer key is still a complete secret.	You cannot. The vendor co-signs every spend, and can refuse.	Yes. The key, the seed, or an unlocked session spends the wallet.	Yes. Anyone holding the paper spends the wallet.
A company is on the signing path	No. ContinuumDAO does not hold a share.	No, inside the contract. Each signature still comes from a hot wallet.	Yes. Every signature needs the vendor.	The extension is the signer. A bad update or a lookalike build is the wallet.	No, until the key is typed into software.
Keeps working if that company disappears	Nodes you already run keep signing. No software updates.	The contract remains. You still need the signer keys and a way to submit.	Signing stops. The share you hold is not a wallet.	The seed imports into another wallet.	The paper still spends, once imported.
What the chain sees	One ordinary signature from the shared address. No threshold details, or who signed.	A contract wallet. Signer set, threshold, and approvals are public, and every call costs extra gas.	One ordinary signature.	One ordinary signature.	One ordinary signature, after import.
Protocols that expect a normal account	The address is a normal account.	Some protocols reject contract wallets or price them differently.	The address is a normal account.	The address is a normal account.	The address is a normal account, after import.
Who approved stays off-chain	Proposals, Accepts, and Rejects stay on your nodes. The chain sees the transaction.	The signer set is public. Executed approvals are often public too.	The vendor sees every signature. The chain sees a single signature.	There is no second approver.	There is no second approver.
One review covers a batch (approve, then the calls that spend the allowance)	One multi-sign request holds the whole sequence. Co-signers Accept every leg, then MPC signs that payload. Broadcast sends the transactions in order.	Safe-style wallets can pack calls into one atomic contract execution. Each signer still approves with a hot key.	One prompt per transaction. Approve and the next call are separate clicks.	One prompt per transaction. The dapp can change calldata between the screen and the signature.	Not a workflow. Each spend imports the key.
Calldata is checked before anyone is bound	Per leg: function signature, parameter types, destination, chain. The request is posted only after that check.	Whatever the UI or a script checked. A bad call reverts on-chain after signers have approved.	A vendor warning on a single transaction, if they built one.	A single-transaction check inside the popup, in wallets that offer one.	None, until import.
The batch is simulated on live chain state	Each leg is simulated from the MPC address. Later legs run on top of earlier legs in the same batch. A revert is visible before creating signatures. Sequential eth_simulateV1 to get the gas from that run.	Some UIs simulate. Atomic execution rolls a failing bundle back after signatures are collected.	A preview of one transaction, if the vendor built one.	A preview of one transaction, in wallets that offer it. No co-signer re-checks a batch.	None.
Accept is bound to the exact payload	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 original payload.	The contract executes the approved hash. The member key that produced the approval is still phishable.	The vendor co-signs what the extension submitted. The extension screen is the trust boundary.	The screen and the signed bytes can diverge: permits, typed data, a swapped recipient.	The import step is the trust boundary. After that, software holds the key.
An AI agent can act without holding a spendable key	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.	An agent that can act must hold a signer key, a module, or a session key. That key is a full secret.	An agent credential is co-signed by the vendor. Policy and uptime belong to the vendor.	An agent with the key is the wallet.	It cannot propose, sign, or trade.
A human circuit breaker on every agent action	The threshold is the gate. A 2/2 group lets the agent propose and requires your other node to Accept. The frontend works with the agent off.	Possible when signers are different people who read the payload. Easy to collapse into one person with several hot keys.	The vendor’s policy engine, not a co-signer you chose.	A popup.	A person holding the paper.
DeFi without exporting the key	Built-in flows for major protocols (Uniswap, Aave, Curve, Aerodrome, Compound, Morpho, GMX, Hyperliquid, Derive, Lido, and others), under the same Accept loop.	Safe apps and WalletConnect, signed by member keys.	The extension’s dapp browser. The vendor co-signs.	Native, and the widest dapp list. Every site can request a signature.	Sweep into a hot wallet first.
Bitcoin and EVM under the same custody	Bitcoin (SegWit and Taproot) and EVM from the same group. Ed25519 chains via FROST are on the rollout. ECDSA uses CGGMP24.	A different contract, or a different tool, per ecosystem.	The chains the vendor shipped.	A different extension, and a different key, per ecosystem.	One chain and one address format.
One lost device, or one person	Extra nodes and a threshold you choose. Encrypted node backups restore a node onto new hardware. Family or friends can hold shares.	Works when the signers are actually independent.	Recovery is the vendor account: email, phone, or KYC. A lock on that account freezes the wallet.	The seed is the whole wallet.	Fire, loss, or an heir who cannot find it. An heir who finds it can take all of it.
Phishing surface at spend time	Reviewers see a request already published to the group. They are not connected to the dapp.	Each signer’s hot wallet is a target. One compromised signer lowers what remains of the threshold.	The extension and the vendor account.	The product itself: every site, every permit, every blind sign.	Low in a drawer. Total at the moment of use.
What you operate	One or more nodes, on a machine or a VPS you control.	A contract, plus a hot wallet per signer.	An extension and a vendor account.	An extension.	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.