In February 2025, Bybit lost approximately $1.5 billion in the single largest theft in crypto history. The wallet that was drained was a multisignature cold wallet. The signers who approved the fatal transaction were legitimate, authorised personnel using hardware wallets, exactly as the security design intended. Every cryptographic control functioned correctly. The theft happened anyway, because the Bybit breach analysis shows the attack targeted the process around the multisig, not the multisig itself.
This is the pattern institutions need to internalise. A multisig wallet is a governance mechanism, not a security guarantee. It distributes authority across multiple signers so that no single compromised key can move funds, but it says nothing about whether those signers can be deceived, whether their devices are compromised, or whether the interface they use to review transactions can be trusted. Security4Web3 treats multisig security as a full People, Process and Technology problem: the technology enforces a threshold, the process defines how transactions are proposed and verified, and the people executing that process are the layer attackers now target directly.
Quorum Design: Choosing the Right M-of-N Threshold
The quorum, expressed as an M-of-N threshold, determines how many of N total signers must approve a transaction before it executes. Choosing this ratio is a governance decision with direct security consequences, and it is one that many organisations set once at deployment and never revisit.
A threshold that is too low creates concentration risk. Radiant Capital ran an admin multisig requiring only 3 of 11 signatures. In October 2024, attackers using malware delivered through a spoofed Telegram contact compromised enough signer devices to reach that threshold and transferred ownership of a core lending contract, draining roughly $50 million from the protocol's Arbitrum and BNB Chain markets. A threshold representing under 28% of total signers gave the organisation the appearance of decentralised control while the practical bar for compromise remained low.
A threshold that is too high creates its own failure mode: operational paralysis. If assembling a quorum requires signers across multiple time zones to be simultaneously available, legitimate urgent transactions get delayed, and organisations respond by relaxing procedures under pressure, which is precisely the condition attackers exploit.
Practical guidance for setting thresholds
- Treasury and cold storage wallets: favour thresholds where compromised signers alone cannot reach quorum, typically 4-of-7 or 5-of-9 for larger balances, consistent with the principles covered in cold storage policy.
- Operational and hot wallets: lower thresholds such as 2-of-3 or 3-of-5 may be acceptable if balances are capped and replenished frequently, reducing the value exposed at any threshold.
- Never let signer count and threshold drift together unreviewed. Radiant's 3-of-11 configuration was flagged publicly by security researchers as uncomfortably low for a protocol of its size well before the breach occurred.
- Tie threshold to value at risk, not to convenience. Thresholds should be reviewed at defined intervals and whenever treasury value, signer headcount or transaction velocity changes materially.
Signer Key Management: Hardware Wallets, HSMs and Rotation
Quorum design only matters if individual signer keys are properly protected. The Harmony Horizon bridge breach in June 2022 illustrates what happens when key custody is weak even inside a nominally distributed scheme. The bridge relied on a 2-of-5 multisig, but investigators found the relevant private keys had been decrypted and stored in a way that allowed an attacker who had already compromised an employee's laptop through phishing to reach multiple keys from the same access point. Two of five keys is meant to represent independent points of failure; in practice the keys were reachable together because the operational separation the design assumed did not exist in how they were stored and accessed.
Signer key management requires the same rigour applied to any other institutional credential holding significant value:
Hardware isolation
Signers should use dedicated hardware wallets, ideally with air-gapped signing paths, used for no other purpose. Radiant Capital's post-mortem confirmed the attackers compromised multiple developers' hardware wallets through targeted malware injection, underlining that a hardware wallet alone does not protect against a compromised host machine feeding it fraudulent transaction data. This is why HSM private key management is the appropriate escalation for institutional treasuries: a properly configured HSM enforces policy at the cryptographic boundary rather than relying on the integrity of a general-purpose device.
Segregation of signer roles
No individual should be able to both propose and independently verify a transaction against source data. This principle of separation of duties is what distinguishes a functioning quorum from a rubber-stamping exercise where signers trust each other's approvals without independent verification.
Rotation and lifecycle management
Signer sets change as personnel join, leave or change roles. Every departure, role change or suspected device compromise should trigger immediate rotation of that signer's key out of the quorum, following a tested runbook rather than an improvised process under pressure. Scheduled rotation, independent of triggering events, should also occur on a fixed cycle, commonly every 6 to 12 months.
The Bybit breach did not break multisig cryptography. It broke the human process around verifying what the multisig was being asked to sign.
Safe{Wallet} Operational Procedures: What Bybit Got Wrong
Bybit used Safe{Wallet}, the most widely adopted multisig platform in the industry, to manage a scheduled transfer from its primary Ethereum cold wallet to a warm wallet. According to Safe's published post-mortem, attackers linked to the Lazarus Group compromised a developer machine with privileged access to the Safe{Wallet} front-end deployment pipeline, reportedly through a social engineering approach resembling a fake job interview. That access was used to push a targeted JavaScript payload to the front-end assets served to Bybit specifically.
When Bybit's hardware wallet operators opened Safe{Wallet} to review the scheduled transfer, the interface displayed what looked like a routine transaction. The transaction actually submitted for signature replaced the multisig's implementation contract via a delegatecall, and once signed and executed, the new implementation transferred the wallet's full balance to attacker-controlled addresses. Funds were split across hundreds of intermediate addresses and moved through cross-chain swaps within 48 hours, a laundering pattern consistent with prior Lazarus operations against Ronin and Atomic Wallet.
The operational lesson is not that Safe{Wallet} is unsafe as a platform. It is that any interface, however reputable, is a single point of trust unless the process independently verifies what it displays. Organisations running Safe or comparable multisig platforms should adopt:
- Independent transaction verification using a second, unrelated tool or method to decode calldata before signing, rather than relying solely on the primary interface's rendering.
- Hardware wallet display verification as a mandatory step, cross-checking the destination address and value shown on the physical device screen against the interface, not skipping this step for speed.
- Isolated signing environments for the machines used to access the multisig interface, separated from general browsing, email and messaging to reduce the attack surface for the kind of front-end supply chain compromise Safe experienced.
- Vendor incident monitoring, tracking security advisories from Safe and comparable providers and having a pre-agreed response if the provider discloses a compromise.
Blind Signing and UI Spoofing: The Attack Surface Bybit Exposed
Blind signing occurs when a signer approves a transaction based entirely on a summary presented by software, without independently confirming what the underlying calldata actually instructs the blockchain to do. In the Bybit case, every signer who approved the malicious transaction was, in effect, blind signing: they saw a routine transfer because that is what the compromised interface showed them, while the actual payload executed a contract upgrade that handed over control of the wallet.
UI spoofing of this kind defeats the entire premise of a human approval step. A quorum of signers reviewing a fraudulent representation of a transaction provides no more security than a single signature, because every reviewer is working from the same falsified source.
Controls that address blind signing directly
- Decode raw calldata using a tool independent of the primary signing interface before every high-value approval.
- Require hardware wallets that display full transaction details, including contract addresses and function calls, on their own screen, and train signers to treat any mismatch as a stop-work event.
- Maintain a known-good hash or reference for routine, recurring transaction templates so deviations are immediately visible.
- Never approve a transaction because "it looked the same as always." Familiarity is precisely what attackers exploit when spoofing a routine transfer.
Transaction Governance: Approval Workflows and Authorisation Limits
Beyond the signing mechanics, institutions need a governance layer that defines who can propose transactions, what value tiers require additional scrutiny, and how exceptions are handled. Effective transaction governance for a multisig treasury typically includes:
Tiered authorisation limits
Not every transaction warrants the same scrutiny. Set defined value thresholds above which additional signers, a mandatory cooling-off period, or a secondary verification call are required, consistent with broader treasury security operations practice.
Out-of-band confirmation
For any transaction above a defined threshold, require a live, pre-arranged verification channel between the proposer and at least one signer that does not rely on the same platform being used to execute the transaction. This defeats attacks that compromise a single communication channel end to end.
Change control on the multisig configuration itself
Adding or removing signers, or changing the threshold, is itself a transaction that deserves the highest tier of scrutiny available, since it directly rewrites the security model of the wallet.
Emergency Procedures: Signer Compromise and Recovery
Every multisig deployment needs a documented, rehearsed response for signer compromise, because detection speed determines whether an incident stays contained. Radiant Capital's response, pausing markets on Base and Ethereum within hours, illustrates the value of a pre-agreed pause capability, though the initial compromise itself was not caught before funds moved.
An effective emergency procedure should define:
- Immediate signer suspension: a documented, fast path to remove a suspected-compromised signer from the quorum without waiting for full forensic confirmation.
- Communication protocols: a pre-agreed, out-of-band channel for coordinating between remaining signers that does not depend on infrastructure that may itself be compromised.
- Asset migration playbook: a tested procedure for moving remaining funds to a newly configured, clean multisig if compromise of the existing configuration is suspected.
- Forensic preservation: capturing device images and logs from suspected-compromised signer hardware before remediation, to support attribution and post-incident review.
These procedures depend on the same discipline described in a broader treasury security operations programme, and should be tested through tabletop exercises rather than left as an unread document.
Auditing Your Multisig Configuration
A multisig configuration should be audited on the same cycle as any other critical security control, not treated as a one-time setup task. An audit should independently verify:
- Current signer list against authorised personnel records, confirming no departed employees or unaccounted-for keys remain active.
- Threshold appropriateness relative to current treasury value and transaction velocity.
- Signer device hygiene, including hardware wallet firmware versions and evidence of dedicated, isolated signing environments.
- Transaction history for anomalous approval patterns, such as unusually fast quorum assembly or repeated use of the same two signers regardless of the full available set.
- Dependency on any third-party interface, such as Safe{Wallet}, including what verification exists independent of that interface.
Security4Web3 conducts these reviews as part of a wider audit discipline that treats the multisig not as an isolated control but as one component of an organisation's full custody and governance stack.
Frequently Asked Questions
What is the safest quorum for a crypto multisig treasury?
There is no single safe ratio that applies to every organisation. Most institutional treasuries settle on a threshold between 3-of-5 and 4-of-7, balancing resistance to collusion and single-signer compromise against the operational cost of assembling a quorum quickly during genuine urgent transactions. The threshold should be reviewed whenever signer headcount, transaction volume or treasury value changes materially.
Did the Bybit hack break Safe multisig technology?
No. The underlying multisig smart contract and signature threshold logic were not broken. Attackers compromised a developer machine with access to the Safe{Wallet} front-end pipeline and pushed malicious JavaScript that altered what legitimate signers saw when reviewing a transaction, causing them to approve a delegatecall that replaced the wallet's implementation contract. The cryptography held; the verification process around it did not.
Should signer devices be air-gapped hardware wallets?
For treasuries holding significant value, yes. Hardware wallets with air-gapped or Bluetooth-free signing paths, combined with a dedicated, hardened device used for nothing else, materially reduce the malware and remote-access risk demonstrated in the Radiant Capital compromise. HSM-backed signing adds a further institutional-grade layer for organisations that need auditable custody controls.
How often should multisig signers be rotated?
Signer rotation should follow a fixed schedule, typically every 6 to 12 months, and be triggered immediately by any change in employment status, suspected device compromise, or personnel role change. Rotation without a documented, tested procedure introduces its own operational risk, so the rotation runbook itself should be rehearsed before it is needed.
What is blind signing and why does it matter for multisig security?
Blind signing occurs when a signer approves a transaction based on a summary shown by a wallet interface without independently verifying the underlying calldata against the source chain. Because the Bybit attackers compromised the interface itself rather than the signers' keys, blind signing was the decisive failure: no signer independently decoded the transaction they were approving.