Multisig Best Practices in 2026: More Signers Is Not Safer

The year multisig stopped being a magic word

When roughly $116 million in Bitcoin drained out of Coldcard hardware wallets during the first two weeks of August 2026, the reflex across crypto social media was immediate and familiar: move to multisig, split the keys, never let one device hold everything. Within days, Ledger chief technology officer Charles Guillemet pushed back. Rushing into a setup you do not fully understand, he argued, can add risk rather than remove it. His verdict, posted to a large following, was blunt: “Multisig is not automatically the right answer.”

That is an unusual thing to hear from an executive whose own company sells a multisig product, which is exactly why it is worth taking seriously. The Coldcard theft, which TRM Labs put at about 1,816 BTC (roughly $116 million) taken from more than 5,200 addresses across four waves, was the third largest crypto hack of the year. It was also a hardware entropy failure, not a multisig failure. Yet the panic it set off exposed a habit worth breaking: treating the word multisig as a spell that makes theft impossible.

It is not. A multisig wallet is a process wearing the costume of a product. Operated well, it is the strongest single control most treasuries can deploy. Operated casually, it splits one point of failure into several, hands them to people who were never trained to hold them, and adds coordination steps that attackers have learned to exploit. The record of the past two years is unambiguous. The biggest multisig thefts did not break any cryptography and did not require stealing a private key. They defeated the humans and the screens around the keys. This guide covers the practices that actually change outcomes, and the moments when the right answer is not multisig at all.

What a multisig actually is, and what it is not

A multisig (multi-signature) wallet requires M signatures from N authorized keys before it will release funds. A 3-of-5 wallet needs any three of its five keyholders to approve a transaction. The purpose is fault tolerance: lose one key and you can still spend; have one key stolen and the thief still cannot move anything. On Ethereum and other EVM chains, the dominant implementation is a smart contract, most often Safe (formerly Gnosis Safe), which reported more than 63 million accounts and about $39.35 billion in transfer volume in the second quarter of 2026; the network held roughly $35.25 billion in assets at the end of the first quarter. On Bitcoin, multisig lives in the spending script, increasingly expressed through Miniscript, a structured language for spending conditions that a hardware wallet can display and check.

It helps to be precise about what a multisig is not. It is not multi-party computation (MPC), where a single signature is assembled from key shares split mathematically off-chain; to the blockchain, an MPC wallet looks like an ordinary single-signer address. It is also not custody in the legal sense. Holding keys in a multisig tells you who can move funds, but as our analysis of control versus ownership in crypto custody explains, who controls a transaction and who legally owns the asset are separate questions, and confusing them is how people end up surprised about their rights after a loss. A multisig is a technical control over authorization. The recovery, the accountability, and the recourse are things you assemble around it, not properties it provides by default.

Five multisigs, billions gone, not one broken key

The argument for taking operational security seriously is written in the ledger. Look at the five largest multisig-related thefts of the current cycle. In every one, the smart contract behaved exactly as designed and the private keys were never cracked. What failed was the layer between the signer and the chain: a manipulated interface, a transaction signed in advance, a backup that quietly folded two thresholds into one laptop.

The pattern is the point. TRM Labs, reviewing the first half of 2026, found that smart-contract exploits were the most common kind of incident but a small share of the money, while infrastructure, key, and operational compromises made up about 15 percent of incidents and roughly 76 percent of the value stolen. The costly failures are not the subtle contract bugs our rundown of what breaks crypto in 2026 catalogs; they are operational. To its credit, Bybit responded with unusual transparency, its chief executive Ben Zhou stating on the day of the theft that “Bybit is Solvent even if this hack loss is not recovered, all of clients assets are 1 to 1 backed, we can cover the loss.” Solvency is not the same as prevention. In each case above, the multisig was, technically, doing its job.

Best practice starts with a threat model, not a template

The most useful thing Guillemet said in August was not the warning itself but the reason behind it. Security decisions, he argued, should follow from a person or organization’s threat model rather than from the latest headline. A multisig is a defense against specific attacks: a single stolen key, a single coerced signer, a single compromised device. It is not free. It costs coordination, adds recovery complexity, and creates new ways to lock yourself out. If the attacks you actually face are phishing and malware on one machine, a well-configured single-signature hardware wallet with clear signing may protect you better than a five-key setup you cannot operate under pressure.

For Bitcoin holders specifically, Guillemet pointed to alternatives that sit between single-sig and full multisig: Bitcoin Miniscript for advanced spending rules such as inheritance and time-locked recovery, the MuSig2 signature scheme, and clear signing on every spending path. For most individuals, he argued, a properly backed-up single-signature wallet remains the most practical choice. None of this is an argument against multisig. It is an argument against adopting one reflexively. Before you design thresholds and buy devices, write down what you are defending against, who your adversary realistically is, and what happens on your worst day: a lost key, a dead signer, a suspected compromise in the middle of a transaction. Every practice that follows should trace back to that document.

Threshold design: the M-of-N math that survives a bad day

Once you have decided a multisig fits, the first design choice is the ratio of signatures to keys. Two failure modes bound the problem. Set the threshold too low and a small number of compromised keys drains the wallet; set it too high, or make it N-of-N, and a single lost or unavailable key freezes your funds forever. The Security Alliance’s secure multisig guidance gives a workable floor: at least three signers, a threshold above 50 percent, no N-of-N configurations, and seven or more signers once a wallet holds over $1 million. Polygon’s engineering team offers similar rules of thumb scaled to the value at stake.

The right ratio buys you a margin for human error, not just for attackers. A 4-of-7 treasury can lose a laptop to a spilled coffee, put a signer on a plane with no connectivity, and offboard a departing employee, all in the same week, and still move funds. That margin is the entire reason to run a multisig. If your configuration cannot survive one ordinary bad day without either freezing or falling to a single compromise, the threshold is wrong before you have signed anything.

Signer diversity is the whole game

A threshold only means something if the keys behind it fail independently. This is where most real-world multisigs quietly collapse back into single points of failure. Humanity Protocol ran a nominal 3-of-6 on Ethereum and 3-of-5 on BNB Chain, two independent thresholds on paper. In practice, several keys from both chains had been backed up to one employee’s laptop, so a single device compromise crossed both thresholds at once. Founder Terence Kwok was candid afterward that some of the keys had been accidentally backed up to a compromised device during setup. Six keys on one laptop is a 1-of-1 wearing a 3-of-6 costume.

Real diversity means separating keys along every axis an attacker could collapse: different people, different hardware wallet models from different manufacturers, different physical locations, and at least one signer outside your own organization. It extends to software too, because if every signer runs the same wallet client on the same operating system, one supply-chain compromise reaches all of them, the exact mechanism behind the Bybit interface injection. Vitalik Buterin has framed signer selection as the heart of the problem, writing that “Two key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them?” Getting the second question right, the instructions, is what the rest of this guide is about.

The signing device: hardware is necessary, not sufficient

Every serious multisig signer should be a dedicated hardware wallet, ideally one that stays air-gapped and is used for nothing else. That much is standard advice, and choosing among the leading hardware wallets in 2026 is a real decision with real trade-offs. But the Coldcard incident is a hard reminder that a hardware wallet is necessary, not sufficient. The theft did not require touching the devices. A build configuration error shipped in a March 2021 firmware release caused seed generation to fall back from the chip’s hardware random number generator to a weak software routine, cutting effective entropy from a designed 128 bits to as little as 40 bits, enough for attackers to reconstruct seeds remotely. The first wave alone drained roughly $70 million in 41 minutes.

Two lessons carry over to multisig design. First, seed generation is part of your threat model, not a solved problem you can assume away; a multisig of five devices that all generated weak seeds is five weak keys, not one strong wallet. Second, patching does not undo a bad seed. Coinkite shipped fixed firmware within a day, but any seed created on the flawed builds had to be abandoned and funds moved to a fresh one; updating the device does not retroactively make a predictable key unpredictable. Coinkite co-founder Rodolfo Novak tied the root cause to a broader shift, noting that “AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts.” The devices in your multisig are only as trustworthy as the code that generated their keys, and that code is now under machine-speed scrutiny by both defenders and attackers.

Clear signing and the display-layer attack surface

If there is a single technical lesson from Bybit, WazirX, and Radiant, it is that the display is the attack surface. In each, signers approved a transaction that the interface misrepresented; the malicious payload lived beneath a screen that showed something benign. This is blind signing: authorizing a data blob you cannot actually read. As our piece on why the signature itself has become the exploit details, the modern attacker rarely needs your key when it can get you to sign for the theft yourself.

The counter is clear signing: rendering a human-readable description of exactly what a transaction does on the hardware wallet’s own trusted screen, so signers approve what they can read rather than a hex string. In May 2026 the Ethereum Foundation took stewardship of a coordinated Clear Signing standard from Ledger, built around ERC-7730, a JSON format for readable transaction descriptors, plus a shared registry, an attestation framework so independent auditors can vouch that a descriptor is accurate, and a calldata digest that lets a wallet show a short fingerprint a signer can recompute on a separate device and compare.

For multisig operators, the practical rules are concrete:

• Never sign what your hardware wallet cannot show you in cleartext; an unreadable payload is a refusal, not a formality.
• Always verify the raw calldata (the target contract, the function being called, and the parameters) against what the operation is supposed to do.
• Recompute the transaction hash on a clean, independent device and compare it to what each signer sees, using an offline verification tool rather than trusting a single interface.
• Treat any interface that cannot produce a verifiable, human-readable description as untrusted, no matter how familiar it looks.

Timelocks, monitoring, and out-of-band verification

A threshold decides who can sign. A timelock decides when the signature takes effect, and that delay is often the difference between an incident and a catastrophe. Drift Protocol is the cautionary tale. Days before its April 2026 theft, its Security Council migrated to a 2-of-5 configuration with no timelock at all. Attackers had spent months socially engineering signers into pre-signing durable-nonce transactions, a legitimate Solana feature that lets a transaction be signed once and executed later. Removing the timelock erased the detection window, so when the pre-signed transactions fired there was no delay in which anyone could notice and intervene, and roughly $285 million left in one motion.

A mandatory delay on sensitive actions (ownership transfers, module changes, large withdrawals) gives your monitoring time to work. That monitoring should be active, not aspirational: real-time alerts on every proposed and executed transaction, on signer or threshold changes, and on any interaction with the multisig’s admin functions, routed to a channel humans actually watch. Pair it with out-of-band verification for anything material. Before a large transfer, signers should confirm the transaction details over a separate channel (a video call plus a signed message), not the same interface that proposed it. Several of the year’s thefts trace to a compromised or spoofed communication channel rather than the signing step itself, so the channel you use to coordinate deserves the same suspicion as the device you sign on: encrypted, authenticated, and reviewed.

Rotation, offboarding, and a written recovery plan

A multisig is not a set-and-forget object; it is an operational system with a lifecycle, and the Security Alliance now publishes a formal multisig operations certification that reads like an operations manual for exactly that. Its checklist spans a named operations owner and a full inventory of every signer, risk-tiered controls, dedicated hardware per multisig with geographically distributed seed backups, quarterly access reviews, and a defined offboarding window of 48 to 72 hours for emergency-class signers. The point of the offboarding clock is simple: a departed employee or rotated contractor whose key is still live is an attacker you have already invited in.

The other half is planning for the day something goes wrong. A written disaster-recovery plan should specify what happens when a threshold of keys becomes unavailable, when a compromise is suspected in the middle of a transaction, and who has authority to freeze activity. The certification calls for playbooks, quarterly reachability tests of every signer, a defined response time for emergencies, and annual drills, because a recovery procedure nobody has ever rehearsed is a document, not a defense. Retain an audit trail (the framework suggests three years) so that after any incident you can reconstruct who proposed, approved, and executed each transaction. None of this is glamorous, and all of it is cheaper than the alternative.

Multisig versus MPC: two ways to split trust

Multisig is not the only way to remove single points of failure. Multi-party computation splits a single key into shares held by different parties and combines them to produce one ordinary-looking signature, never reconstructing the full key in one place. The two approaches make opposite trades. Safe frames it as a choice about where trust lives, arguing that multisig externalizes trust into verifiable on-chain code while MPC internalizes it into infrastructure that cannot be fully verified on-chain. Fireblocks, from the institutional custody side, notes that regulators have recognized MPC as valid for self-custody since 2019, while multisig carries the longer, more battle-tested audit record.

Neither is strictly safer. A transparent on-chain multisig is independently auditable but advertises its structure to attackers, who can see exactly how many signatures they need to compromise. An MPC wallet hides its structure and rotates shares cheaply but asks you to trust a provider’s infrastructure you cannot inspect on-chain. For most treasuries that value verifiability and are comfortable operating in public, multisig remains the default. For institutions weighing speed, cross-chain reach, and privacy against that verifiability, MPC is a legitimate alternative, not a shortcut around the operational discipline both approaches demand.

Treasuries, DAOs, and the multisig everyone can watch

On-chain multisigs that govern protocols and treasuries carry a specific burden the average user does not: they are public. Anyone can read a DAO’s Safe, count its signers, see its threshold, and map its admin functions. The multisigs that secure bridges, protocol upgrades, and the Security Councils behind many rollups are among the highest-value targets in crypto precisely because their structure is legible and their holdings are large. The same infrastructure that secures tens of billions of dollars also concentrates it, which is why a single council multisig can sit upstream of an enormous amount of value across restaking and shared-security systems.

Public multisigs therefore need public discipline. Timelocks matter more here, not less, because a delay on an upgrade or ownership change gives a watching community the chance to react before a malicious transaction executes. Governance should require that admin actions be proposed, visible, and delayed, not signed quietly and executed instantly. The Radiant Capital theft turned on an attacker calling a privileged ownership-transfer function through a compromised council; a mandatory delay and active monitoring on that exact function class is what a public treasury owes the people whose funds it holds. Transparency is a feature, but only if someone is actually watching the transparency.

The regulatory gap: who answers when a multisig fails

When a multisig is drained, the question of who is on the hook depends almost entirely on who was running it, and in the United States the answer is often nobody with a clear duty. None of Bybit, WazirX, Radiant, Drift, or Humanity happened at an entity the SEC regulates as a custodian. The SEC’s Custody Rule under the Investment Advisers Act (Rule 206(4)-2) requires registered investment advisers to hold client assets with a qualified custodian, and in late September 2025 the SEC’s Division of Investment Management issued no-action guidance letting certain state-chartered trust companies serve as bank custodians for crypto, conditioned on written key-management and cybersecurity policies, SOC-1 and SOC-2 audits, asset segregation, and no rehypothecation without consent.

What that guidance pointedly did not do is resolve whether assets held in a multisig or MPC arrangement satisfy the Custody Rule at all. The ambiguity is the point: multisig is a security control, not a compliance status, and running one does not by itself put a custodian inside a regulated perimeter or give a user statutory recourse. For decentralized protocols the gap is wider still. A DeFi multisig operated by a pseudonymous council usually sits outside any custody regime entirely, so when it fails, users’ only recourse is whatever the protocol chooses to offer, a reality our look at who is actually on the hook in DeFi examines in detail. Best practice, in other words, is not only technical. Knowing whether anyone is legally accountable if your multisig is drained is part of choosing how to hold funds in the first place.

A 2026 field checklist, and when to walk away

Distilled to a working checklist, the practices that separated the survivors from the headlines this year are consistent:

• Write the threat model first, and let every other decision trace back to it.
• Use at least three signers, a threshold above 50 percent, and never 1-of-N or N-of-N; scale to seven or more keys above $1 million.
• Make the keys fail independently: different people, different hardware models and manufacturers, different locations, at least one external signer, and diverse client software.
• Give each multisig its own dedicated, ideally air-gapped, hardware wallet, and treat seed generation as part of the threat model, not a solved problem.
• Enable clear signing, verify raw calldata every time, and recompute the transaction hash on a separate device before approving.
• Put a mandatory timelock on sensitive actions, and back it with real-time monitoring routed to a channel humans watch.
• Confirm material transfers out of band, over a separate authenticated channel, never the interface that proposed them.
• Rotate and offboard keys on a defined clock, keep an audit trail, and rehearse a written recovery plan on a schedule.

And the practice that frames all the others: be willing to conclude that multisig is not for you. If your threat model is a single machine and a phishing link, a well-backed-up single-signature hardware wallet with clear signing may protect you better than a multisig you cannot operate calmly at two in the morning. Ledger’s own native multisig, launched in late 2025, drew criticism when it attached a flat fee plus a percentage charge to transactions, a reminder that even the tools sold as the answer carry costs and trade-offs. The strongest multisig is the one whose operators understood exactly why they needed it. The most dangerous is the one adopted in a panic because a competitor got hacked.

Frequently Asked Questions

Is a multisig wallet safer than a hardware wallet?

They solve different problems. A hardware wallet protects one key from malware and physical extraction; a multisig spreads authority across several keys so no single compromised device can move funds. The strongest configurations use hardware wallets as the individual signers inside a multisig. But a multisig you cannot operate correctly is not safer than one well-backed-up hardware wallet, which is why Ledger’s chief technology officer urged people not to rush into multisig after the 2026 Coldcard breach.

What is the best multisig threshold?

For individuals and modest holdings, 2-of-3 is the common baseline: it tolerates one lost key without locking you out and one stolen key without losing funds. High-value treasuries typically use 3-of-5 or 4-of-7, and the Security Alliance recommends at least three signers, a threshold above 50 percent, and seven or more signers once a wallet holds over $1 million. Avoid 1-of-N, a single point of failure, and N-of-N, which freezes funds if any one key is lost.

Why do multisig wallets still get hacked?

Almost never because the cryptography failed. The largest 2026 losses came from blind signing (approving a transaction the interface misrepresented), pre-signed transactions, malware on signer machines, and backups that placed multiple keys on one device. TRM Labs found that operational and key-compromise incidents were about 15 percent of hacks but roughly 76 percent of the value stolen in the first half of 2026.

What is clear signing and why does it matter for multisig?

Clear signing shows a human-readable description of exactly what a transaction does on the hardware wallet’s own screen, so signers approve what they can read instead of an opaque data blob. The Ethereum Foundation’s 2026 Clear Signing standard (ERC-7730 and related proposals) and independent tools that recompute a transaction hash on a separate device directly target the display-layer manipulation behind the Bybit and WazirX thefts.

Does US law require a multisig for crypto custody?

No. The SEC’s Custody Rule (Rule 206(4)-2) requires registered investment advisers to use a qualified custodian, and late-2025 staff guidance let certain state-chartered trust companies serve as bank custodians for crypto under strict key-management conditions. That guidance does not resolve whether assets held in a multisig or MPC arrangement satisfy the rule, so multisig is a security control, not a compliance guarantee.

Marcus Feld covers self-custody and on-chain security for HOGE Wire.