How should a team or company hold crypto safely: hot wallets, cold wallets, multisig or MPC?

A company should never hold meaningful crypto behind a single key that one person controls. The standard setup is a small hot wallet for day-to-day payments, holding only what you can afford to lose, and a treasury secured by several keys on hardware devices held by different people in different places. Those keys are combined through either a multisig wallet or MPC threshold signing, with written policies about who can move what, and a tested recovery plan. Which tools you pick matters less than making sure no single person, device or web page can move the money alone.

Custodial or self-custody

The first decision is who holds the keys.

	Custodial (exchange or qualified custodian)	Self-custody
Who holds keys	A third party	Your team
Main risk	Custodian failure, insolvency, freezes	Your own operational mistakes
Operational load	Low	Moderate to high
Access to DeFi and on-chain operations	Limited	Full
Fits	Regulated entities, funds with custody requirements, teams without security staff	Protocols, DAOs, crypto-native teams

Many companies use both: a regulated custodian for the bulk of reserves and self-custody for operational funds. If you use an exchange, treat it as a hot wallet you don't control. Exchange failures, from Mt. Gox to FTX, have repeatedly shown the risk of leaving balances there.

Hot and cold

• A hot wallet has keys on an internet-connected machine: a server, a browser extension, a cloud KMS. It's convenient, and it's the first thing attackers target.
• A cold wallet keeps keys on a device that never exposes them to a networked computer, typically a hardware wallet. The device signs internally and displays what it's signing for confirmation.

Hardware wallets protect the key, not the decision. If the signer approves a malicious transaction on the device, it will sign it. Most large losses from cold setups happen this way, not through extracted keys.

Multisig: several keys on-chain

A multisig requires m of n keys to authorise a transaction, and the chain itself enforces the rule.

On EVM chains the standard is Safe (formerly Gnosis Safe), a smart contract wallet with a list of owners and a threshold. Owners sign off-chain, and once enough signatures are collected, anyone can submit the transaction. Safe also supports modules and guards that add rules such as spending limits or delays.

On Bitcoin, multisig is native script. Modern wallets describe it with an output descriptor:

wsh(sortedmulti(2,
  [a1b2c3d4/48h/0h/0h/2h]xpub6E...Alice/0/*,
  [e5f6a7b8/48h/0h/0h/2h]xpub6F...Bob/0/*,
  [c9d0e1f2/48h/0h/0h/2h]xpub6G...Carol/0/*))

That's a 2-of-3 native SegWit multisig, with line breaks added for readability. The bracketed parts are each key's master fingerprint and derivation path. Back up the full descriptor, including all three xpubs, with each key. A single seed phrase can't rebuild a multisig wallet without the other public keys. Taproot multisig also exists, using tr() descriptors with multi_a, but check that every wallet you use supports it.

MPC: one key, split into shares

Multi-party computation (MPC) wallets, also called threshold signature (TSS) wallets, never create a whole private key. Several parties hold key shares and run a protocol that produces one ordinary signature when enough of them cooperate.

	Multisig	MPC / TSS
Where the rule lives	On-chain (contract or script)	Off-chain, in the signing protocol
On-chain footprint	Visible multisig, higher fees	Looks like a single-key wallet
Chain support	Per chain; needs contract or script support	Any chain with a supported signature scheme
Rotating a signer	New owner set or new address	Refresh shares, same address
Main risks	Contract bugs, signing UI trust	Cryptographic implementation bugs, vendor dependence
Transparency	Anyone can audit the policy on-chain	Only the vendor and the parties see the policy

MPC is attractive for exchanges and companies operating on many chains. Researchers have published vulnerabilities in several TSS implementations, so vendor quality matters a great deal. Multisig on Safe or Bitcoin script is more transparent and uses battle-tested code. Plenty of teams combine them, for example an MPC-held key serving as one owner of a Safe.

Choosing a threshold

Setup	Tolerates	Typical use
2-of-3	Loss of 1 key, compromise of 1 key	Small teams, founders' treasury
3-of-5	Loss of 2 keys, compromise of 2 keys	Company or protocol treasury
4-of-7 and up	More of both	Large treasuries, protocol admin keys

Avoid n-of-n: one lost key freezes everything. Avoid 1-of-n: any one compromised key drains everything. The threshold should be high enough that an attacker must compromise several independent people, and low enough that you can still sign when someone is on holiday or has left.

Independence is the whole point. Keys should be held by different people, on different device models if possible, stored in different buildings or cities, and not all reachable through the same laptop, email account or password manager. Five keys on five devices in one office safe amount to a single key.

Policies that limit damage

• Spending limits: small, pre-approved amounts can move with fewer approvals. Everything else needs the full threshold.
• Allowlists: funds may only go to pre-registered addresses, and adding an address needs its own approval and delay.
• Timelocks: large transfers or configuration changes wait a set period (for example 24–72 hours) before executing, so the team can cancel a malicious one. On Safe this is done with a delay module.
• Separation of roles: the people who propose payments aren't the only ones who approve them.
• Monitoring: alert on every proposal, signature and execution, and on any owner, threshold or module change.

Blind signing and transaction simulation

In February 2025, attackers stole roughly $1.5 billion in ETH from Bybit's cold Safe wallet. The Safe contracts were not broken. The attackers had compromised the Safe web interface and served Bybit's signers a doctored transaction. The screen showed a routine transfer, but signers actually approved a delegatecall that replaced the wallet's logic and handed control to the attacker. The hardware wallets showed data the signers couldn't meaningfully check.

This is blind signing, and a higher threshold doesn't fix it if every signer trusts the same web page. Defences:

1. Verify on the device. Use hardware and firmware that decode transactions (clear signing). Compare the hashes the device displays with ones recomputed independently by an open-source Safe hash tool.
2. Check the operation type. On Safe, operation = 1 means delegatecall, which should essentially never appear in a normal treasury transfer.
3. Simulate first. Run the exact transaction through a simulator and read the resulting balance and state changes, not just the method name.
4. Use more than one interface. At least one signer should verify through a separate frontend, CLI or self-hosted UI.
5. Slow down large transfers. A timelock turns a successful deception into a cancellable proposal.

Recovery and succession

• Record who holds which key, where backups live, and the full wallet configuration (Safe address and chain, or Bitcoin descriptor).
• Store seed backups on durable media, separate from the devices, under the same independence rules.
• Run a recovery drill at least yearly: restore a key from backup and sign a test transaction.
• When someone leaves, rotate their key out the same week. Don't just collect their device.
• Plan for death or incapacity. A lawyer or trusted party should be able to trigger a documented process without ever holding enough keys to act alone.

A decision guide by treasury size

Treasury	Suggested setup
Under $10k	Reputable exchange or a single hardware wallet with a tested backup
$10k–$250k	2-of-3 multisig on hardware wallets, held by different people
$250k–$10M	3-of-5 multisig or institutional MPC, allowlists, a separate hot wallet for operations, simulation on every transaction
Over $10M	3-of-5 or higher across locations, timelocks, independent verification UI, monitoring, possibly a qualified custodian for part of the reserves, and regular external security reviews

Start with the question every design must answer: which people, devices and software would an attacker need to compromise to move the money? If the answer is "one", fix that first.