What the Binance Hack Says About Who Signs Your Bitcoin
Binance says it found no evidence a key leaked, yet its own wallets signed the transfers. The full account, and what it means for self-custody.
Before the Bitcoin network accepts a transaction, it checks that the signatures are valid. It does not ask who decided to sign, or whether anyone read what was being signed. On the evening of Thursday 29 October 2026, at Binance, that difference was the whole story.
TRM Labs counts roughly $6.36 billion taken from Binance that evening, across ten networks, most of it in about twenty minutes from 20:05 UTC. Binance says about $6.3 billion, Chainalysis about $6.4 billion. Elliptic's chief scientist called it "almost certainly the single largest known theft of any kind." TRM puts the previous record at Bybit, in February 2025, at about $1.5 billion. This is roughly four times that.
The Bitcoin leg was 18,270 BTC, taken from one Binance hot wallet in eleven transactions, every one validly signed and all confirmed in block 973,732 at 20:20 UTC. By 00:30 UTC the next morning, about $2.7 billion of stablecoins taken in the same attack had been frozen, by TRM Labs' count, and Binance puts the figure closer to $3 billion. None of the Bitcoin was frozen, because there is nothing and nobody that can freeze it. Since then it has been split along a peel chain, one piece shaved off at a time, into round amounts: nineteen wallets, seventeen of them holding exactly 1,000 BTC. As of 30 October, they were sitting still.
No evidence a key was stolen
The sentence that matters most here came from Binance itself: "We have found no evidence of any wallet private key" leak.
Their initial finding was that the attack "may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions." A later update said the "subsequent investigation has uncovered additional points of breach. This was a complex attack." Binance's CEO, Richard Teng, added that "the attacker did not simply use one engineer's permissions, and this was not a single 'one-click' action," and reportedly said the attacker used a self-destruct mechanism to erase traces. Reporting puts the start of preparation at least 36 hours before the theft.
Now put that next to what the chain shows. On nine of the ten networks, Bitcoin included, the money left in what TRM calls "ordinary signed transfers," carrying valid signatures from wallets Binance controls. TRM's reading: "this points to a compromise of Binance's hot wallet signing infrastructure." As TRM also notes, "Binance has yet to publish a root cause," and which component actually signed the Bitcoin transactions is not public.
So Binance has found no evidence that a key left, and the signatures are real. If both hold, the likeliest reading is TRM's: the machinery holding the keys was made to use them. On that reading, nobody needed to steal a key. They needed the thing that signs to say yes.
Technical detail: how the Ethereum leg used EIP-7702
The Ethereum leg, about $3.79 billion by TRM's count, worked differently from the Bitcoin one, and it is why so much of the coverage has focused on a single Ethereum feature.
EIP-7702 lets an ordinary Ethereum account sign an authorization that delegates its behaviour to a smart contract. At 20:20:59 UTC, one transaction carried 50 such authorizations, all signed by a Binance hot wallet that TRM labels "Binance 14." Each pointed to a sweeper contract the attacker had deployed around 16:00 UTC, four hours earlier, which only the attacker could operate.
Authorizations are bound to the account's nonce, a counter that goes up with every transaction. Because each authorization works at only one nonce, the attacker had obtained 50 signatures in advance, for 50 consecutive nonces from 18,914,775 to 18,914,824. Exactly one matched. About three and a half minutes later the sweep began, and it kept re-sweeping as deposits continued to arrive, until the delegation was revoked around 00:10 UTC on 30 October. The same delegated wallet also pulled $823 million of USDC out of a separate Binance smart account.
None of this applies to Bitcoin. On Bitcoin and the other networks, the funds left as plain signed transfers. EIP-7702 explains how the Ethereum leg was emptied, not how the signatures were obtained in the first place.
Bybit, the same idea with people in the loop
TRM Labs and Chainalysis both attribute the attack, with high confidence, to TraderTraitor, a unit within North Korea's Lazarus Group. Binance has not named anyone. The FBI attributed the Bybit theft of February 2025 to the same group, and Bybit is the case worth holding this one against.
At Bybit, there was no automated hot wallet doing the signing. People signed, and they used hardware wallets to do it. That is usually the advice, and it is still good advice. What went wrong was the screen they trusted. They were on the genuine site, at the right address, and the page showed the routine transfer they expected. The code behind that page had been tampered with. Their devices showed the transaction as a block of raw data rather than an amount and a destination, and the last signer later said he reviewed it "not completely in detail." They approved it, and the approval was used to empty the wallet.
Put the two side by side and the shared pattern is plain. In both cases the right keys produced valid signatures. In neither case were those signatures the product of the owner reading, on a screen the attacker could not reach, exactly what was about to happen. At Binance, the signing ran inside the exchange's own systems, where no customer saw anything. At Bybit, humans signed and saw something the attacker had written for them.
The defence against this kind of attack is not a better lock on the keys. It is making sure the last thing between a request and a signature is a person reading the real amount and the real destination on a screen nobody else controls.
If your Bitcoin is on an exchange
If you hold Bitcoin on an exchange, this is the uncomfortable part. Your Bitcoin is not a coin with your name on it. It is a row in the exchange's database. When you withdraw, their hot wallet signs. You never sign anything, at any point, for any transaction. When Binance's hot wallets were emptied, there was no step at which a customer could have noticed or objected, because customers are not part of the process.
Binance deserves credit for what came next, and I want to be fair about it. They suspended deposits and withdrawals the same evening and halted trading. They said: "Binance will absorb the financial impact of these stolen funds, not our users," using their SAFU emergency fund and company money. By 31 October, Reuters reported, 90% of the losses had been replenished, with the remaining 10% in less liquid tokens. Withdrawals were planned to resume on 1 November, and a proof of reserves on 2 November.
Users have been made whole so far. But be clear about what it proves. It proves that Binance is large enough to absorb a loss of this size. It does not prove that the money was safe. Users had no say in how their Bitcoin was guarded, and no way to withdraw it for about two days. Their protection was the balance sheet of the company that lost the money. A smaller exchange hit the same way could not have done what Binance did.
What self-custody fixes, and what it doesn't
Hold your own keys, and the shape of the problem changes.
When you send Bitcoin from a hardware wallet, your computer hands the device an unsigned transaction, often as a PSBT, the standard format defined in BIP-174. A Ledger or a Trezor then shows you on its own screen what you are about to approve, before it signs: the amount in BTC and the destination address, in plain text. This is the real difference from Bybit. Your device is not asking you to approve a block of raw data. It is showing you the two facts that matter, on a screen your laptop and any server cannot draw on.
And no server can make it sign. The key never leaves the device, and the device signs only when you confirm on the device itself. A compromised exchange signs on its own. A compromised laptop next to a hardware wallet can ask, but it cannot say yes for you.
Two honest limits. The screen tells you the truth about what is being signed, not whether that address belongs to the person you think it does. You still have to check it against something the attacker cannot reach, such as the recipient reading it back to you over a different channel. And the screen only protects you if you actually read it every time, not just the first time.
That is the single-key version: one key, one device, one screen. It is a real step up from an exchange, and its limits are just as plain. One misread screen, or one lost device with a backup that turns out not to work, and nothing else stands in the way. A 2-of-3 multisig vault changes the shape. Three keys sit on three separate devices, and any spend needs two of them, so every transaction has to be shown and confirmed on two separate device screens. A compromised laptop, or a compromised coordinator building the transaction, has to fool two devices, not one. And one lost or broken key is not fatal, because the other two can still move the funds. The cost is concrete too: more devices to buy, update and keep apart, more backups to check, and more for your heirs to learn.
Self-custody does not remove the risk. It moves it to you. No server can make your device sign, but nobody will make you whole either. The failures that actually take people's Bitcoin in self-custody are usually quieter than a hack: a device that dies in year three, a backup nobody ever checked, a family that cannot use any of it when the person who set it up is gone. Trading the exchange's risk for those risks is usually the right trade for money you mean to keep for decades. It is still a trade.
Where Keystody sits
This is the part where I say what I built, and where its limits are.
Keystody vaults are 2-of-3 multisig: three keys, any two of which can move funds. No production vault has ever had a Keystody-held key. That matters here for a precise reason. With no key of ours in the vault, the threshold is out of our reach. If Keystody's servers were broken into, there would be nothing on them that can produce a signature. A compromised Keystody could still do harm, and I want to name it. It could put the wrong transaction or the wrong receive address in front of you. It could expose what the vault holds, because Keystody keeps the vault's public keys in order to show your balance and build transactions. A wrong transaction is what your device's own screen exists to catch: the amount and destination appear there before it signs. A wrong receive address is caught by checking the address on the device itself, which Keystody supports on Ledger and Trezor. The exposure is a loss of privacy, not of Bitcoin. What it cannot do is sign.
Every vault we set up puts each key on a hardware wallet from a different maker, so that a flaw in one manufacturer's device cannot reach two of your keys. I wrote about why after the COLDCARD seed flaw. To be plain about it: the software does not yet refuse a vault that breaks this rule. It is how we set vaults up, not something the code enforces.
The rest is aimed at the quiet failures in the callout above. Each vault gets a readiness grade from A to F. Keys get scheduled check-ups on the device itself, so a dead device shows up in a reminder rather than in an emergency. Recovery drills are recorded against the vault, so you know it can be restored before you need it to be. You get a recovery kit for the people who would need it. And the vault is described in standard output descriptors, so you can recover it with Sparrow or Bitcoin Core without Keystody being involved at all.
For why that matters across a generation, see passing a family vault to the next generation, and for why I started this, introducing Keystody.
If this week has you looking at Bitcoin you hold on an exchange and wondering what moving it would actually take, we offer a free 15-minute call. No pitch: we work out whether self-custody fits you, and what it would cost you in effort.
This story is three days old, and Binance has promised both a post-mortem and a proof of reserves. Go to the primary sources: Binance's initial finding and investigation update, TRM Labs' analysis, CoinDesk on the Bitcoin leg, the EIP-7702 mechanism and the attribution, and Reuters on the replenishment. On Bybit: Safe's statement on the compromised developer machine, and Ledger Insights on what the last signer saw. For a wider overview, see the coverage in The Guardian and The New York Times.