Bybit, $1.5 billion: the keys held, the screen lied

What happened

Bybit kept most of its ether in a multisig wallet run through Safe{Wallet}, a widely used interface for shared custody. Moving funds out required several signers to approve the same transaction on hardware devices. Those safeguards did what they were designed to do — and the money still left.

How a signature was turned against its signer

A Safe wallet is a small proxy contract. It holds the funds, but forwards every call to an implementation contract whose address sits in its first storage slot. Change that slot and you change what the wallet is.

The transaction Bybit's signers approved was not a transfer. It was a delegatecall into a contract the attackers had deployed beforehand — code that runs inside the wallet's own storage and overwrote that first slot with the attackers' implementation. From then on the wallet obeyed them, and emptying it took ordinary transfers. Bybit's chief executive has said the interface displayed a legitimate transaction while a different payload went to the signers' devices.

Safe's smart contracts were never compromised; its web interface was. And the injected code targeted only Bybit — every other user of the same interface saw a normal application.

ETH drained from one cold wallet

401,347NCC Group technical analysis

Ethereum addresses linked to the theft in the FBI's notice

51FBI PSA I-022625-PSA

Share of all crypto stolen in 2025 taken in this one theft

≈44%Altumptic calculation from Chainalysis totals

Our reading

Analysis — Altumptic's interpretation of the reporting above.

• The keys were never the target. Cold storage, hardware signers and a multisig threshold all held. The attack went around them, through the one component everyone trusted to describe the transaction: the screen.
• Blind signing is a design flaw, not a user error. If the signing device cannot decode what it signs, the signer is trusting the display of a computer that may be compromised. Three careful people made the same mistake because the system invited it.
• A transfer never needs delegatecall. Treasury wallets can refuse it outright, or put implementation changes behind a timelock. Either rule would have stopped this transaction.
• The supply chain reached the vault. The entry point was a developer laptop and a cloud session token — Web2 hygiene, not blockchain cryptography.

For our own wallet the case is a standing reminder of where the boundary is. ALT-01 Phobia Wallet signs on the device and asks for the password before every send, but no wallet can protect a signer from a display it does not control. The design notes in ALT-04 say what it does and does not defend.

Before you sign anything large

1. Decode the transaction on a second, independent device, and refuse to sign anything the hardware device cannot show in full.
2. Block delegatecall and implementation changes from treasury wallets, or put them behind a timelock.
3. Simulate every high-value transaction against current chain state before it is broadcast.
4. Treat the signing interface as part of your attack surface: pin and verify its files, or run it locally.
5. Protect developer laptops and cloud sessions like production — hardware keys, short-lived tokens, no unvetted code.