Do Multisig Wallets Actually Improve Security? A Threat-Model View

Multisignature wallets—wallets where M-of-N keys must sign before a transaction is valid—are usually presented as the obvious upgrade from a single-key hot wallet. Most treasury setups in DAOs, exchanges, and serious crypto-native companies run through some flavor of multisig (Safe, Squads, Multisig.js, threshold-signature variants).

That reputation is well earned, but only against a specific threat model. Multisig defeats some of the most common ways funds get stolen and does almost nothing against others. Below is the honest version: what multisig is actually good at, where it falls short, and the cases where adopting it can make a setup less safe.

What multisig is, very briefly

In a 2-of-3 multisig, three private keys exist; any two of them must sign a transaction for it to execute on-chain. The wallet itself is a smart contract (in the Ethereum / EVM world) or a native multisig output type (in Bitcoin via P2SH/P2WSH). The contract verifies the signatures and then forwards the transaction.

The most widely used implementation in EVM ecosystems is Safe (formerly Gnosis Safe). On Solana, Squads plays the same role. Bitcoin has a long history of native multisig support, often combined with hardware wallets through PSBT workflows.

Threshold-signature schemes (TSS, FROST, MPC) achieve a similar outcome with a single on-chain key—each signer holds a share of the private key and they sign jointly without ever reconstructing it. From a threat-model perspective most of the points below apply equally to both, with a few caveats noted later.

What multisig defeats (the good news)

Single-key compromise

This is the headline benefit. If one signer's hardware wallet is stolen, one signer's phone is malware-infected, one signer's seed phrase leaks, an attacker holding that single key cannot move funds. They need to compromise at least M-1 other keys at the same time.

For a 2-of-3 setup, this means the attacker must compromise two independent endpoints, ideally held by different people, on different hardware, in different physical locations. The probability of two independent compromises in the same window is usually orders of magnitude lower than the probability of one.

Insider risk

A single person with full custody can rage-quit, defect, get coerced, or simply make a catastrophic mistake. Multisig forces collusion. For DAOs and companies, this is often the primary motivation—the security benefit against external attackers is secondary to the governance benefit against any one internal actor.

Lost-key recovery

In an M-of-N setup with N > M, losing one key is not catastrophic. The remaining signers can move funds to a fresh multisig and replace the lost key. This is a meaningful improvement over single-key custody, where one lost seed phrase means permanent loss.

Phishing the user

Many wallet phishing attacks (fake airdrop sites, malicious token approvals, drainer contracts) rely on the user signing a malicious transaction in a single browser session. A multisig adds a confirmation step at a different surface—a coordinating UI like Safe's, or a hardware approval on multiple devices—which gives the user another moment to notice that they are signing something they did not intend.

What multisig does not defeat (the uncomfortable part)

This is the section most quick takes skip.

Smart-contract bugs in the multisig itself

The multisig is a smart contract. If the contract has a bug, all the careful key management in the world does not help. The most expensive multisig incident in history—the Parity multisig freeze in November 2017—was a contract bug, not a key compromise. About $150M worth of ETH was rendered permanently inaccessible by a single transaction.

Modern Safe is one of the most audited contracts on Ethereum and has held up well, but the point stands: you are trading "one private key to protect" for "one smart contract to trust." That trust must be earned and re-earned with audits and time.

Compromise of the signing UI

Almost every multisig sign-off happens through some interface—Safe's web UI, a wallet plugin, a custom dashboard. If that interface is compromised (DNS hijack, supply-chain attack on a dependency, malicious browser extension), the attacker can show signer A "send 1 ETH to alice.eth" while actually transmitting "send 1000 ETH to attacker.eth" to the hardware wallet for signing.

Most hardware wallets do display the actual destination address, but signers routinely skim. The Bybit incident in early 2025 hinged on a Safe UI compromise; all signers approved what they thought was a routine transaction, while the proxy contract was being modified.

Multisig protects you against an attacker who only has one key. It does not protect you against an attacker who can put the wrong transaction in front of all your signers.

Coordinated phishing of multiple signers

If the signers are known and reachable—and for any treasury with a published Safe address, they usually are—an attacker can target all of them. Run the same phishing campaign at each signer. Wait. If two out of three are tired, distracted, or off-guard on the same day, the threshold is reached.

This is the most realistic attack against well-run multisigs in practice, and the defenses against it are mostly procedural, not technical: out-of-band confirmation of every transaction in a separate channel (Signal, a different chat, a phone call), and a strict policy that any transaction over $X must be discussed live before signing.

Off-chain key storage compromise

If the "signing keys" are actually 2-of-3 between two engineers' MetaMask seed phrases and one hardware wallet in the office safe, you have an OPSEC problem dressed as a multisig. The threshold is technically met, but the diversity is fake. A laptop-malware infection on two engineers' machines, or a single break-in to the office, can compromise the threshold.

Real diversity requires:

• Different hardware models. (One Ledger, one Trezor, one Keystone.)
• Different operating systems for any software signing.
• Different physical locations for any persistent storage.
• Different humans, where applicable, with different threat profiles.

Loss past the threshold

The other side of recovery: in a 2-of-3, losing two keys is permanent loss. In a 3-of-5, losing three is permanent loss. The bigger the gap between M and N, the safer against single losses—but the easier for an attacker to find M signers to phish.

This is the unavoidable tension. Higher M is more secure against external attack and less recoverable. Lower M is more recoverable and easier to attack. There is no setting that optimizes both.

Where multisig can make things worse

A few honest cases:

• For very small balances, the operational overhead of multisig (transaction coordination, gas costs on EVM, learning curve) can produce mistakes that single-key custody would not have. The right tool for $200 of pocket-money crypto is a hardware-backed single key.
• For solo users who treat multisig as a recovery scheme but in practice keep all three keys on devices they alone control, multisig adds complexity without changing the threat model—if a single attacker compromises one of those devices today, they probably can compromise them all.
• For organizations that do not actually have signer diversity—everyone in the same office, on the same VPN, using the same SSO—the threshold becomes a formality.

In all three cases, the answer is not "use single-key custody." It is "use multisig correctly or use a custodian who does." But pretending the contract type alone delivers safety, regardless of operational practice, is how the high-profile losses happen.

What good looks like

A 2-of-3 or 3-of-5 multisig works well as a treasury control when all of the following are true:

• Signers are different humans, in different jurisdictions where possible.
• Signing devices are different hardware brands, on different OSes.
• A separate communication channel is used for transaction confirmation, independent of the signing UI.
• A documented process exists for verifying the transaction payload against an expected diff—calldata, target, value—before any signer approves.
• The multisig contract itself is well-audited (Safe is the conservative default in 2026) and the version is pinned and known.
• A signer replacement procedure exists and has been rehearsed.

This is more discipline than most teams realize at the outset. The good news is the discipline is one-time investment; the bad news is the discipline matters more than the contract.

How this connects to domains

Naming is one of the strongest analogies to multisig in the off-chain world. A domain controlled by a single registrar account behind a single password is a single-key wallet. A domain protected by registrar lock + registry lock + 2FA at the DNS provider + multiple authoritative providers is, structurally, a multisig: multiple independent factors must each be compromised before the name moves.

Namefi takes this further by representing ownership as an on-chain record that can be held in a multisig wallet directly. The same threshold scheme that protects a treasury can now protect the DNS control plane—so a single phished individual cannot lose the company's domain any more than they can drain the treasury alone. The threat model upgrade is the same in both worlds: replace "trust one credential" with "compromise M of N independent factors."

Sources and further reading

• Safe — Smart account contracts and audits.
• IETF FROST — RFC 9591, the Flexible Round-Optimized Schnorr Threshold protocol.
• Bitcoin — BIP-174 PSBT.
• Parity — Multisig freeze post-mortem.
• a16z crypto — Practical guide to running a Safe multisig.