What was the signer allowed to sign?

What is reported

Binance says preliminary findings point to a compromised laptop belonging to a DevOps engineer. The attacker used it to reach a service container and submit unauthorized withdrawal transactions. Binance also says it has found no evidence of any wallet private key leak. It estimates the impact at about $6.3 billion.

Bitquery's on-chain analysis adds a detail worth pausing on. It reports that the attacker used EIP-7702 authorizations to make Binance's busiest Ethereum hot wallet run attacker-chosen code, and that those authorizations were signed by Binance's system. It also states its own limit: the record shows each drain was validly signed, but not who asked the system to sign, or how.

I'm not describing what Binance's internal controls were. I don't know. I'm asking what a signing system should check before it signs anything.

The question

Could a compromised service get the signer to execute an unauthorized business action?

If the signer treats a request from an internal service as an authorization, the answer is yes. Three controls could interrupt that path:

1. Independent approval, bound to the exact action and usable once. The approval names the source wallet, operation type, asset, chain, destination, amount, expiry and the actual signing payload, and it can be consumed only once. A service credential alone isn't enough.
2. Authority changes are not payments. An operation that changes who can act through a wallet, such as a delegation, needs a separate approval path and should not be reachable through the ordinary withdrawal API.
3. Revalidate at the moment of signing. Check every queued request immediately before signing, and reject approvals that have expired, been revoked or already been consumed. An emergency stop has to reach that boundary too.

These are proposed controls, not findings that Binance lacked them.

Where it has to live

Where this lives matters more than what it's called. A gateway that checks tokens and request schemas won't do this alone. It takes an independent approval service and transaction-aware policy. The signer must refuse anything that bypasses it, and the compromised environment must be unable to change the policy.

The boundary matters because of what comes after it. Once a usable signature leaves the signing boundary, stopping new API requests may not stop its use. An EIP-7702 authorization has no time-based expiry and can be submitted by anyone, but is accepted only when the account's current nonce matches the signed nonce. Removing an installed delegation takes a separate authorization that is submitted and processed on-chain.

I've written about the narrower version of this idea: a valid signature alone does not establish that the action was authorized (Signing Is Not Authorization).

Protecting the private key is essential. So is controlling what your own systems are allowed to ask that key to sign.

---

Views are my own.

Sources:

• Binance, security incident update (Oct 30, 2026; preliminary): https://www.binance.com/en/square/post/382713227024938
• Bitquery, Binance hack investigation (attributions may be revised): https://bitquery.io/investigations/binance-hack
• EIP-7702, Set Code for EOAs: https://eips.ethereum.org/EIPS/eip-7702
• Saleme, "Signing Is Not Authorization: Claim-Level Negative Vectors for Agent-Payment Receipts," Zenodo, v1.0, 2026-07-24: https://doi.org/10.5281/zenodo.21535452