Multisig Security Risks & Mistakes: The Bybit Lesson 2026

Introduction

Multisig removes single-key risk but adds new failure modes: blind signing (Lazarus drained approximately $1.4 billion from Bybit in February 2025 via a spoofed Safe{Wallet} signing UI), lost wallet descriptors and configuration data, coordinator compromise, and unverified destination addresses. Multisig is a category of solutions rather than a single product, and the security of any given multisig depends entirely on the signer's operational discipline at the moment of approval. The threshold model on its own does very little if the people holding the keys cannot verify what they are signing.

You have probably heard the line that multisig solves single-point-of-failure. It does, narrowly. What it does not solve is signer-side compromise, blind-signing approval of a malicious transaction, lost configuration data, coordinator backdoors, or address-bar phishing. Each of those is a distinct failure mode this guide enumerates. Before multisig is the right framing for you, your single-key setup needs to already sit on hardware — the single-key baseline is the C4 layer of the C4 → C8 → C10 security chain that this page sits in.

This page does not re-explain M-of-N mechanics; the cluster's multisig wallets complete guide owns the conceptual model. It does not walk through Bitcoin multisig setup or Safe deployment; those operational walkthroughs live in the BTC setup and Safe setup satellites of this cluster. What this page enumerates is the set of failure modes that the rest of the cluster keeps stepping around — the Bybit case study being the worst recent example, with Ronin (2022) and WazirX (2024) as the shorter comparisons that show the same root pattern in different mechanisms.

The structure that follows is a framing question — does multisig actually make you safer, calibrated honestly — then four failure modes (blind signing as the Bybit centrepiece, then lost descriptor, coordinator compromise, and address verification), a mitigations checklist that turns each failure mode into a concrete discipline, and a conclusion that distils the operational lesson. The single-sentence stance the page defends throughout: multisig is safer than single-sig if you handle the new failure modes; it is no safer than single-sig — sometimes worse — if you blind-sign or skip address verification.

Does Multisig Actually Make You Safer?

The honest answer is yes if done right, no by default. Multisig changes the shape of the failure surface; it does not eliminate failure. Spell the asymmetry out before going into the specifics — the rest of the page only makes sense if you carry this framing through every section.

The "yes" case — done right

A correctly configured and disciplined multisig delivers four properties that single-sig structurally cannot. No single key compromise drains funds: an attacker who phishes one seed phrase has nothing actionable, because the threshold blocks a 1-of-N transaction. Geographic key distribution makes coordinated theft hard: keys in three different jurisdictions, behind three different physical security perimeters, raise the operational cost of a coordinated attack by orders of magnitude. Threshold redundancy protects against device loss and death events: lose one device, you can still spend; die without succession planning is a separate inheritance problem that the cluster covers in a dedicated satellite. For organisations, multisig provides a clean separation-of-duties story that auditors recognise — the "two signatures required" pattern from traditional finance applies cleanly to crypto custody.

The "no" case — by default

Each of the four failure modes in this guide explains a specific way a multisig can fail as badly as single-sig, sometimes worse. Blind signing converts a multisig into a single-attacker compromise: if 2 of 3 signers approve a malicious transaction without verifying what they are signing, the multisig has failed exactly the way a single-sig would. Lost descriptor or config equals lost funds: a 2-of-3 Bitcoin multisig with all three seed phrases backed up but no descriptor is unrecoverable. This is the Bitcoin multisig footgun that the Bitcoin multisig setup guide covers operationally (linked in the conclusion and related-resources below). Coordinator compromise can mislead all signers simultaneously, which is the Bybit pattern in one sentence. Address-verification gaps mean signers approve the wrong destination — multisig provides no protection against an unverified destination, because the threshold rule only checks that enough signers signed, not that they signed the right thing.

The framing sentence that ends this section is the bridge into the Bybit case study: multisig is not a security primitive — it is a security architecture. The primitive is the signer's verification discipline at the moment of approval. The architecture only works when the primitive holds. The rest of the page is about how the primitive fails and what to do about it.

Blind Signing and the Bybit Case Study

What blind signing is

Blind signing is when your hardware signer renders an opaque hash or binary blob on its screen rather than a human-readable transaction breakdown. You see thirty-some hexadecimal characters and an "approve" button; you cannot verify the destination, the value, or (for contract calls) the function being invoked. Clear signing is the opposite: the device parses the transaction and renders the destination address, the token, the amount, and — for smart-contract calls — the function name and the decoded arguments. You can read what you are about to sign, line by line, before approving. The single concrete reason this matters in multisig: the multisig contract trusts that each signer verified what they signed. If every signer blind-signed, the multisig is, in effect, a rubber stamp on whatever transaction the UI presented to them.

What happened to Bybit

On 21 February 2025, attackers drained approximately $1.4 billion to $1.5 billion from Bybit's cold multisig wallet (the figure varies depending on the reference point — whether measured at the moment of transfer or at later USD reference points). The ETH amount was approximately 401,347 ETH per Chainalysis tracking. The wallet configuration was a defensively chosen 2-of-3 cold multisig per Bybit's official postmortem and Sygnia's independent root-cause analysis — not a 1-of-1 hot wallet, not a single-sig vault, not a careless setup. Multisig did not prevent the loss.

The attack vector matters more than the dollar figure. A Safe developer's machine was compromised, and malicious JavaScript was injected into the Safe{Wallet} web interface served to Bybit's signers. When Bybit's three signers loaded the Safe{Wallet} UI to review and approve what they understood as a routine internal transfer, the injected JavaScript substituted the underlying transaction payload while continuing to display the expected destination on screen. Each signer's hardware device received the actual (malicious) payload to sign — but only as an opaque hash, not as a human-readable transaction. The signers blind-signed; the multisig executed the malicious transfer. The three-signer threshold operated exactly as designed — the design assumes signers verify on hardware, and the signers did not.

What was not exploited matters for the calibrated framing of the entire incident. The Safe smart-contract protocol behaved exactly as designed. Safe contracts have had no contract-level exploit since the protocol shipped in 2018, and the system currently secures over $100 billion across more than 30 networks under SafeDAO governance. The Bybit hack was a supply-chain attack on the developer environment of the UI layer combined with a blind-signing failure on the signer side. It was not, by any technical reading, a Safe protocol exploit. Frame this to your future self plainly: do not avoid Safe because of Bybit — but do not approve transactions without clear-signing because of Bybit.

Attribution and aftermath

Attribution converged independently from multiple investigators on the same conclusion: Lazarus Group, North Korea state-sponsored, FBI-confirmed via PSA on ic3.gov. Chainalysis tracked the laundering trail across mixers and bridge hops and reached the same attribution independently of the FBI. Sygnia's incident report focused on the developer-machine compromise vector; NCC Group's independent analysis confirmed the JavaScript injection mechanism. The attribution is unusually well-corroborated for an incident of this scale.

The aftermath landed in two categories: customer impact and ecosystem health. Bybit reimbursed all customers within roughly 24 hours of the incident per its official postmortem — meaning the loss was an exchange operational loss rather than a user-funds loss in the legal sense. The figure remains the single largest crypto theft on record at the time of writing. On the Safe protocol side, ecosystem usage continued to grow through 2025 and 2026: Safe currently secures over $100 billion across more than 30 networks, with SafeDAO governance fully decentralised since 2023 and the $SAFE token trading on major exchanges since April 2024. The market response did not punish Safe for an incident that was not Safe's fault; the appropriate response from individual signers is the same.

The operational lesson

The single highest-leverage change every multisig signer can make is to enable clear-signing on every hardware device used as a signer, and to refuse to approve any transaction the device renders as an opaque hash. Treat the device's display as the source of truth and the coordinator UI's display as a convenience. If the two disagree, trust the device. If the device cannot clear-sign a given transaction at all — meaning it only shows you a hash — decline the transaction and investigate why. A specific contract call may genuinely be too novel for your device's parser, in which case the answer is to wait, update firmware, or use a different signer; the answer is never to blind-sign through it because the UI says it is safe.

Three additional disciplines compound the clear-signing baseline. Use hardware signers from at least two different manufacturers across your multisig signer set — defence in depth against a single firmware exploit that would otherwise compromise all your signers simultaneously. Cross-check the rendered destination, value, and function name against the intended transaction every time, not just for large transfers. For multisig setups that handle high-value transactions, send a small test transaction first (a few dollars of stablecoin) to confirm the destination before signing the full amount. None of this is novel discipline; it is the basic verification hygiene that the Bybit signers either skipped or could not perform because their devices were not clear-signing.

Bybit was not an isolated event. In March 2022, the Ronin Bridge lost approximately $600 million when Lazarus spear-phished Sky Mavis operators and gained control of 5 of 9 validator keys — a multisig with too low a threshold and insufficient signer diversity. In July 2024, WazirX lost approximately $235 million when attackers exploited a signing-interface mismatch on a Liminal multisig wallet — a different mechanism, same root failure: signers approving transactions they could not actually verify on their device. Different vectors, identical lesson: multisig only works when every signer can independently verify the transaction.

Lost Descriptor or Config Recovery

The failure mode in one sentence: signers preserve their seed phrases diligently, but lose the wallet structure (the descriptor for Bitcoin; the contract address plus chain ID for Safe). Funds are technically recoverable in cryptographic terms — the keys still exist — but operationally unreachable. This is the highest-frequency multisig failure mode at the long tail, far more common than spectacular hacks. It accounts for an unknown but non-trivial share of the "lost crypto" anecdotes you read in Bitcoin community discussions.

The Bitcoin descriptor footgun

A Bitcoin multisig descriptor is a text representation of the script type (P2WSH for SegWit, P2TR for Taproot), the extended public keys (xpubs) from each signer, the derivation paths, and the M-of-N threshold. Without that descriptor, three seed phrases cannot reconstruct the multisig wallet — they can only generate single-sig wallets that do not own the multisig UTXOs. The seeds spawn correctly. The single-sig wallets they generate have nothing in them. The multisig UTXOs sit unspendable on the chain because the script needed to spend them is unknown.

The recovery procedure framing is straightforward in principle and routinely skipped in practice. Store the descriptor alongside the seed phrases. Use a steel backup if the seeds are steel-backed; paper degrades, steel does not. Keep multiple geographic copies — the descriptor is public information (it does not include any private keys), so storing it more places than the seeds is structurally fine. The operational walkthrough — exactly how to export the descriptor from Sparrow or Nunchuk, how to verify it loads correctly into a fresh coordinator instance, how to perform a recovery dry run — lives in the BTC descriptor mechanics and recovery procedure satellite (linked below).

The Safe and EVM case — different shape, smaller surface

EVM multisig has a smaller surface area for this failure mode, because the Safe wallet configuration (owners, threshold, modules) lives on-chain at the contract address. Losing the contract address is recoverable if you have any signer wallet's transaction history — the deploy transaction is on-chain and links the owners to the contract. Losing access to all signer wallets simultaneously is the standard threshold problem (you no longer have M of N signers), which is distinct from the descriptor problem above. The mitigation is correspondingly lighter: store the contract address, the chain ID, and a screenshot of the Safe{Wallet} UI showing the owner set, in a location independent of any single signer's keys. A passphrase manager, a small text file in your password vault, or a printed sheet in your safe-deposit box all work.

The reader takeaway across both cases: configuration data deserves the same backup discipline as seed phrases, because losing it has the same operational consequence — funds that exist but cannot be moved. For Bitcoin specifically, this is non-optional. For Safe, the failure mode is rarer but still real, and the mitigation is cheap.

Step-by-step recovery walkthrough for descriptor or contract loss

The mechanical procedure differs by ecosystem but follows the same arc. For Bitcoin descriptor loss with intact seeds, the recovery has four steps. First, locate any prior coordinator backup, signer-device export, or paper backup of the descriptor that might survive in a less obvious storage location — a USB stick, a printed sheet inside a hardware-wallet box, an email draft from setup day. Second, if no backup is recoverable, the seed phrases plus knowledge of the script type (P2WSH versus P2TR) plus the derivation path (m/48'/0'/0'/2' for P2WSH mainnet, m/48'/0'/0'/3' for P2TR mainnet) plus the threshold value can be combined to manually reconstruct the descriptor — recoverable in principle but several hours of work that any normal user should engage a wallet engineer to perform. Third, validate the reconstructed descriptor by loading it into a fresh Sparrow instance and confirming the read-only wallet renders the expected receive history. Fourth, transfer funds to a new multisig once you have a working coordinator setup confirmed against the original signers. For Bitcoin descriptor loss with seed loss alongside, the funds are unrecoverable; the cryptographic primitives simply do not exist to derive the addresses without both the seeds and the script structure.

For Safe contract-address loss with intact owner-wallet access, the recovery procedure is short. Open Safe{Wallet} from any of the owner addresses, navigate to the network where the Safe was deployed, and the Safe appears in the owned-Safes list automatically — the Safe contract registry on each chain indexes contracts by owner address. For Safe contract-address loss without owner-wallet access, the situation parallels Bitcoin seed-plus-descriptor loss: the funds remain at the contract address forever (Safe contracts cannot be unilaterally drained, which is the security property), but you cannot transact with them. The structural answer for both ecosystems is identical: do not lose access to a quorum of owner-side material. Annual dry-runs that reconstruct the wallet from backup on a clean coordinator environment are the discipline that turns these procedures from theoretical capabilities into practised ones, and discovers the backup gaps while you still have slack to fix them.

Coordinator and Setup Compromise

The failure mode: an attacker compromises the software that signers use to coordinate transactions, or the channel through which the wallet structure was originally distributed. All signers' devices then operate against a manipulated view of the wallet or the transaction. The Bybit incident is the canonical example of the coordinator-UI variant of this failure mode; the broader category includes supply-chain compromises of the coordinator binary and compromises at the moment of wallet generation.

Coordinator UI compromise — the Bybit pattern

JavaScript injected into the signing UI displays one transaction while hardware devices receive another. This is the precise mechanism behind the Bybit drain. The mitigation is the same as the blind-signing mitigation, because the two failure modes are the same primitive failure expressed at different layers: clear-signing on the hardware device makes the substitution observable to the signer. The device's display is the source of truth, not the UI's display. If the device's renderings and the UI's renderings disagree, you trust the device and decline the transaction.

Coordinator software supply-chain compromise

The risk: a malicious update is pushed to Sparrow, Nunchuk, Electrum, Safe{Wallet}, or any other coordinator your signers use. Either the maintainer's signing key is compromised, or a binary distribution channel is compromised, or a build-system intermediary is compromised — the result is that signers run a coordinator binary that does not match the published source code. Mitigation has three components. Verify release signatures before installing any update — this is a one-line discipline that most coordinators document and that few users actually perform. Prefer open-source coordinators with reproducible builds, where independent verification is cryptographically possible. Lag updates by a week or two on cold-wallet machines so that supply-chain incidents have time to surface publicly before you install the affected version.

Setup-time compromise

The wallet itself is generated on a compromised machine. The descriptor or contract address you receive corresponds to a wallet whose private keys the attacker already controls — the threshold is irrelevant because the attacker has the keys. Mitigation: generate setups on air-gapped devices that have never been online, verify each xpub on the hardware signer's screen against the values the coordinator displays, and verify Safe contract deployment from at least two independent machines before depositing meaningful funds. The discipline gap between "generated on my laptop while it had Telegram open" and "generated on an air-gapped machine I just initialised from clean media" is the gap between "your multisig is yours" and "your multisig is someone else's".

The operational discipline behind every variant of this failure mode lives in the verify-don't-blind-sign clear-signing flow within the Safe satellite (linked below in conclusion and related-resources). The reader takeaway here: the coordinator sits inside your trust boundary even though it is not your wallet. Treat coordinator updates with the same caution as wallet firmware updates, and treat wallet generation with the same caution as initial seed-phrase generation.

Incident response — what to do when coordinator compromise is suspected

Suspicion does not need confirmation to act on. The threshold for stopping the signing flow is much lower than the threshold for confirming an attack. If during transaction review the coordinator UI renders a destination address you do not recognise, a value different from what you set out to send, a gas estimate implausibly high for the operation, or a function call that decodes into something other than the transfer or contract interaction you expected, refuse to sign and investigate. The same applies if your hardware device is rendering only an opaque hash where you expected clear-signing detail. The reason to pause on these signals rather than dismiss them is that the attack pattern depends on signers treating routine signing as routine; a discipline that pauses on anything unexpected does not survive its first instinct.

Once paused, the immediate response has three components. First, document the suspect state — photograph or screen-record the coordinator UI, the hardware-device display, and the browser address bar in their current rendering. These artefacts are the evidence you need if the suspicion turns out to be confirmed. Second, disconnect from the coordinator UI and from the signer hardware before any further interaction; the suspect software stays open in a screen recording but is no longer receiving instructions. Third, do not approve any further transaction from any other signer in the same set until the coordinator is independently verified; if signer two is about to approve the same transaction that signer one paused on, signer two pausing is what blocks the attack from completing the multi-signer flow.

Verification is the diagnostic step. Check the coordinator vendor's official status page and incident-disclosure channel (Twitter, GitHub issues, blog) for active incident reports. Re-download the coordinator software from its canonical source — Sparrow from sparrowwallet.com, Nunchuk from nunchuk.io, the Safe{Wallet} web interface from app.safe.global — and verify the release signature against the maintainer's published PGP key. If you cannot verify the signature, treat the coordinator as suspect. Cross-check the transaction details independently: load the same wallet read-only into a second coordinator (Sparrow can render Safe addresses read-only; a second Safe{Wallet} session in a different browser profile can re-render the same EVM transaction) and compare. If two independent coordinators show identical transaction details and they match your intent, the coordinator-UI compromise hypothesis is weakened; if they diverge, you have your confirmation and the disconnect step you took already is what kept you out of the threshold.

Containment and key rotation depend on how far the suspect transaction progressed before you paused. If no signer signed, the transaction is not on-chain and cannot execute; reinstall the coordinator from a verified source and resume normal operation. If signer one signed before the pause but signer two did not, the partial signature is not on-chain yet — you are below the M-of-N threshold — but you should still treat the multisig as conditionally exposed: deploy a new multisig with a different owner set, transfer the funds across using a clean coordinator and clear-signing on every step, and decommission the old setup. If the threshold was met and the malicious transaction is on-chain, you are in a recovery scenario rather than a prevention one: coordinate with chain-analysis services (Chainalysis, TRM, Elliptic) to attempt freezing the funds on exchanges before they are cashed out, file an incident report with the relevant law-enforcement channel (FBI IC3 for US-routed funds, your national equivalent otherwise), and document the incident for the broader community. Post-incident documentation matters because the next operator of the same coordinator vendor learns faster from your disclosure than from waiting to repeat the same lesson.

Address-Verification Gaps

The failure mode: signers correctly verify the transaction structure on their hardware device — value, function call, gas — but the destination address itself has been substituted between the intent ("send to our payroll wallet") and the device's display. Multisig provides no protection against signing a transaction to the wrong address. The threshold checks signatures, not intent.

Three common vectors

Address-bar substitution in the coordinator UI is the simplest variant. Signers reviewing the UI see one address; the transaction sent to their device contains another. The vector relies on signers not checking the full address character-by-character on the device, which most signers do not bother to do for routine transactions. Clipboard hijacking during paste from the address book is the second variant, particularly relevant for organisational workflows that maintain spreadsheets of "approved" addresses — copy from spreadsheet, paste into coordinator, never verify. The malicious clipboard process substitutes the address between copy and paste. The third variant is lookalike address phishing: vanity addresses generated with matching prefix and suffix characters to a legitimate destination. Signers visually scanning the first four characters and the last four characters approve the wrong address, because both ends match.

Mitigation discipline

Address books should be cryptographically anchored, not just stored. For Safe, the on-chain address book or a hardware-secured entry pinned by a signer's device is the structural answer. For Bitcoin, address-book entries should live in a write-protected file with explicit verification steps before reuse. Verify the full destination address on the hardware device for any transaction above a threshold your organisation defines — somewhere in the $10,000 range is a reasonable starting point — and do not rely on a first-four-last-four visual scan, because that is exactly what lookalike phishing defeats. For new high-value destinations, send a small test transaction first (1 to 10 USDC), confirm receipt through an out-of-band channel, and only then sign the full amount.

The reader takeaway: clear-signing solves transaction-structure verification, but it does not solve "is this the right address". Address verification is a separate verification step that happens at the address-book and intent layer, not at the device-display layer. The mitigation list in the next section turns these three categories — blind signing, lost descriptor, coordinator compromise, address verification — into concrete actions you can apply this week.

Mitigations Checklist

Each failure mode in the previous sections maps to a concrete operational discipline. The list below is actionable, not philosophical — every item is something you can verify or change about your multisig setup this week. The items are listed roughly in order of leverage, with clear-signing first because it is the single highest-impact change the Bybit case study supports.

• Enable clear-signing on every hardware device used as a multisig signer. Refuse to approve any transaction your device renders as an opaque hash. If a contract call is too novel for your device to parse, wait, update firmware, or use a different signer — do not blind-sign through it.
• Use hardware signers from at least two different manufacturers across your multisig signer set. Defence in depth against a single firmware exploit that would otherwise compromise all your signers simultaneously.
• Back up the descriptor (Bitcoin) or contract address plus chain ID plus owner-set screenshot (Safe / EVM) in storage independent of any single signer's seed phrase. The configuration data is as critical as the keys.
• For Bitcoin multisig specifically: store at least two copies of the descriptor in separate geographic locations. Steel-backup if your seeds are steel-backed — paper degrades and the descriptor is the recovery key.
• Verify the full destination address on the hardware device for every transaction above your organisation's defined threshold. A first-four-last-four visual scan defeats nothing; vanity-address attackers generate matches deliberately.
• For new high-value destinations: send a small test transaction first (1 to 10 USDC), confirm receipt out-of-band through a phone call or signed message, and only then sign the full amount.
• Verify coordinator software release signatures before updating. Lag updates on cold-wallet machines by one to two weeks so supply-chain incidents have time to surface publicly.
• Generate new multisig wallet setups on air-gapped devices that have never been online. Verify each xpub or contract address on the hardware screen against the coordinator's display from at least two independent machines.
• Maintain an offline "signing playbook" that documents your organisation's process for routine transactions, high-value transactions, signer recovery, and emergency response. This becomes essential during incident response, and writing it surfaces gaps you would otherwise discover under stress.
• Subscribe to security disclosure channels for every component in your stack: hardware-wallet firmware mailing lists, coordinator-software changelog or social channels, Safe protocol release notes, and any custody provider you use. The signal arrives publicly hours to days before the patch deployment lifecycle catches up.
• If maintaining all of the above solo feels heavier than the discipline you can sustain over years, consider collaborative custody as a solution for solo signers — a paid third-party service that holds one key and runs part of the verification discipline as their product. The trade-off is third-party trust plus service fees against full self-custody; the comparison page covers when the trade is worth it and when it is not.
• For the full operational-security stack underneath multisig signing — device hygiene, key-ceremony procedures, signer-onboarding checklists, incident response — see our operational security for multisig signers — full op-sec deep-dive [C10, coming July 2026].

Conclusion

Multisig is safer than single-sig if you handle the new failure modes; it is no safer than single-sig — sometimes worse — by default. The four failure modes this guide enumerates are the operational reality, not edge cases. Blind signing converts your multisig into a single-attacker compromise the moment every signer approves a hash they cannot read. Lost descriptor or configuration data converts a multisig with intact seeds into permanently unrecoverable funds. Coordinator compromise lets the attacker present every signer with the same lie. Address-verification gaps let the threshold authorise the wrong destination.

The single highest-leverage discipline across all four is clear-signing on every device, every transaction — the Bybit lesson distilled into one operational rule. Everything else in the mitigations checklist is supporting infrastructure that makes clear-signing reliable in practice: multi-vendor signers so a single firmware exploit cannot compromise all your devices, descriptor backups so the keys you carefully preserved actually open something, supply-chain hygiene on coordinator software so the UI you trust corresponds to source code you can read, and address-verification discipline so the threshold approves the right destination. Multisig is a security architecture; the architecture only works when the operational discipline holds.

Three forward links close the loop. For M-of-N mechanics if you skipped them, return to the multisig wallets complete guide. For Bitcoin multisig setup including descriptor backup discipline, see the Bitcoin multisig setup guide. For Safe deployment with clear-signing discipline built into the flow, see the Ethereum Safe multisig guide.

Sources

• Safe — official protocol overview: primary citation for Safe ecosystem scale ($100B+ across 30+ networks), SafeDAO governance, and the official statement on the Bybit incident.
• Chainalysis — Lazarus Group tracking: independent attribution of the Bybit drain to Lazarus, with on-chain laundering forensics.
• FBI PSA — North Korea and Lazarus Group attribution: federal-law-enforcement attribution of the Bybit incident to North Korean state-sponsored actors.
• BleepingComputer — Bybit hack incident coverage: independent incident summary including the developer-machine compromise vector and the JavaScript-injection mechanism.
• Bitget Web3 — Safe as the industry standard for multisig: industry analysis citing Safe's $100B+ AUM and 30+ network coverage, used in the post-Bybit ecosystem-health framing.
• Keystone Guide — Bitcoin multisig with Nunchuk: practical reference for the Bitcoin descriptor mechanics referenced in the lost-descriptor failure-mode section.
• Nunchuk — Bitcoin multisig coordinator: official site for the Nunchuk coordinator referenced in the coordinator-software supply-chain discussion.
• Sparrow Wallet — Bitcoin desktop coordinator: official site for the Sparrow coordinator, including release signatures and reproducible-build documentation referenced in the supply-chain mitigation.

Frequently Asked Questions

Are multisig wallets safe?

Yes if you handle the new failure modes — blind signing, lost descriptors, coordinator compromise, address-verification gaps. No by default. Multisig changes the failure surface, it does not eliminate it. The Bybit February 2025 hack (approximately $1.4 billion drained from a 2-of-3 cold multisig) proved that a defensively configured multisig fails identically to single-sig if every signer blind-signs the transaction the UI presents. Your operational discipline as a signer matters more than the threshold you chose. Use clear-signing on every device.

What happened to Bybit in February 2025?

On 21 February 2025, attackers drained approximately $1.4 billion (around 401,347 ETH) from Bybit's 2-of-3 cold Safe multisig. The vector: a compromised Safe developer machine injected malicious JavaScript into the Safe{Wallet} signing interface served to Bybit's signers. Each signer's hardware device showed the actual malicious payload only as an opaque hash; the signers blind-signed it. Attribution: Lazarus Group, North Korea state-sponsored, FBI-confirmed. Safe protocol contracts were not breached — the incident was a supply-chain attack on the UI layer plus a blind-signing failure on the signer side. Bybit reimbursed customers within roughly 24 hours.

Is Safe still safe to use after the Bybit incident?

Yes. The Safe smart-contract protocol has had no contract-level exploit since it shipped in 2018, and the system currently secures over $100 billion across more than 30 networks under SafeDAO governance. The Bybit incident was a developer-environment supply-chain attack plus a blind-signing failure — neither was a Safe protocol bug. Your discipline as a signer determines your operational safety far more than the contract layer. Treat Safe the way you would treat any critical piece of infrastructure: keep it updated, verify what you sign on hardware, and use clear-signing every time.

What is blind signing and why does it matter?

Blind signing is when your hardware device shows an opaque hash or binary blob instead of a human-readable transaction breakdown. You cannot verify the destination, the value, or (for contract calls) the function being invoked. Clear-signing — the antidote — renders the destination address, the token, the amount, and the function name on the device screen, so you can verify the transaction line by line before approving. Every Bybit signer blind-signed; every multisig user should refuse to. If your device cannot clear-sign a given transaction, decline it and investigate.

What is the most common way multisig users lose funds?

Lost configuration data — not spectacular hacks. A Bitcoin 2-of-3 multisig with every seed phrase carefully preserved but no wallet descriptor is unrecoverable; the seeds alone cannot reconstruct the multisig wallet. The same logic applies on EVM with the Safe contract address: lose the address, and your signer wallets cannot reach the funds even though the keys are intact. Back up the descriptor (for Bitcoin) or contract address plus chain ID plus an owner-set screenshot (for Safe) alongside your seeds — in storage independent of any single signer.

Should I trust my coordinator software (Sparrow, Nunchuk, Safe{Wallet})?

Trust but verify. Coordinator software lives inside your trust boundary even though it is not your wallet. Verify release signatures before updating; prefer open-source coordinators with reproducible builds; lag updates by a week or two on cold-wallet machines. The Bybit incident is what happens when the coordinator UI is compromised and signers do not cross-check on hardware. Your hardware device's display is the source of truth — what the coordinator UI shows is a convenience, not a verification.

What did Ronin and WazirX have in common with Bybit?

Different mechanisms, same root failure: signers approved transactions they could not independently verify. Ronin (March 2022, approximately $600 million): Lazarus spear-phished operators and seized 5 of 9 validator keys — threshold too low, signer diversity too thin. WazirX (18 July 2024, approximately $235 million): a Liminal multisig signing-interface mismatch caused signers to approve a transaction that differed from what their UI displayed. Bybit (February 2025): blind-signing of a substituted transaction. In each case, multisig was operationally bypassed because signers could not (or did not) verify on hardware what they were approving.

Related Resources

• Multisig wallets complete guide — hub overview of M-of-N mechanics, Bitcoin versus EVM multisig, and the decision framework for when multisig is worth the additional complexity.
• Bitcoin multisig setup guide — practical 2-of-3 BTC setup with Sparrow or Nunchuk, including the descriptor backup discipline that fixes the lost-descriptor failure mode covered above.
• Ethereum Safe multisig guide — practical Safe deployment walkthrough including the "verify, do not blind-sign" operational discipline that is the antidote to the Bybit pattern.
• Safe vs Casa vs Unchained — collaborative-custody service comparison for solo signers who want to delegate part of the verification discipline to a paid partner.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.