Multisig vs MPC Wallets: Cutting Custody Risk for Trading Bots

When a hot wallet has one key, it has one point of failure

A market-making bot that fires 400 orders a day can't wait on a 2-of-3 confirmation flow every time it rebalances. But a treasury holding six months of trading capital shouldn't sign anything with a single private key sitting in an environment variable on a VPS. Those are two different problems, and most teams solve them with one wallet architecture, which is the actual root cause behind most bot-related custody losses — not clever hacks, just a key management model that didn't match the job it was doing.

The two real options once you move past "one key, one signer" are on-chain multisig (Safe on EVM chains, Squads on Solana) and threshold-signature MPC (Fireblocks, Turnkey, Lit Protocol, DFNS, or a custom TSS implementation). They solve the same problem — no single point can move funds alone — but they do it at different layers, with different latency, different cost, and different failure modes. Picking the wrong one for a given wallet is how teams end up either bottlenecked on signing or exposed on a key they thought was distributed.

How multisig actually works

Safe and Squads enforce the threshold at the smart contract level. The wallet is a contract account. Each transaction gets proposed, signers submit approvals (either on-chain or off-chain via a relay service like the Safe Transaction Service), and once the threshold is met, anyone can trigger execution. The private keys involved are ordinary keys — held in a hardware wallet, a browser extension, whatever the signer uses — and the contract does the coordination.

This is why multisig is battle-tested: Safe alone has secured well over $100B in assets across years of adversarial conditions, and the contract logic is open source and heavily audited. It's also why it's slow for automated trading. Every transaction is visible in the mempool before execution, gas cost scales with signer count (each approval that goes on-chain is its own transaction), and you can't realistically get a bot to wait on human-speed confirmations for every trade.

How MPC actually works

Threshold-signature MPC doesn't touch the contract layer at all — from the chain's perspective, an MPC wallet looks exactly like a normal EOA producing a normal signature. The private key never exists in one place. It's generated as key shares distributed across separate parties (servers, HSMs, or a decentralized network of nodes), and signing happens through a cryptographic protocol — commonly GG18/GG20 for threshold ECDSA or FROST for Schnorr/EdDSA — where a threshold of shares jointly compute a valid signature without ever reconstructing the full key on any single machine.

Because the output is a single standard signature, MPC works with any contract, any chain, no special wallet contract needed, and signing latency is milliseconds instead of block times. That's why it's the default for exchange custody and for bots that need to self-sign at high frequency without a human in the loop.

A concrete example: what changes for a bot

Say your strategy engine needs to submit a swap the moment a signal fires. With Safe, you'd need pre-approved session keys or a module like Zodiac's role-based execution to avoid a live confirmation round trip — workable, but it's extra contract surface to get audited. A basic proposal flow with the Safe SDK looks like this:

import Safe from '@safe-global/protocol-kit';

const safe = await Safe.init({
  provider: RPC_URL,
  signer: BOT_SIGNER_KEY,
  safeAddress: SAFE_ADDRESS,
});

const tx = await safe.createTransaction({
  transactions: [{ to: DEX_ROUTER, value: '0', data: swapCalldata }],
});
const signed = await safe.signTransaction(tx);
await safe.executeTransaction(signed); // needs threshold already met, or reverts

With MPC, the bot calls a signing API, the threshold nodes compute the signature in the background, and the resulting transaction is broadcast the same way a normal wallet would broadcast it — no contract-level approval step, no extra calldata, no extra gas.

Multisig vs MPC, side by side

Dimension	Multisig (Safe / Squads)	MPC (TSS-based)
Signing latency	Seconds to minutes (human approvals)	Milliseconds, automatable
On-chain footprint	Contract account, visible threshold logic	Looks like a normal EOA
Gas overhead	Scales with signer count and approvals	None extra — single signature
Transparency	Fully on-chain, auditable by anyone	Off-chain protocol, trust the vendor/implementation
Chain support	Per-chain deployment (Safe ≠ Squads)	Works across chains with the same key material
Vendor dependency	None — open contracts, self-hosted UI possible	Usually yes, unless you build TSS in-house
Best fit	Treasury, withdrawal wallet, governance	Hot execution wallet, high-frequency signing
Typical setup cost	Low — deploy contract, wire up signing UI	Medium to high — vendor subscription or custom crypto engineering

Cost and complexity, honestly

Deploying a Safe or Squads vault is close to free. The contracts are already deployed and audited; the work is integration — proposal flow, signer onboarding, maybe a Zodiac module for scoped bot permissions. A competent developer can wire this up in days, and if you want a second set of eyes on the module logic before real funds move through it, that's exactly the kind of narrow, high-stakes review worth commissioning as a code review and audit rather than skipping.

MPC is a different cost profile. Managed providers like Fireblocks or Turnkey charge per-signature or a flat enterprise fee that starts in the tens of thousands annually for serious volume — but you're buying HSM-backed infrastructure and a compliance-ready audit trail, which matters if you're custodying client funds. Rolling your own TSS with GG20 or FROST is a legitimate option only if you have cryptography engineering depth on staff; get the resharing or nonce-generation logic wrong and you've built a key exfiltration bug, not a security feature. This isn't a weekend project for a generalist backend developer.

Either path benefits from ongoing key rotation, signer offboarding, and monitoring — the kind of operational discipline that's easy to skip after launch and expensive to skip after an incident. That's the argument for treating custody as a maintained system, not a one-time setup, which is where ongoing support and maintenance earns its keep instead of a Slack thread six months later titled "who still has signing access."

The gotchas that actually bite

The Bybit incident in early 2025 is the cleanest cautionary tale: signers approved what looked like a routine Safe transaction through a compromised interface, and the displayed transaction didn't match what actually executed on-chain — roughly $1.5B moved out of a cold multisig wallet. The threshold logic worked exactly as designed. The failure was that humans verified a UI, not calldata. Any multisig setup that doesn't independently decode and verify raw transaction data before signing has the same exposure, threshold or not.

MPC has its own quiet failure mode: collusion risk isn't eliminated just because key shares are split, if the parties holding those shares run on the same cloud account, same admin, or same jurisdiction under one subpoena. A 2-of-3 MPC setup where you don't control any of the three nodes is custodial in every way that matters, regardless of the cryptography underneath.

Neither model protects against a compromised price feed feeding your bot bad signals to trade against, which is a separate class of risk worth reading up on if you haven't compared oracle providers for Solana perps — and neither protects your capital if your bot's execution venue itself takes on cascading liquidation risk, the way Hyperliquid's HLP vault absorbs counterparty exposure during large unwinds. Custody is one layer of a stack, not the whole stack.

The verdict

Don't pick one. Use MPC for the hot wallet that signs trades in real time, where latency and automation matter more than on-chain transparency, and use multisig for the treasury and withdrawal wallet, where you want slower, auditable, human-in-the-loop control over anything that moves capital out of the system. A single strategy running under a few dozen trades a day can get away with multisig everywhere and skip the vendor cost. Anything running at real frequency needs MPC on the execution path or it'll be bottlenecked by its own security model.

If you're deciding which of these to implement and don't want to find out the hard way which threshold logic has a gap, get a code review and audit on the custody design before it holds real capital.