Multisig Wallet Security: Why Blind Signing Keeps Winning

In the five biggest multisig failures of the last two years, the cryptography never broke. No one factored an elliptic curve or brute forced a private key. Every case involved a signer, or several signers, approving something other than what they believed they were approving. Bybit lost roughly $1.5 billion this way in February 2025. Drift Protocol lost about $285 million this way in April 2026. Humanity Protocol lost around $36 million this way in June 2026. The common denominator is not weak math. It is weak process.

Multisig wallets require two or more independent keys to authorize a transaction rather than trusting a single point of failure, and they are the backbone of how crypto’s biggest treasuries, exchanges, DAOs and protocols hold funds. Safe, the dominant smart contract wallet on Ethereum and other EVM chains, alone secured an estimated $35.25 billion in assets across more than 61 million accounts as of the first quarter of 2026. That scale is exactly why misconfigured multisig setups are so expensive, and why the practices in this guide, choosing a threshold, diversifying signers, verifying before signing and enforcing timelocks, matter more with every treasury that grows into a target.

This piece works through what actually happened in five of the most consequential multisig failures, what they share, and the specific configuration, verification and process choices that would have changed the outcome, or did, for teams that got it right.

What a Multisig Wallet Actually Does

A multisig, short for multi-signature, wallet requires a minimum number of independent approvals, commonly written as M-of-N, before a transaction executes. A 3-of-5 setup holds five separate private keys and needs any three of them to sign before funds move anywhere. No single compromised device, employee or key is enough on its own to drain the wallet.

On Ethereum and other EVM chains, the dominant implementation is Safe, formerly known as Gnosis Safe, a smart contract wallet rather than a native multisignature script. Bitcoin has its own native multisig scripts, and Solana programs implement equivalent logic through on-chain multisig accounts, most visibly in Drift Protocol’s Security Council, discussed later in this piece. The mechanism differs by chain, but the goal is identical: replace trust in one key with trust in a threshold of independent ones.

That threshold model is why multisig became the default for exchange cold storage, DAO treasuries, protocol admin functions and, increasingly, for individuals securing large personal holdings rather than a single seed phrase. It is also why insurers, auditors and institutional allocators treat a well-run multisig as a meaningfully different risk profile than a hot wallet secured by one key alone.

Why Multisig Security Matters More Than Ever in 2026

Two forces are pushing multisig security up the priority list in 2026. First, the wallets themselves keep getting bigger. Safe’s own first quarter 2026 report put total assets secured at $35.25 billion across 61.11 million accounts, a record for the protocol, with roughly 2% of the entire global stablecoin supply now sitting in Safe accounts and March alone adding 852,000 new accounts and 50.9 million transactions. As corporate treasuries, DAOs and exchanges accumulate larger holdings through cycles like the one our halving cycle coverage tracks, the wallets safeguarding those holdings become correspondingly higher value targets.

Second, attackers have adapted faster than most organizations’ internal controls. TRM Labs recorded 207 hacks and exploits in the first half of 2026, more than double the same period in 2025, for a combined $972 million stolen. Smart contract bugs made up most of those incidents by count, but infrastructure and operational compromise, the category multisig failures fall into, accounted for only about 15% of incidents and roughly 76% of the value stolen. TRM Labs tied about $643 million of H1 2026 losses, close to two thirds of the total, to North Korea linked hackers, driven overwhelmingly by the Drift Protocol and KelpDAO attacks in April alone.

In other words, the rare multisig and key management failures are doing disproportionate damage relative to how often they happen. That is the pattern this guide works through case by case, then turns into a checklist.

The Bybit Hack: How $1.5 Billion Left a Secure Wallet

On February 21, 2025, Bybit’s multisig cold wallet appeared to make a routine internal transfer. Instead, roughly 400,000 ETH, worth about $1.5 billion at the time, left the exchange in what remains the largest crypto theft on record. Forensic investigators at Sygnia traced the intrusion back more than two weeks: a Safe developer’s Mac workstation was compromised around February 4, likely through social engineering, and the attackers used that access to reach Safe{Wallet}’s AWS infrastructure by February 5. On February 19, the JavaScript resources served to Safe{Wallet}’s web interface were modified with malicious code.

That code never touched Bybit’s own systems, and it never touched the underlying smart contract, which is exactly why the attack worked. It sat dormant until Bybit’s signers opened the interface to approve a transaction from their cold wallet, then silently altered the transaction details being displayed while leaving the signing request looking routine. Bybit’s signers approved what looked like an ordinary transfer. What they actually signed handed control of the multisig to the attacker, later attributed to North Korea’s Lazarus Group.

Bybit’s own response afterward showed the flip side of the story: the exchange’s balance sheet was never in question, only the signing process. CEO Ben Zhou posted within hours 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,” and the exchange backed that up with bridge loans from partners, whale deposits and OTC purchases that covered the ETH deficit within about two days, processing more than 99% of a surge of withdrawal requests within the first ten hours.

The lesson is not that Safe’s smart contract is insecure; it was never touched. The lesson is that a multisig is only as trustworthy as the interface its signers use to read a transaction before approving it, a concept the rest of this article calls clear signing versus blind signing.

WazirX and Radiant Capital: Two More Failures of Trust, Not Cryptography

Bybit was not the first lesson in this pattern, and it was not the last before 2026 began. Indian exchange WazirX lost nearly $235 million on July 18, 2024, from a Safe multisig run as a 4-of-6 setup, five keys held by WazirX and a sixth by custody partner Liminal. All six signing keys lived on hardware wallets, which on paper checked every box a security checklist would ask for. The attack succeeded anyway: the interface signers relied on to review the transaction did not match what was actually being authorized, so four legitimate signers approved a transaction that looked benign and was not.

Radiant Capital’s October 16, 2024 loss of roughly $50 million followed a similar script with a twist. Its 3-of-11 Safe multisig was compromised after macOS malware, delivered through a decoy PDF sent over Telegram, infected several signers’ machines. Because the malware compromised the signing devices themselves, Safe’s own transaction simulation tools showed nothing wrong; the machine reporting the simulation was the same machine that had already been compromised. Eleven possible signers might sound safer than six, but Halborn’s own analysis points out the flaw: an attacker only ever needed to succeed against three of them, so the larger pool of targets became a liability rather than a safeguard.

Both cases reinforce the same point Bybit later underscored at a much larger scale: hardware wallets, simulation tools and a nominally healthy threshold do not help if what a signer sees is not what they are actually signing.

Drift and Humanity Protocol: Two 2026 Cases, Two New Failure Modes

Two cases from the first half of 2026 show the same underlying weakness evolving into new shapes. On April 1, 2026, an attacker drained roughly $285 million from Drift Protocol, the largest decentralized perpetuals exchange on Solana, in the single largest DeFi exploit of the year so far. The attackers never touched Drift’s core smart contracts. Over the preceding weeks they socially engineered members of Drift’s Security Council, a 2-of-5 multisig, into pre-signing so-called durable nonce transactions, a legitimate Solana feature that lets a transaction be signed once and executed later, without expiring, once conditions are met. The pre-signed authorizations looked routine when approved. In late March, days before the exploit, Drift had migrated the Security Council to that 2-of-5 configuration with zero timelock, removing the delay that might otherwise have let someone notice and intervene before the pre-signed transactions were finally executed.

The stolen funds looked legitimate on the way out because of a second, connected technique: in the weeks before the takeover, the attackers had also manufactured a fictitious token, seeded it with just a few thousand dollars of liquidity on a Solana exchange, and used wash trading to build a price history near $1. Once the compromised Security Council let it into the system, Drift’s oracles accepted that fabricated token as legitimate collateral worth hundreds of millions, a reminder that a multisig failure and a price oracle failure can compound each other rather than sitting in separate risk categories.

TRM Labs linked the attack to North Korea, consistent with the roughly $643 million in North Korea linked H1 2026 losses cited earlier, most of which its aggregate report attributed to the Drift and KelpDAO attacks. Drift’s own postmortem said the attackers had spent months building relationships with the team before the pre-signing requests ever went out, patience that made the requests feel routine rather than suspicious.

Two months later, Humanity Protocol lost about $36 million on June 9, 2026, in a case that shows why nominal thresholds can be misleading. Its bridge admin keys were split across a 3-of-6 multisig on Ethereum and a separate 3-of-5 multisig on BNB Chain, on paper two independent thresholds. In practice, multiple keys from both chains had been backed up to the same employee laptop. Founder Terence Kwok said afterward that some of the keys were accidentally backed up to a compromised device during setup, which let a single machine compromise cross both approval thresholds at once. The attacker transferred bridge ownership on Ethereum and deployed code that drained roughly 141 million H tokens, while minting close to 200 million more on BNB Chain through a contract with an unlimited mint function.

Two separate M-of-N thresholds are only two separate lines of defense if the keys behind them are genuinely independent. Humanity Protocol’s setup had the right numbers on paper and the wrong reality underneath them.

The Common Thread: Keys Are Fine, Displays Lie

Lay the five cases side by side and the pattern is unmistakable. Not one involved a broken signature scheme or a brute forced key. Every one involved signers approving something other than what they believed they were approving, whether through a manipulated interface, a pre-signed authorization whose future use was misrepresented, or keys that were nominally separate but practically consolidated.

The figures above are approximate, drawn from the investigations and reporting linked throughout this piece; some final recovery and loss figures have shifted slightly as investigations closed. What has not shifted is the structural lesson: in every case, the multisig’s cryptography performed exactly as designed. The failure sat entirely in the layer above it, the software, hardware and human judgment deciding what to sign.

Choosing the Right Threshold for Your Treasury

There is no universal correct M-of-N ratio, but the Security Alliance, the nonprofit security collective known as SEAL, publishes one of the industry’s more widely cited baselines. Its recommendations scale with value at risk rather than prescribing one number for everyone.

SEAL’s framework also warns explicitly against N-of-N configurations, where every single signer must approve every transaction. It looks maximally secure on paper, but it turns any one lost, stolen or simply unavailable key into a permanent lockout, with no way to recover the funds at all. Radiant Capital’s 3-of-11 setup is a useful reminder that more signers is not automatically safer either: the absolute number of approvals required, not the size of the total pool, is what an attacker actually has to beat.

SEAL’s guidance goes beyond the raw signer count too. It recommends documented communication protocols for how a transaction proposal reaches signers in the first place, since several of the cases above trace back to a compromised or spoofed channel rather than the signing step itself, plus a written disaster recovery plan covering what a team does if a threshold of keys becomes unavailable, or a compromise is suspected mid-transaction.

Signer Diversity: Hardware, Geography and People

A threshold number means little if the signers behind it share a common failure point. SEAL’s framework and other industry guidance converge on a similar checklist: use different hardware wallet models and manufacturers across signers rather than standardizing on one device, so a single supply chain or firmware issue cannot touch every key at once; separate signers geographically so no single office, city or natural disaster can compromise a quorum; assign keys to different individuals across different roles inside an organization rather than concentrating several keys with one trusted employee; and include at least one signer external to the core team or company, so an internal compromise cannot reach every key by itself.

Ethereum co-founder Vitalik Buterin has framed the signer selection question directly: “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?” Radiant Capital’s 3-of-11 setup technically had signer diversity in headcount; what it lacked was diversity in the operating environment, since a single malware campaign was able to reach several signers’ machines through the same Telegram based social engineering approach.

Humanity Protocol’s collapse of two separate chain-level thresholds into one laptop is the clearest illustration of why diversity has to be operational, not just numerical. A multisig with six or eleven named signers offers no real protection if their key material converges on a shared device, a shared backup routine, or a single moment of carelessness during setup.

Clear Signing: ERC-7730, ERC-8213 and the End of Blind Approval

Blind signing, approving a transaction based only on what an interface displays rather than the actual instructions being executed, is the mechanism behind essentially every case above. On May 12, 2026, the Ethereum Foundation announced it had taken over stewardship of Clear Signing, an open standard aimed directly at ending it. The initiative was originally proposed by hardware wallet maker Ledger and is now backed by a broad coalition including MetaMask, Trezor, Fireblocks, WalletConnect, Keycard, Cyfrin, Sourcify, ZKnox and Zama, hosted under the Ethereum Foundation’s Trillion Dollar Security Initiative.

Clear Signing ships as a few coordinated pieces rather than one single fix. ERC-7730, still a draft standard, defines a shared JSON format wallets can use to turn raw smart contract calls and structured data into plain language before a signer approves them, replacing unreadable hexadecimal calldata with a description of what the transaction actually does. ERC-8176 layers an attestation system on top, built on the Ethereum Attestation Service, so independent auditors can formally vouch that a given descriptor accurately represents the contract it describes rather than signers having to trust whoever wrote it. ERC-8213 covers the fallback case: when no verified descriptor exists yet, it lets a wallet display a short, reproducible cryptographic fingerprint of the exact calldata being signed, one a signer can independently recompute on a separate device and compare before approving. A shared, publicly viewable registry lets any wallet pull the same verified descriptor for a given contract rather than every vendor building its own translation layer from scratch, which is the main reason backers expect adoption to move faster than past security standards did.

None of this would have stopped Bybit’s attackers from injecting malicious code into Safe{Wallet}’s interface in the first place, but it would have changed what happened next: a hardware wallet or independent verification tool displaying the true, human readable contents of that transaction, rather than trusting whatever the compromised web interface claimed, gives a signer an actual chance to notice something is wrong before approving it.

Verifying Before You Sign: Tools and Habits

Clear Signing is a standard still rolling out wallet by wallet, so multisig operators cannot wait for universal adoption before adopting the underlying habit themselves. Independent, open source tools already let a signer verify a Safe transaction away from the primary signing interface: Cyfrin’s clearsig and the community tool SafeLens both recompute a transaction’s true hash and, where descriptors exist, its plain language contents on a separate, ideally offline, machine, so a signer can compare that independent result against whatever the main interface shows before approving.

The underlying discipline is simple to state and easy to skip under time pressure: always verify raw calldata, meaning the target contract address, the specific function being called and its parameters, rather than trusting a plain language summary alone; recompute the transaction hash independently rather than assuming the number shown on screen is correct; and confirm unusual or high value requests out of band, through a live video call or a separately verified signed message, never through email or a chat thread that could itself be spoofed.

This is also where multisig security overlaps with plain social engineering. Radiant Capital’s malware arrived as a decoy PDF on Telegram; Bybit’s intrusion began with a compromised developer machine, very likely through social engineering as well. Our coverage of crypto’s phishing and drainer economy goes deeper into how these campaigns are built and targeted; the short version relevant here is that a multisig signer is a higher value phishing target than an ordinary wallet holder, and should be treated, and trained, accordingly.

Timelocks and Circuit Breakers: Buying Time to Catch Fraud

A threshold of signatures only protects a treasury at the moment of approval. Timelocks extend that protection past the signature itself by inserting a mandatory delay between when a transaction is approved and when it actually executes, giving a team a window to notice something is wrong and intervene. SEAL’s framework treats a timelock as close to mandatory for anything touching admin functions or large transfers, precisely because it turns a successful social engineering attempt into a race against a visible countdown rather than an instantly final transaction.

Drift Protocol’s case is a direct illustration of what happens without one. Days before the exploit, its Security Council migrated to a 2-of-5 threshold with zero timelock, which eliminated exactly the delay that could have let someone catch the pre-signed durable nonce transactions before they executed. A timelock would not have stopped the social engineering that produced those signatures in the first place, but it would have given the team a chance to catch the abuse before hundreds of millions of dollars actually moved.

The same principle scales down to routine operations: pair timelocks with active, automated monitoring of the multisig address itself, watching for owner changes, threshold changes and unusually large or unusual proposals, rather than relying on someone happening to notice. Some protocols go a step further and build automated circuit breakers that pause specific functions the moment on-chain activity crosses a predefined risk threshold, without waiting for a human at all, treating the timelock window as a backstop rather than the only line of defense. A delay is only useful if something is actually watching during it.

When the Signer Is Not Human: Multisig for Agents and Automation

A newer wrinkle is emerging as autonomous software, not just people, starts holding spending authority. Our look at AI agents operating on-chain covers how quickly agentic wallets have moved from experiment to real, funded accounts making their own transactions. The multisig lessons above translate directly: an autonomous agent with unilateral signing authority over a treasury is a single point of failure in exactly the way a lone human signer is, arguably a more exploitable one, since a manipulated prompt or a compromised API key can substitute for the social engineering that worked on Bybit’s and Drift’s human signers.

The practical response looks familiar: require a threshold of independent approvals before an agent-initiated transaction executes above a set value, keep at least one human or independently operated check inside that threshold rather than letting agents fully self-authorize, and apply the same calldata verification and timelock discipline to an agent’s proposed transactions that a careful human signer would apply to their own. Multisig was designed to remove trust from any single point of failure; that principle does not care whether the point of failure is a person or a piece of software.

A Practical Multisig Security Checklist

The cases and standards above condense into a short list any team running a multisig, from a two-person startup to a billion-dollar treasury, can act on directly.

• Never configure an N-of-N multisig; keep the threshold meaningfully below 100% of signers so one lost or unavailable key cannot permanently lock the funds
• Scale signer count and threshold to value at risk: a small team may reasonably run 2-of-3 or 3-of-5, while SEAL recommends seven or more signers for treasuries above roughly $1 million
• Diversify hardware wallet brands and models across signers rather than standardizing on one device or manufacturer
• Separate signers geographically and organizationally, and include at least one signer external to the core team
• Verify raw calldata, the target address, function and parameters, before every signature rather than trusting an interface’s plain language summary alone
• Recompute transaction hashes independently, ideally on a separate or air gapped device, using tools such as SafeLens or Cyfrin’s clearsig
• Confirm unusual or high value requests out of band, through a live video call or an independently verified signed message, never email or chat alone
• Enforce a mandatory timelock between approval and execution for admin functions and large transfers
• Treat pre-signed or offline-signed transactions, including Solana durable nonces, as high risk, and avoid open-ended validity windows
• Monitor the multisig address itself for owner changes, threshold changes and unusual proposals in real time

Regulatory Stakes: Who Answers When a Multisig Fails

None of the five cases in this piece happened at an SEC-regulated entity. Bybit is headquartered outside the United States, WazirX operates under Indian jurisdiction, and Drift, Radiant and Humanity Protocol are decentralized protocols with no single regulated custodian standing behind them. That is not a coincidence so much as a gap: the SEC’s core custody framework, the Advisers Act Custody Rule, governs how US-registered investment advisers must safeguard client assets, and it was written for traditional securities custody long before multisig or MPC wallets existed.

The SEC has started to address the crypto-specific version of that question, if narrowly. In late September 2025, its Division of Investment Management issued no-action relief allowing certain state-chartered trust companies to qualify as custodians for crypto assets held by registered advisers, conditioned on the custodian maintaining written policies for private key management and cybersecurity, independent audits, segregation of client assets, and a written agreement barring the custodian from lending or pledging those assets without consent. What the guidance does not resolve is the more fundamental question underneath all of it: whether assets held in a multisig or MPC-controlled arrangement satisfy the Custody Rule at all. Registered advisers are, for now, largely left to make that judgment call themselves.

That regulatory patchwork sits alongside the SEC’s broader, still evolving approach to crypto enforcement, covered in more detail in our mapping of US crypto enforcement in 2026. Outside the United States, frameworks such as the EU’s Digital Operational Resilience Act impose similar operational and ICT risk management duties on regulated crypto-asset service providers, again without prescribing any specific multisig configuration. For a fully decentralized protocol like Drift or Radiant, the practical reality is starker than any custody rule debate: there is no qualified custodian requirement to fall back on, and a team’s own signer discipline is the entire defense.

Frequently Asked Questions

What is a multisig wallet?

A multisig, or multi-signature, wallet requires a set minimum number of independent private keys out of a larger total to approve a transaction before it executes, commonly written as M-of-N, such as 3-of-5. It replaces trust in a single key or person with trust in a threshold of independent approvals, which is why exchanges, DAOs and protocol treasuries widely use it for cold storage and admin functions.

How many signers should a multisig wallet have?

There is no universal number, but security researchers converge on similar rules of thumb: at least three signers with roughly a 50% approval threshold as a baseline, seven or more signers for treasuries above about $1 million according to the Security Alliance’s frameworks, and never an N-of-N setup requiring every signer, since losing or misplacing a single key would permanently lock the funds.

What is blind signing, and why is it dangerous?

Blind signing happens when a signer approves a transaction based only on what a wallet interface displays, without independently verifying the underlying calldata, the actual instructions the transaction executes. It is dangerous because a compromised interface, like the one used against Bybit in February 2025, can display a routine looking transfer while the signature actually authorizes something entirely different, such as handing control of the wallet to an attacker.

Is a multisig wallet safer than a single hardware wallet?

Generally yes, because it removes the single point of failure a lone hardware wallet still represents; if that one device or its owner is compromised, the funds move. Multisig only delivers that benefit if the keys are genuinely independent across different devices, people and locations. WazirX kept every signing key on a hardware wallet and still lost roughly $235 million, because the interface signers relied on to review each transaction had been compromised, not the hardware itself.

What is the difference between multisig and MPC wallets?

Multisig uses multiple complete, separate private keys and is typically visible on-chain as a transaction carrying multiple signatures or calls to a multisig contract. MPC, or multi-party computation, instead splits a single private key into shares held by different parties who jointly compute one signature without ever reconstructing the full key in one place, so the result looks like an ordinary single-signature transaction on-chain. Both aim to remove single points of failure; they differ mainly in on-chain transparency and implementation flexibility.

Written by the HOGE Wire security desk.