Multisig Wallets: How Shared Crypto Custody Actually Works

A multisig wallet shares crypto custody by requiring more than one approval before funds can move, rather than trusting a single private key. Most explanations stop at "multiple keys are required" and skip the part that actually matters: whether that makes your crypto safer, and what new responsibilities it puts on you.

If you have read a few multisig explainers and still cannot tell whether you actually need one, that is a reasonable place to be. The concept gets described two ways that do not quite fit together: as a near-magic security upgrade, and as something only companies and DAOs use. At Blockready, the approach is to understand how a custody system works before deciding whether to adopt it, because the same setup that protects a treasury can lock an individual out of their own funds. This article walks through the mechanism, the tradeoffs, and the questions worth asking before trusting one.

What a multisig wallet actually is

Start with the wallet you probably already know. A standard, single-signature wallet controls funds with one private key. Whoever holds that key can move the assets, and if it is lost or stolen, the funds usually go with it. That single key is the whole security model, which is why protecting the private key is the foundation of wallet security. If you are still building the basics of how a crypto wallet stores keys and authorizes transactions, that single-key picture is the right starting point.

A multisig wallet changes that rule.

So a 2-of-3 wallet has three keys, but only two are needed to authorize a transaction. The third key can sit in reserve. This is the source of multisig's appeal: one key can be lost without losing access, and one stolen key is not enough to move funds on its own. The shorthand is worth memorizing, because almost every multisig decision comes back to choosing M and N.

M-of-N, and why 2-of-3 shows up so much

The threshold you pick is a design decision, not a difficulty slider where higher numbers are always safer. Each configuration trades one kind of risk for another.

A 2-of-3 setup is popular because it balances two failure modes. You can lose any one key and still spend with the other two, and an attacker who steals one key still cannot move funds alone. That same balance is why a 2-of-3 arrangement was one of the original motivating examples for Bitcoin multisig, used to describe a buyer, a seller, and an escrow agent who only needs two of the three to agree.

Other thresholds make sense for other goals. A 3-of-5 setup gives a team or treasury more resistance to a single compromised signer, at the cost of more coordination. A 2-of-2 forces two parties to agree on everything, but a single lost key can freeze the funds. An m-of-m setup, where every key must sign, maximizes consent and also maximizes lockout risk. There is no universal best. The right threshold depends on how many keys you can realistically protect, how many people you trust to be available, and what happens if one of them disappears.

This is where the stakes become concrete. A misconfigured threshold does not announce itself. A 2-of-2 wallet looks fine right up until one key is lost and the funds become permanently unspendable. A 1-of-2 wallet feels convenient until you realize either key alone can drain it. The mechanism is only as good as the design choices around it, which is exactly why multisig deserves more thought than a number you copy from a tutorial.

Single-signature versus multisig

Put side by side, the difference is less about "more secure" and more about where the responsibility sits.

Same idea, different machinery: Bitcoin script versus Ethereum smart accounts

Here is a distinction most explainers blur. Multisig is not one technology. The shared-approval idea is implemented in genuinely different ways depending on the chain, and treating them as the same is a common source of confusion.

On Bitcoin, multisig is a script condition, not a separate kind of account. The standard for M-of-N spending was defined in Bitcoin Improvement Proposal 11, which introduced multisignature transactions and the script operation that checks them, using a 2-of-3 escrow as its motivating example. A later proposal, Pay to Script Hash, made it practical to fund these complex conditions without the sender needing to know the full spending rule in advance. To collect approvals across separate devices, Bitcoin wallets exchange a partially signed transaction, a format standardized in the PSBT specification, passing it from signer to signer until enough have signed. No smart contract is involved.

On Ethereum, multisig usually works through a smart contract account. Safe is the widely used example. According to Safe's own documentation, the account stores a list of owner addresses and a threshold value, and it executes a transaction only after at least that many owners have provided valid signatures. The important detail is that this account is a contract. It has no single private key of its own, so the contract's code is what enforces the rule, and that code can include modules, upgrade paths, and other logic that a plain Bitcoin script does not have.

Why does this matter? Because it changes where the risk lives. Bitcoin script multisig keeps the attack surface narrow and well understood. Ethereum smart-account multisig is more flexible, and that flexibility adds a contract layer that itself has to be trusted and maintained. Neither is simply better. They solve the same custody problem with different tools, and the phrase "all multisig wallets are smart contracts" is inaccurate the moment you look at Bitcoin.

There is a practical consequence for anyone approving a transaction. On Bitcoin, what you sign is close to the raw spending condition, so there is less hidden behavior to misread. On a smart-account multisig, you are usually approving a call into contract code, which can do more than a plain transfer. That extra capability is genuinely useful, and it is also why careful transaction review becomes more important, not less, as the setup grows more flexible.

What multisig reduces, and what it adds

The single most useful way to think about multisig is as a risk transfer. It removes one specific failure point and, in exchange, introduces a system you now have to operate correctly.

Read that as a trade, not an upgrade. You are exchanging "protect one key perfectly" for "design and maintain a signing system safely." For some holdings that trade is clearly worth it. For others it adds complexity a person cannot realistically operate, which is its own kind of risk. The cost is also ongoing rather than one-time. Keys have to stay separated, backups have to stay current, and at least one signer has to remain reachable when funds need to move. A setup that is sound on day one can drift into fragility if that upkeep quietly lapses.

Where shared custody still goes wrong

Multisig fails in predictable ways, and almost none of them involve breaking the cryptography. The threshold math is rarely the weak point. The setup, the storage, and the signing process are.

The "approving what you cannot verify" failure is worth slowing down on, because it produced the largest crypto theft on record. On February 21, 2025, attackers stole roughly $1.5 billion in crypto from Bybit, an event the FBI attributed to North Korean actors it tracks as TraderTraitor. Bybit's cold wallet used a multisig setup that required several signers. The threshold was never broken. Instead, as NCC Group's technical analysis describes, the signing interface was manipulated so that signers saw a routine transfer while approving a transaction that handed control of the wallet to the attackers. Every signature was valid. The signers were simply deceived about what they were signing. The full chain of events is worth reading in our breakdown of how the Bybit hack actually happened.

This is the lesson that sits underneath multisig: a valid signature is not the same as a correct transaction. A protocol cannot tell the difference between a deliberate approval and a deceived one. It only sees that the threshold was met. This is also why verifying a transaction on a hardware wallet's own screen, sometimes called clear signing, matters so much. The control that would have broken the Bybit attack was signers confirming the real transaction on a device independent of the manipulated interface.

It is worth naming a common and very human mistake here, because almost everyone who sets up multisig feels the pull toward it. After the effort of creating three keys, it is tempting to store them, and their backups, somewhere convenient and together. That single decision quietly turns a 2-of-3 wallet back into a single point of failure. This happens not because people are careless, but because the threshold feels like the security, so the storage feels like an afterthought. Understanding that the backups and signer separation are part of the security model, not paperwork around it, is what separates a multisig that protects funds from one that only looks like it does.

There is a quieter version of the same problem. Multisig assumes the required signers stay reachable. A 3-of-5 treasury where two signers leave a project, lose a key, or stop responding can slide below its own threshold with no attacker involved at all. Availability is part of security in a multisig design, and it is easy to overlook on setup day when every signer is present and responsive.

Multisig, MPC, and social recovery are not the same thing

Search results blur three mechanisms together because they all aim to reduce single-key risk. They work differently, and confusing them leads to bad decisions.

The practical takeaway is that "multisig" and "MPC" are often marketed as interchangeable, and they are not. Multisig enforces approvals through a visible on-chain rule. MPC reduces single-key risk off-chain, inside the signing process, and produces one signature. Social recovery answers a different question again: not "who approves this payment," but "how do I get back in if I lose a key." Knowing which problem a product actually solves is the difference between buying the right tool and trusting the wrong assumption.

Who actually needs multisig?

Multisig earns its complexity when it removes a real failure mode you would otherwise face. A shared treasury for a team or DAO, where no single person should be able to move funds alone, is a strong fit. So is a high-value personal holding where one key feels too fragile to be the only thing standing between you and total loss. Inheritance and continuity planning is another case, where a threshold can let a trusted person help recover funds without handing them full control today. Before any of that, the underlying custody question is the same one covered in what self-custody actually means and the tradeoffs it carries.

It is also genuinely possible to over-engineer. A beginner with a small balance who adopts a 3-of-5 setup has not bought safety. They have bought five keys to protect, five backups to manage, and several new ways to lock themselves out, in exchange for guarding an amount that did not need that machinery. Multisig is not a status upgrade. It is a tool matched to a specific threat model. The better question is not whether multisig is more secure in the abstract. It is whether the specific failure multisig removes is one you actually face, and whether you can run the resulting system without introducing a worse failure. For a small balance held by one person, a well-protected single key with a tested backup can answer the real threat more reliably than a complex threshold nobody rehearses.

This is also where structured learning helps more than a single article can. Multisig sits on top of custody fundamentals, and those fundamentals are easy to skip when you jump straight to a fancy setup. Blockready's Wallets module works through custodial versus non-custodial wallets, seed phrases, private keys, and hot versus cold storage as separate steps, because shared custody only makes sense once those basics are solid. If you want to see how that sequence is laid out, the structured crypto curriculum shows where wallets and custody fit in the wider path.

Frequently Asked Questions