A private key is only as safe as the system that decides what it signs. This week made that point twice, at two very different scales. On 29 October, Binance lost an estimated $6.3 billion from its hot wallets in an attack that, on the exchange's own preliminary reading, did not require stealing a single private key. A few days earlier, the Electrum Bitcoin wallet disclosed a flaw that let a malicious server trick users into signing a payment to an attacker while they thought they were simply speeding up their own transaction.
Neither case is a story about broken cryptography. Both are about the gap between what a signer is shown and what it actually approves.
What happened at Binance
Binance said in its security incident update that its initial investigation "suggests that the security incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions." It added that it had "found no evidence of any wallet private key leak", put the estimated impact at around $6.3 billion with about $3 billion frozen on-chain, suspended deposits and withdrawals, and said it will cover all losses. A full technical post-mortem has not yet been published, so the details below come from on-chain analysis and may be refined.
The largest single leg hit one of Binance's busiest Ethereum hot wallets, labelled Binance 14. According to Blockaid's analysis, at 20:20:59 UTC the attacker submitted a transaction carrying 50 EIP-7702 authorizations, all signed with the Binance 14 key, one for each of 50 consecutive account nonces. EIP-7702, live on Ethereum since the Pectra upgrade in 2025, lets an ordinary account attach smart-contract code to itself by signing an authorization. Because the wallet was busy paying out withdrawals, the attacker could not know which nonce would be current, so it signed a window. One entry matched. Three minutes and 24 seconds later, a single call to the attacker's contract moved 167,464 ETH, 1.615 billion USDT and dozens of other tokens out of the wallet.
The delegation then stayed in place. As 808bits documents, deposits kept arriving at the wallet after the drain and were swept again, until Binance reset the delegation with a new authorization to the zero address shortly after midnight UTC. Other hot wallets on other chains sent ordinary transfers to the same attacker address within minutes.
Why the signer did not object
The detail that matters most is the shape of what was signed. An EIP-7702 authorization is a signature over a tiny message: a magic byte, a chain ID, a delegate address and a nonce. It has no recipient, no amount and no calldata. As the 808bits analysis puts it, a signing service that is handed 32-byte digests cannot tell this digest from a transaction hash, and a policy engine that checks destination, amount and calldata never gets a look, because the object has none of those fields.
In plain terms: a policy that would refuse a large transfer to a new address may have no rule at all for a message that says "let this contract act as me". The 50-nonce window also suggests the signatures came back from a pipeline in the ordinary course of its work, rather than from someone holding the raw key, which is consistent with Binance's statement. That remains a reading of the evidence until the post-mortem confirms it.
The pattern is familiar. In the 2025 Bybit incident, signers approved a transaction that looked like a routine transfer. The lesson then was to show signers the full calldata. This time there was almost nothing to show, and the lesson extends further: every kind of message a key can sign needs its own rule, and anything the signer does not understand should be refused by default.
The same gap, at wallet scale
Electrum's case is much smaller, but the mechanics rhyme. In its security advisory published on 24 October, the project explained that a malicious server could swallow a transaction the user had just broadcast and replace it in the wallet's history with a conflicting one that paid the attacker. The substitute carried invalid signatures, but older clients did not check them for unconfirmed transactions. If the user then used Replace-by-Fee to bump the fee on what looked like a stuck payment, the wallet signed a valid version that paid the attacker.
The developers reported two user cases, one with a real loss, and noted that the attacker's address had been ground to match the last four characters of the legitimate one. Version 4.8.3 fixes the specific path by verifying signatures on wallet-owned inputs of unconfirmed transactions. CoinDesk's coverage adds that users connected only to servers they trust, including their own, were not exposed. The project's own workaround is the one that applies everywhere: before signing anything, a fee bump included, verify the output addresses and amounts in full.
What we take from this week
We build XColdPro, our air-gapped cold wallet software, around a simple principle: transactions are created, verified and signed on a computer that is disconnected from every network, and it reconnects only to broadcast the signed result. Isolation removes whole classes of remote attack, but this week shows that isolation alone is not the full answer. A signer, online or offline, has to understand what it is approving. These are the points we keep coming back to:
- Parse before you sign. A signing step should decode every message into human-readable terms: what type it is, which chain, which address, which amount. Anything it cannot decode should be refused, not passed through as an opaque digest.
- Treat delegations as their own category. Authorizations such as EIP-7702 delegations and token approvals grant ongoing power, not a single payment. They deserve stricter rules than transfers, and a clear way to check and revoke them afterwards.
- Do not trust the history you are shown. Electrum's flaw worked because the wallet trusted a server's view of pending transactions. What appears in a list is not proof of what was signed.
- Check full addresses, not the ends. Address grinding to match the first or last characters is now routine. Compare the complete address against a source you trust.
- Separate the request from the approval. At Binance, the attacker reportedly reached a service that could submit withdrawals. Whatever can ask for a signature should not be the same thing that decides whether to give one.
For individual users, the practical advice is short. Update Electrum to 4.8.3 from the official site, keep long-term holdings away from keys that sign automatically, and read every field on the confirmation screen, even for a fee bump you started yourself.
Looking ahead
Binance has promised a detailed post-mortem, and we will read it closely. Whatever it confirms, the direction is already clear. As accounts gain more programmable power, the most important security question is shifting from "who holds the key" to "what will the key agree to sign, and who decides". Systems that answer that second question explicitly will be the ones that hold up.
