How is the Bybit incident fundamentally different from the more familiar "smart contract vulnerability exploited" type of hack?
Most previous major hacks — the DAO Hack, various DeFi flash loan attacks — involved attackers exploiting a genuine logical flaw in the contract code itself: the code was written incorrectly, and attackers found a way to make the contract behave in an unintended way. The Bybit incident is entirely different. Safe's multisig contract had no logical flaw whatsoever; its formally verified core code continued operating exactly as designed. What the attackers bypassed wasn't the contract — it was the entire information channel through which a human learns what they're about to sign before signing it.
This distinction matters because it means the question "was the contract audited?" is entirely beside the point for this class of attack. An audit verifies whether contract logic behaves as intended, but no audit scope covers whether the interface a signer sees faithfully represents what the contract is actually being asked to do — these are two completely separate chains of trust.
Why would a well-resourced major exchange like Bybit rely on a third-party service to manage its multisig wallet instead of building it in-house?
The cryptographic logic behind a multisig wallet isn't particularly complex on its own, but wrapping it into a system that lets multiple signers operate safely and conveniently on a daily basis — with transaction simulation, anomaly detection, cross-device syncing, and more — requires substantial ongoing engineering and security investment. Safe (formerly Gnosis Safe) became the dominant multisig solution in the Ethereum ecosystem precisely because it built this infrastructure to an industry-recognized level of maturity, sparing institutions from reinventing it themselves.
But this also creates a structural risk: when an entire industry concentrates its reliance on a small number of infrastructure providers, those providers themselves become single points of failure. An attacker doesn't need to target every institution using Safe individually — successfully compromising Safe's own development environment can simultaneously affect every client relying on that interface. This is precisely why, after the incident, the industry conversation shifted toward not relying solely on a vendor's security reputation, but building a verification layer independent of that vendor entirely.
If even a team as experienced as Bybit's got deceived, what concrete, actionable steps can other institutions or individuals actually take to defend against this kind of interface-layer attack?
The industry conversation currently centers on three approaches, all built around the same principle: don't rely on a single interface for both generating and verifying transaction content. First is pre-signing simulation — using a tool entirely independent from, and sourced differently than, the primary signing interface to re-simulate what the transaction will actually execute; any mismatch between the simulation and what the signing interface displays is itself a red flag. Second is raw data verification on hardware devices — some hardware wallets can display the raw call data of a transaction rather than just an interface-generated summary, and training signers to actually read that raw data rather than trusting a summary that merely "looks reasonable." Third is supply-chain governance over front-end code — auditing every front-end package and cloud storage access permission the signing interface depends on, treating the interface itself as part of the attack surface rather than assuming it's trustworthy by default.
For an individual user, these institutional-grade practices aren't fully replicable, but the underlying principle carries over: any screen asking you to sign a transaction should be treated as a potentially tamperable information source, and for higher-value transactions in particular, it's worth cross-checking through a second, independent channel — such as an official app or a blockchain explorer.
I don't use a multisig wallet — how does this incident actually relate to an ordinary individual investor?
Even if you only sign everyday transactions through a standard software or hardware wallet, the core risk pattern the Bybit incident exposed applies directly to you: whatever you see before signing any transaction — whether it's a confirmation pop-up in a wallet app or a summary on a hardware wallet screen — is generated by some layer of software, and that software itself can potentially be compromised. This is exactly why an increasing number of wallets now feature transaction simulation as a core selling point: before you sign, an independent source tells you what this transaction will actually do to your wallet's holdings, rather than just displaying whatever the interface itself claims.
In practical terms, this suggests two habits worth building for any request to sign a transaction — particularly ones involving large amounts or unfamiliar smart contract interactions: prioritize wallets with built-in transaction simulation (ones that can preview exactly how your holdings will change after signing), and for especially large transactions, cross-check the destination address through an official channel or blockchain explorer rather than relying solely on what a single interface displays for your final decision.
On February 21, 2025, Bybit executed what should have been an entirely routine operation: moving roughly 400,000 ETH from a cold wallet to a hot wallet for daily withdrawals. Three signers followed standard procedure, checking the destination address and amount on screen before signing off one by one. Everything displayed on the interface looked correct — except the interface itself had already been tampered with. By the time the transaction executed on-chain, Bybit discovered that this "routine transfer" had actually sent over 400,000 ETH and stETH, worth approximately $1.5 billion, to an attacker-controlled address, making it the largest single theft in cryptocurrency history. The attack has been attributed with high confidence to North Korea's state-sponsored Lazarus Group.
The most counterintuitive part of this incident is that the cryptography behind the multi-signature wallet itself was never broken. Bybit's cold wallet used a 3-of-6 multisig setup, requiring three out of six designated signers to approve any transaction — the industry-standard approach for preventing any single point of failure. The problem originated with Safe{Wallet}, the third-party interface Bybit relied on to manage that multisig wallet. Attackers compromised the development environment of a Safe engineer, obtained access credentials to cloud storage, and injected malicious JavaScript into the files Safe's front end used to render the transaction-signing interface. The code was designed to activate its disguise only when it detected a transaction matching specific criteria, staying dormant otherwise — making it far harder for routine security checks to catch.
When Bybit's signers followed the scheduled process to execute the transfer, the compromised interface displayed a destination address and transaction details that bore no resemblance to what was actually being signed on-chain. The transaction that was actually broadcast called the upgradeTo function on the Safe contract, replacing the logic contract underlying the entire multisig wallet with one deployed by the attacker — effectively handing over control of the whole wallet. The three signers checked the address and amount displayed on their screens exactly as company policy required; no step in the process was skipped. The screen they were checking against had simply been lying from the start.
This attack pattern is known in the industry as blind signing, or an interface-spoofing attack — the entire security guarantee of a multisig setup rests on the assumption that signers can accurately interpret what they're approving, and that assumption collapses the moment the interface they rely on to interpret it has itself been compromised. It's worth noting specifically that the Safe multisig contracts Bybit relied on had undergone rigorous, industry-recognized formal verification, and the core logic had never suffered a major breach at the protocol level in years of real-world use. This incident was never a case of the contract code itself being broken — it was the interface layer signers depended on to understand what the contract was asking them to approve that had been tampered with. Everything visible on-chain, including a sufficient signature count and a correctly formatted call, was entirely legitimate. The blockchain had no reason to suspect this was a malicious transaction, because cryptographically, it was a fully and validly signed one.
In the aftermath, Bybit CEO Ben Zhou quickly went public on social media to explain the situation, and within three days, the exchange secured over $1.2 billion in ETH through bridge loans, whale deposits, and OTC purchases with partners including Galaxy Digital, Wintermute, and FalconX — fully restoring its reserve ratio and resuming normal withdrawal service within roughly 12 hours of the breach. This response speed was possible largely because Bybit chose to publicly acknowledge the scale of the loss early and simultaneously release an independent proof-of-reserves report, rather than staying quiet while assessing the situation — a contrast often drawn against other exchange incidents where attempts to downplay losses further eroded user confidence. The attackers, meanwhile, rapidly converted the stolen assets into native ETH — an asset with no issuer able to freeze it — and dispersed the funds across roughly 50 wallets, each holding about 10,000 ETH, laundering them out one by one over the following nine days, with blockchain investigators and multiple analytics firms tracking the flows.
In the wake of the Bybit incident, the multisig industry began taking the question of how to independently verify the interface layer far more seriously — including requiring signers to re-simulate transaction content using tools entirely separate from the primary signing interface before signing, verifying raw transaction data directly on hardware devices rather than trusting on-screen summaries alone, and subjecting every front-end code update to multi-party review. The underlying logic behind all of these practices is the same: you can no longer assume that what the interface displays equals what you're actually signing — that equation now has to be actively verified, not passively trusted.
For an everyday user, the most direct lesson from the Bybit incident is this: multisig wallets, hardware wallets, and audited smart contracts, taken together, defend against an attacker breaking cryptography directly or stealing a single private key — but they don't necessarily defend against an attack where what you see on screen has been quietly altered. Whether you're a multisig signer at an exchange or approving a single transaction on your own hardware wallet, the real line of defense is whether what you're reviewing genuinely comes from a device or source you trust, rather than from any intermediate interface layer that could have been tampered with. Next time you're about to hit "confirm" on a wallet pop-up, asking one more question — who generated this information, and can it be independently verified — will do more for you than relying on the reputation of a multisig setup or an audit report alone.