Binance names a root cause: what broke was a service identity with signing power, not EIP-7702

Based on Binance's Security Incident Update of 02:23 UTC, 30 October 2026 and on-chain data; prices as of 02:43 UTC. The announcement's own wording is "initial investigation suggests may involve", "no evidence of" and "estimated" — this is a direction of investigation, not a final finding. The technical post-mortem Binance has promised is the decisive document.

TL;DR

What broke was not EIP-7702. It was a service identity that held signing power.

• Root cause (Binance's account): possibly a compromised DevOps engineer's laptop, from which the attacker reached a service container and submitted unauthorised withdrawal transactions.
• Binance says it found no evidence of any wallet private key exposure, and has revoked the affected addresses' authorisations.
• Scale: total impact estimated at $6.3B, about $3B frozen, roughly $3.3B of net exposure, covered by SAFU and company funds.
• 7702's role changes: not the entry point but the amplifier — it turned an action bound by withdrawal policy into code execution bound by nothing.
• It also answers the question my previous piece left open: I noted that all 50 authorisations carried chain_id = 1, so the multi-chain outflows "need another explanation". This announcement supplies it — one withdrawal service, several chains, and no 7702 needed anywhere outside Ethereum.
• There is a seam in the announcement: Binance says the attacker submitted unauthorised withdrawal transactions, but the Ethereum transaction was a set-code transaction, not a withdrawal. The two are compatible, but the post-mortem has to answer: why could that service request a signature that rewrites account code?

1. The announcement: seven facts, one genuinely new

Unlike the two earlier "funds are safe, checks under way" statements, this one contains specifics that can be checked:

Only the first line is genuinely new: the root cause moved from "unknown" to "an operations endpoint and a service credential". Every other figure confirms or revises upward something already known.

"Revoked the affected addresses' authorisations" deserves separating out. The announcement never writes EIP-7702, but "address authorisation" is exactly the on-chain vocabulary of a 7702 delegation — so this is Binance conceding, indirectly, that the Ethereum path was code delegation rather than an ordinary private-key transfer.

2. The root-cause chain: from a laptop to signing power

Unfolded, it is roughly five steps:

DevOps engineer's laptop
  → VPN / kubeconfig / CI-CD token / service account
  → withdrawal or signing service container
  → signing service / HSM / MPC
  → Type-4 authorisation (50 nonces)
  → hot wallet code rewritten → batch sweep

Step one: why a DevOps laptop. Endpoints like these hold the keys to the automation, not the coins: a Kubernetes kubeconfig, CI/CD deployment tokens, SSH keys, VPN credentials, a password manager, monitoring consoles. Compromising one is equivalent to acquiring a high-privilege service identity.

The announcement does not say how the intrusion happened (phishing, malware, supply chain), nor how long the attacker had been resident — and those two facts determine how many other services need auditing.

Step two: why a service container is dangerous. It is not "a machine" but a workload with a cloud identity. Having taken the container, the attacker does not necessarily need to steal a key — they can use its IAM role or service account to make requests of the signing service.

"No evidence of private key exposure" is fully compatible with this path: the key never left the HSM, but its signing power was borrowed.

That is harder to defend against than a leaked key — rotating the key achieves nothing; you have to cut off the service identity.

Step three: why 7702 bypasses withdrawal controls. This is the most underrated technical detail in the whole chain.

A withdrawal system's policy engine typically inspects a transaction's to, value, data, allowlist and limits. A Type-4 transaction looks like this:

To a policy that only parses calldata, this looks like a harmless "sends itself zero" transaction. Once the signature clears and the code is written, the withdrawal limit is void entirely — the subsequent drain never goes through the withdrawal system at all; it executes code as the hot wallet.

Step four: 50 nonces say the signer was an interface, not a person. If the signing side could read the nonce from a node, one authorisation suffices. Needing 50 usually means the signing service cannot see live chain state, or has to cover the drift between signing and inclusion.

That matches the "service container co-signing" picture closely: it can request a signature but cannot necessarily read the chain. In the attack-chain piece I inferred from this that the evidence pointed at compromised signing infrastructure rather than a copied key — the announcement points the same way.

Step five: three readings of "no evidence of private key exposure".

1. The HSM/MPC signing oracle was impersonated and the key never left;
2. A software key was used in place inside the container or in memory, never copied;
3. The key did leak and the investigation has not found it yet.

If the revocation the announcement describes has taken effect and the attacker has not re-delegated, the first two are likelier — because someone holding the full key could reinstall the back door immediately after a revocation. In the attack-chain piece I treated the absence of that tug of war as weak evidence for an abused signing channel; the announcement gives it a stronger frame.

3. The seam the announcement does not explain

Binance says the attacker submitted unauthorised withdrawal transactions. But the Ethereum transaction was a set-code transaction, not a withdrawal.

The two are not contradictory — a withdrawal service may well also be able to construct Type-4 transactions. But the technical review has to say:

Why could that service request a signature that rewrites account code?

That is the real control failure. "Withdraw" and "point this account's code at an unverified contract" are not in the same risk class, yet they shared one signing policy.

4. Reconciling the scale: $6.3B gross, about $3.3B net

$6.3B is the most misreadable number in the announcement:

Given that the announcement lists about $3B frozen separately, $6.3B reads as gross outflow rather than net loss. On that basis:

$6.3B   total impact (gross)
−$3.0B   frozen
───────
 $3.3B   theoretical net exposure

But that is neither the final loss nor cash recoverable now.

The freezes partly reconcile: Tether about $1.567B, Circle $823M, Ripple $200M of RLUSD, World Liberty/BitGo $27M — about $2.62B in total. The announcement's $3B implies roughly $380M of additional freezing that has not been itemised.

More importantly, frozen is not recovered. USDT, USDC and RLUSD can be frozen at the contract level; BTC and ETH cannot. The 18,270 BTC BWEnews estimates (about $1.4B) can only be recovered by seizure on entry to an exchange or by law enforcement — that portion is currently "traceable but not frozen".

So the $3B of freezes is probably concentrated in stablecoins, and actual cash recovery still depends on issuer cooperation and the pace of enforcement.

The announcement does not disclose SAFU's balance. Public reporting has put the SAFU conversion programme at the $1B order of magnitude; on that rough basis, $3.3B of net exposure still leaves about $2.3B for company funds. For a firm of Binance's size that is not unbearable — but "bearable" and "covered" are different claims, and an updated PoR is the only way to verify the second. The announcement gives only a condition, "once remediation completes", and no date.

5. On-chain cross-check: four points of contact

Contact one: the 7702 path is fully corroborated on-chain. The 50 authorisations, the one that took effect, the 0xef0100‖0x63e842… designator, the sweep 3 minutes 24 seconds later, and the 12 sweeps over the following three and a half hours (several of them 23,100-gas empty polls) all fit "persistent delegation plus an automated bot".

Contact two: the revocation claim has not been independently checked. Binance says it revoked, but the last on-chain confirmation that the delegation was live is 00:10 UTC, so a revocation would come after that.

A revocation transaction may be sent by a service address, so it would not appear in Binance 14's outgoing list — confirming it independently means reading that address's code directly (by specification EXTCODESIZE returns 23, so the delegate address is recoverable) or waiting for the post-mortem to give a transaction hash. Until there is a hash, "revoked" remains a company statement.

Contact three: $6.3B sits about $460M above the third-party cluster. That could come from addresses outside the Arkham cluster, outflows on other chains, or differences in snapshot time. The announcement gives no per-chain or per-asset breakdown, so no line-by-line reconciliation is possible.

Contact four: the pause widened. The first statement covered withdrawals only; the new one pauses deposits and withdrawals together and postpones a new listing.

That suggests Binance is not "waiting for on-chain confirmation" but rebuilding or isolating the whole withdrawal path. Reasonable from a risk standpoint; a signal worth watching from a liquidity standpoint.

6. The market is pricing "contained and covered"

BNB's rebound from the $678.13 low to $713.85 says traders are currently pricing "contained and covered" rather than "insolvent".

But that is pricing built on a promise, not on verification.

7. Six open questions

The announcement gives a direction, not evidence. These decide whether "contained" holds:

1. When and how was the laptop compromised, and how long was the attacker resident? If the intrusion is weeks old, other services and endpoints need auditing too.
2. Which service account or container held signing authority, and what were its boundaries and approval chain? This is the throat of the whole chain.
3. Why did the signing policy clear 50 authorisations? Does it parse authorization_list? Why no alert on "unverified contract plus 50 nonces"?
4. Is the key in an HSM/MPC or in software, and can logs prove it was never exported? "No evidence of exposure" needs logs behind it, not a conclusion.
5. Did the BTC and Tron outflows come from the same service? If so, the root cause is a cross-chain withdrawal service rather than one chain_id = 1 authorisation — which also explains neatly why 7702 appears only on Ethereum.
6. Is $6.3B gross or net? What is the itemised $3B of freezes and how recoverable is it? When does the PoR land, and does it cover the liability side?

8. Conclusion

The value of this announcement is not the figure $6.3B. It is that the root cause moves from cryptography back to operations.

EIP-7702 was not broken. A service identity holding signing power was.

7702 was only the amplifier: it turned a limit-bound withdrawal into code execution bound by nothing. What has to be fixed is service identity, signing policy and endpoint security — not the protocol.

For the industry the lesson is explicit: code delegation has to be governed as a highest-privilege operation. It is not in the same risk class as a transfer, and the two must not share one signing policy.

Bottom line. Until the technical post-mortem and an updated PoR are out, "contained" is an announcement, not a finding. Three signals are what matter next: whether a verifiable revocation appears on-chain, whether the PoR covers the liability side, and whether withdrawals resume within days. For BNB, $678 is the confidence line and $760 the repair line.

Sources

• Binance, Security Incident Update
• CoinDesk live coverage
• The Block: Binance investigating suspicious outflows
• BWEnews: independent on-chain accounting
• EIP-7702 specification

Companion pieces: a Binance hot wallet falls, anatomy of the EIP-7702 attack, the EIP-7702 signing flow, and Binance has not released the signing logs (that audit runs to 00:30 UTC; this announcement came at 02:23 UTC). The announcement's wording is "initial investigation", "no evidence of" and "estimated"; the root cause is not confirmed by a technical review. Not investment advice. DYOR.