$1.5 billion. One transaction. The largest crypto theft in history.
The uncomfortable truth about the Bybit hack is not that the attackers were sophisticated. It’s that the signers did everything right and still lost. They followed a reasonable procedure. The multisig worked exactly as designed. The private keys were never compromised.
They just couldn’t see what they were signing.
What happened in the hack?
The Lazarus Group compromised Safe’s frontend and injected JavaScript that silently replaced the transaction Bybit’s signers were about to approve. Each signer connected their Ledger, reviewed what looked like a routine transfer, and confirmed. The Ledger showed a hex hash of the transaction instead of a detailed description of the transaction — which was the only thing Ledger could do — it couldn’t decode what was inside. The signers had no way to know what they were actually signing.
That’s it. That’s the whole failure.
The failure point: blind signing
When a Ledger or Trezor device can’t decode a transaction, it shows you the raw hash and asks you to confirm.
This is called blind signing — you’re approving something you cannot read (good luck inferring something meaningful out of a bunch of hex digits).
In Bybit’s case, the actual transaction was not a transfer at all. It was a call that replaced the multisig’s implementation with attacker-controlled code. Once three signers confirmed, the attacker had full control of the multisig wallet. This is a point of no return, and the second transaction drained everything.
What the signers saw when signing the transaction:
Safe UI: “A routine transfer to hot wallet” ✅ Hardware device: “Hash value” ⚠️ (dangerous but frequently ignored) Actual transaction: “Change Multisig Code” ❌ (beyond hope now)
Why whitelisting doesn’t generalize
The obvious solution people reach for is whitelisting: whitelist known contract addresses and known function selectors, so the device can display something meaningful instead of a hash.
This works, and some approaches do implement it. Ledger’s Clear Signing Initiative maintains a registry of contracts with their ABIs, so the device can decode transfer(address, uint256) and display it as a human-readable transfer.
But here’s where it breaks down for Bybit’s case specifically.
The Safe contract was legitimate. execTransaction is a known Safe function. A whitelist covering "Safe contract + execTransaction" would have given a green light — because those two things checked out. By the way, Safe multisig wallets are deployable instances per multisig. So there is a new address for each deployment, making it harder to consider whitelisting for this scenario. The malicious payload was inside the calldata of that execTransaction: a delegatecall to an attacker contract, nested inside a legitimate call on a trusted address.
To catch this with whitelisting, you’d need to be able to recognize the patterns of calldata provided. It’s possible theoretically, but it’s an extremely challenging technical task in reality.
This requires an ever-growing library of dangerous patterns, maintained continuously, covering every protocol and every possible operation that could be abused.
Whitelisting secures identity (what is the action, what is the protocol). But it can’t secure behavior.
ERC8009: show consequences, not calldata
ERC8009 takes a different approach entirely. Instead of asking “where is this transaction going?”, it asks “what will this transaction do to my balances?”
The transaction is simulated before signing. The result — specifically, what balance changes will occur — is shown on the hardware device screen.
Trezor screen showing +2.8 USDC and -0.01 ETH as a result of transaction
The signer doesn’t need to understand what the transaction even does. They just need to see whether the consequences match what they expected to sign.
What the simulation would have shown on February 21
The malicious transaction moved zero ETH. Its only effect was changing the Safe’s implementation contract to an attacker-controlled address.
The Safe UI claimed: “transfer to hot wallet”. ERC8009 would have shown: “0 ETH moved”.
That contradiction alone ends the attack. No signer confirms a transaction when the simulation shows nothing is moving, but they expected ETH to move.
“But couldn’t the simulation be faked too?”
Yes — if the simulation runs on the same compromised machine serving the malicious frontend, an attacker could fake the output.
This is why the architecture matters. The expected balance changes are passed to the ERC8009 contracts and enforced there, and hardware wallets that support ERC8009 can display these balance changes directly on the hardware screen.
The attacker can manipulate a browser tab. They cannot change what appears on the physical device screen. That’s the trust boundary ERC8009 relies on, and it’s the same trust boundary that makes hardware wallets meaningful in the first place.
Multisig: now covered
There was one important gap in earlier versions of ERC8009: multisig signing flows.
In a multisig, signing and execution are separated. Signer A approves a transaction that doesn’t execute until B and C also sign. This made it unclear how to apply simulation-based clear signing when each signer’s action is independent of execution.
This is now resolved. ERC8009 has been extended to support multisig flows — the executor of the transaction can see simulated consequences of the collective transaction on their hardware device before confirming it.
Bybit’s setup — three independent signers each approving a Safe transaction — is exactly the flow that is now covered.
Why it scales
Address whitelisting has to keep up with every new contract deployed. That’s a losing race — millions of new addresses every year, across hundreds of protocols, with arbitrary call combinations.
ERC8009 doesn’t care about any of that. There are technical solutions that fully ignore the environment constraints, rather than trying to work with them. ERC8009 is one of them. Balance changes are the ground truth regardless of how deep the call chain goes, how new the protocol is, or how complex the interface is. You cannot construct a transaction that drains a wallet and have a simulation say nothing changes.
The property is generic by design.
Where things are now
ERC8009 is a proposed standard. There is a working implementation, including multisig support, and a demo with hardware wallets.
Spec and demos: ERC8009.xyz
Formal proposal: ethereum/ERCs #1184
Discussion: Ethereum Magicians
The Bybit hack was not the first attack that blind signing made possible. Radiant Capital ($50M), WazirX ($230M), and others before them followed the same pattern. It will not be the last — until hardware devices can show signers what a transaction actually does.
That’s what ERC8009 is for.
