ALT Title: The same gap in three incidents. In each case no key had to leak; something with authorized access could ask for signatures, and the request alone was enough. Bybit, February 2025: asked by a tampered Safe{Wallet} page showing a routine transfer; asked to sign a handover of the cold wallet contract; known from the FBI, about 1.5 billion dollars. Polymarket, October 2026: asked by a vendor script on the site, using the logged in session; built to ask for position sales and transfers to an address set in the script; known from Hudson Rock's read of the script. Binance, October 2026, highlighted: asked by a service container, reached from a compromised laptop; asked to sign an EIP-7702 delegation to a sweeper; known from Binance, about 6.3 billion dollars impact. At the bottom: Who checks what your keys sign?
ALT Title: A signer that reads first. The same two requests, sent as full messages; the signer decodes them, checks its rules, then hashes the same bytes it read, and signs. Left, the withdrawal service sends: transfer, 349.40 USDT, to 0x2874…a237. Right, the attacker sends: EIP-7702 delegation, run code at 0x63e8…6fae. Both go into a dashed boundary labelled inside the signer, with the key, holding the rules: SIGNED, its usual transfers and calls under the limits; REJECTED, anything else: delegations, approvals, unknown types. The service asking can't skip or change these rules. The transfer is SIGNED; the delegation is REJECTED. Below: a hot wallet signs what it normally sends; it has no reason to sign a delegation, so it never should. Example rules for an exchange hot wallet; changes to them need several people and a delay.
ALT Title: Two requests, one blind signer. The signer receives a 32 byte hash of each; it can't tell a payment from a takeover. Left, the withdrawal service wants to sign 349.40 USDT to a user (nonce 18,914,807, 15:20:47 CT). Right, the attacker, via a compromised service, wants to sign: make this wallet run the attacker's code (nonce 18,914,809, 15:20:59 CT). Each is hashed: 0x1fc1385d…5c35a729 and 0xac384c3e…3d2674ac. Both reach one signer, and both are stamped SIGNED. The signer sees two hashes, 32 bytes each, as good as random. It can check who asks and how often: is this caller allowed to ask? A login, a key, a network rule, a rate limit; nothing about the message itself. It can't check, because the hash hides it: transfer or takeover, which token, how much, to whom, what code it installs. Here the attacker was calling from a trusted service. Real signing hashes recomputed from the chain; the hash only signer is an illustration.