跪拜 Guibai
← Back to the summary

Binance's $6.3B Hack: Attackers Didn't Steal Keys, They Weaponized a Signer via EIP-7702

The industry spent a decade locking private keys in safes: HSM, MPC sharding, hot/cold separation, multi-signature approval. In the October 29 incident, not a single private key was lost — Binance officially stated "no evidence of any wallet private key leak" was found. But $6.3 billion still walked away.

Because the attacker never wanted the key. They wanted the seal.

1. Aligning the numbers: why the same event is reported from $1.7B to $6.4B

From on-chain anomaly to official announcement took only 6 hours, but the amounts given by different parties differ by nearly 4x. This isn't anyone spreading rumors — it's different statistical scopes. Putting them side by side clarifies the loss structure.

Scope Amount Entity Notes
Total event impact ~$6.3B Binance official announcement Includes frozen portions and unrealized losses
Valuation at theft time $6.36B TRM Labs 10 chains, Ethereum ~$3.79B, 18,270 BTC ~$1.47B
Valuation at theft time ~$6.4B Chainalysis CEO Jonathan Levin Roughly consistent with TRM
On-chain frozen ~$3.0B Binance Only "confirmed" portions
Issuers + Arbitrum freeze ~$2.7B TRM Labs Different cutoff times
Net loss after freeze ~$3.43B On-chain analyst EmberCN 18,000 BTC ~$1.44B + 46.7万 ETH ~$1.06B
CZ's rough gap ~$2.0B Zhao Changpeng himself 60 − 30 (frozen) − 10 (SAFU)

The early "$1.7B" figure came from a Bloomberg-cited trader estimate, the lowest scope before the event was characterized; "$5.3B" was Glassnode's early reading, and Chinese media in reposting even wrote 17,985 BTC as "Ethereum" — at the then ETH price of ~$2,228, 17,985 ETH would only be worth $40 million, contradicting the "$1.45B" given alongside. Such unit slips are the most common distortion in fast news; always return to the primary source when citing.

Only two numbers Binance itself confirmed: total impact ~$6.3B, on-chain frozen ~$3.0B.

2. Technical core: EIP-7702 turns hot wallets into "programmable accounts"

To understand why "no private key leak but still lost money" this time, you first need to understand EIP-7702, launched in the Ethereum Pectra upgrade in May 2025.

It solves a legitimate problem: a normal wallet address (EOA, Externally Owned Account) has only one private key, with no batch transactions, no spending limits, no social recovery. EIP-7702 allows an EOA to delegate its execution authority to a contract code while retaining the original address, private key, and history.

Mechanism:

New transaction type 0x04 (SET_CODE_TX_TYPE)
  └─ authorization_list: [ (chain_id, contract_address, nonce, y_parity, r, s), ... ]
        │
        │  Signature digest = keccak256(0x05 ‖ rlp([chain_id, address, nonce]))
        ▼
  EVM validates each: chain_id matches → ecrecover recovers signer → nonce equals current nonce
        │
        ▼
  Writes a 23-byte delegation indicator into the EOA's code field:
        0xef0100 ‖ <20-byte implementation contract address>
        │
        ▼
  From then on, any call to that EOA executes the implementation contract's code
  with the EOA's balance and storage as context.

Three design details, in hindsight all double-edged:

  1. Delegation does not require the private key to be "handed over" — only one signature. Once the signature is on-chain, that address permanently (until revoked) becomes an instance of the attacker-specified contract.
  2. Revocation requires only a new authorization pointing to the zero address — no time lock, no admin. Sounds safe, but it requires "you have to discover it first."
  3. Invalid authorizations are skipped, not causing the whole transaction to revert. This is to allow scenarios like batch onboarding where one failure doesn't roll back the entire batch.

Point 3 was the amplifier in this attack.

By September 2026, over 27 million Ethereum accounts had used EIP-7702. It's a widely adopted standard, not a vulnerability. The problem lies in who has the authority to request such a signature.

3. 50 signatures, 1 hit: reconstructing the attack chain

The following timeline comes from Blockaid's on-chain analysis, TRM Labs' tracking report, and Binance's official announcements, UTC times.

Oct 29, 15:59 — The attacker's operational wallet deploys a contract (marked 0x63e8…6fae). This is 4.5 hours before the actual attack.

20:20:59, block 26,300,753 — A type-4 transaction is sent to Binance hot wallet 0x28c6…1d60 (on-chain labeled Binance 14). The transaction carries 50 EIP-7702 authorizations:

chain_id  = 1 (Ethereum mainnet, all 50)
contract  = 0x63e8…6fae (attacker-deployed sweeper contract)
nonce     = 18,914,775 → 18,914,824 (consecutive 50)
signer    = Binance 14's own private key

Why 50? Because an authorization only takes effect when its nonce exactly equals the account's current nonce. Binance 14 is one of the exchange's busiest wallets, sending transactions every second, so the nonce jumps constantly. The attacker didn't know the exact value at execution moment, so they signed a full contiguous block of nonces, betting one would hit.

Of the 50, only 1 hit. The other 49 were silently skipped because the nonce didn't match — the whole transaction doesn't fail, which is the cost of that "tolerant design." The attacker can use one blind spray to get a deterministic hit.

20:24:23 — The operational wallet calls the now-sweeper Binance 14. The same call transfers out:

At the time, that's about $2.5 billion. Almost simultaneously, Binance 16 also transfers 28,005.6 ETH to the attacker's address.

20:32 — On-chain researcher Spreek raises the first alarm, pointing out the funds passed through Tornado Cash.

21:15 — Zhao Changpeng responds: "Looks like a hack on Binance indeed."

21:18 / 21:25 — Circle freezes over $800M USDC; Tether freezes over $1.567B USDT. Both stablecoin issuers did what Binance couldn't do within an hour of the event.

23:56 — Key detail: the delegation remained active. For the next 3.5 hours, the same sweeper contract was repeatedly invoked, continuing to sweep subsequent deposits.

Oct 30, 02:25 — Binance issues its first official announcement: suspected a DevOps engineer's laptop was compromised, allowing the attacker to access a service container and submit unauthorized withdrawal transactions; no private key leak found; total impact ~$6.3B; ~$3.0B frozen; fully covered by SAFU fund and company capital.

08:20 — On-chain check shows Binance 14's code field restored to empty (0x), delegation cleared.

08:47 — Binance updates: investigation found more intrusion points, the attack was a "complex process," not a "one-click operation"; withdrawals expected to resume in ~45 hours.

fig4-attack-chain.png

Nowhere in the entire chain is "cracking cryptography." The entry point is an engineer's laptop, the amplifier is a signing channel, and the executor is a legally written delegation.

4. Why "no private key leak" is worse news

If the private key had actually been stolen, this event could have been filed under the familiar drawer of "custody incident": swap the HSM, add more sharding, make the cold wallet even colder.

But this time it wasn't. The 50 authorizations visible on-chain were each signed by Binance 14's own private key. The key wasn't taken, but it was used. Blockaid co-founder Ido Ben-Natan gave this pattern a name: key misuse, as opposed to key leak.

"It appears the signing infrastructure was compromised. We don't think the key was leaked."

The severity here is that it moves the entire threat model one notch:

Old model (key leak) New model (key misuse)
Attack target The private key itself Get the signer to sign a payload it shouldn't
Defense focus Key storage (HSM / MPC / cold storage) Signing intent validation and permission granularity
Compromise signal Key exfiltration A signature that looks completely legitimate
Can revoke afterward? Only change address Can revoke delegation, but must discover first
Typical methods Theft, side-channel, insider Phishing, supply chain, operations terminals

The real design problem: why does a withdrawal service have permission to request a signature that says "delegate this account to this contract"?

What a withdrawal service needs is the semantic "transfer X from A to B." What an EIP-7702 authorization needs is "give execution authority of this address to contract C." These are two completely different orders of authorization, yet they go through the same signing channel, the same key. After gaining the service container, the attacker doesn't need to forge a transfer — they only need to make the signer do what it has permission to do, but was never designed to do.

This is a failure of permission granularity, not cryptography. It's the same error as "give ops a root that can drop the database," except this time the dropped thing was a hot wallet.

Binance's later disclosure of "more intrusion points" and co-founder He Yi's emphasis that this isn't something a "single engineer one-click operation" could accomplish, with the investigation not attributing to any individual, is worth noting: before the official post-mortem report, any "single point failure" narrative is just a simplification. Binance promises to publish a detailed technical review after the investigation and update its Proof of Reserves (PoR).

5. Freeze asymmetry: USDT can freeze $1.567B, BTC can't freeze a dollar

The most worth-repeated table in this event isn't the loss table — it's the freeze table.

Asset Frozen amount Who can freeze
USDT ~$1.567B Tether (contract-level admin permission)
USDC >$800M Circle (same)
RLUSD ~$200M Ripple assisted
USD1 / XUSD / USDT0 / WBETH / XAUT / PAXG / USDP Not individually disclosed Respective issuers
ARB Not individually disclosed Arbitrum ecosystem involvement
BTC (18,270 BTC, ~$1.47B) 0 No one can freeze

fig5-freeze-asymmetry.png

Bitcoin has no issuer, no admin key, no "please freeze this address" interface. These 18,270 BTC haven't moved much so far — not because the attacker doesn't want to, but because moving would be traceable, and the stablecoin route is already blocked by those two companies.

This brings three uncomfortable conclusions:

First, the "emergency brake" in the on-chain world is actually held by two or three private companies. This time it saved $3.0 billion, with astonishing efficiency — freezing within an hour, faster than the exchange's own emergency response. But the same privilege can fall on any ordinary token holder. Today you think it's useful because it wasn't you who got frozen.

Second, the attacker's optimal strategy has been structurally rewritten. In a market where "stablecoins can freeze, BTC cannot," a rational attacker will try to stay in BTC and ETH, stretching the laundering period to months. This explains why most assets are still "lying in wallets."

Third, and most counterintuitive: the most effective stop-loss measure in this event came from the part of the design many consider "the original sin of centralization." The decentralized narrative didn't save anyone that night.

6. Attribution: the same script, third time

TRM Labs attributes the attack with "high confidence" to North Korean hacking group TraderTraitor (the crypto-asset special unit under the Lazarus system); Chainalysis CEO gives the same judgment; Blockaid says the tactics are "highly similar to North Korean-related operations." TRM's listed characteristics include:

On-chain detective ZachXBT added a key link: on Oct 30, the stolen funds from the Binance case and the earlier Bitget case (~$350M) converged into the same address after passing through THORChain. The Bitget case has been attributed to TraderTraitor and overlaps with the Kelp DAO case from April 2026. The probability of a common source therefore rises significantly.

But the boundaries must be stated clearly:

Zooming out the timeline, this is a repeatedly validated script:

Time Event Amount Method
2025.02 Bybit ~$1.5B (400k ETH/stETH) Hijack Safe developer credentials → enter wallet provider backend → trick signer into approving malicious transaction
2026.04 Kelp DAO ~$293M Same kind of signing-side breach
2026.10 Bitget ~$350M Not fully disclosed
2026.10.29 Binance ~$6.3B Ops terminal → service container → signer → EIP-7702 delegation

In three out of four times, the breakthrough wasn't cryptography but "making people (or machines) sign what they shouldn't." CertiK data shows Q3 2026 crypto industry losses reached $1.28B, up ~56% quarter-over-quarter — and that's before the Binance event.

7. The cost: market, reserves, and confidence

Price side. BTC fell from a monthly high of ~$86,000, dropping below $76,500 (a six-week low, down over 5% intraday) as the event unfolded; ETH hit a low of $2,174; BNB fell 7%–10%. In 24 hours, liquidations reached $1.517B, 237k people were liquidated, with longs at $1.284B (85%). Coinbase stock fell ~5%, Strategy dropped nearly 6%.

Reserve side. This is where to watch. Binance 14 appeared in Binance's Oct 1 Proof of Reserves, meaning it is part of the assets backing user balances. According to ICRYPEX's estimate, the stolen ~204.5k ETH is about 5.6% of its ETH reserves, potentially dropping ETH coverage from 100% to ~94% — this figure is a third-party estimate, not Binance disclosure; the next PoR on Nov 1 is the verification point.

On payout capacity, the SAFU fund has hovered around $1B, currently holding 15k BTC (~$1.157B); Binance's latest PoR shows total reserves of ~$165.4B. CZ's own rough math: 6B loss − 3B frozen − 1B SAFU ≈ 2B gap, covered by company funds. He Yi put it more directly: "The company's revenue this year is enough to cover the loss." This can be compared to historical data: Binance's net profit was $12B in 2021 and $5B in 2023.

On-chain side. Contagion did occur, but didn't blow up. The attacker deposited $60M USDT into Aave, borrowed 19,762 WETH (~$44.6M), and Aave preemptively froze ~300 markets; because the position was overcollateralized, no bad debt arose, depositors were unharmed. This is a rare case of "large stolen funds entering DeFi without dragging the protocol under" — not because the protocol is stronger, but because the collateral ratio is sufficiently conservative.

Structural side. Standard Chartered's head of digital assets research, Geoffrey Kendrick, gives a two-stage judgment: short-term there will be more declines, but after assets are liquidated and details become clear, a new bottom will be found; medium-term it's a structural shift — the relative share of decentralized exchanges will continue to rise. His basis: in Q2 2026, the top-10 spot DEX/CEX trading volume ratio reached 23.5%, up 2.1 percentage points quarter-over-quarter, and Uniswap has never been directly breached. He maintains a UNI price target of $100 by 2030, and says this event makes that prediction "possibly still too low."

Trust transmission is slower and more expensive than price. Some reports say institutional funds are exiting centralized exchanges and rebalancing order books — the exact scale is unverifiable, but the direction isn't hard to judge: when the largest player can have $2.5B moved out in 15 minutes, custody risk must be repriced.

8. Four judgments for engineers

Whether you work on-chain or not, the lessons from this event can be carried over directly — because "authorization" is a universal problem.

First, treat "authorization" as a first-class citizen to audit, not an accessory.

EIP-7702 authorization, OAuth scope, cloud assumed roles, Agent tool permissions — essentially the same object: one signature, a period of execution power. Such objects must have four attributes, none less:

① TTL          —— expiry time, short by default
② Quota limit  —— double-layer: single + cumulative
③ Target whitelist   —— delegatable only to audited implementation contracts
④ Semantic constraint —— reject chain_id = 0 (cross-chain universal), reject unknown contracts,
                  reject batch authorizations with consecutive nonces in a single request

Point ④ is the most direct stop-loss for this event. A request for 50 consecutive nonce authorizations should be a massive red flag in any risk-control system — it's not a normal business pattern; it's a confession of "I don't know your nonce, so I'll just sign them all."

Second, the permission granularity of your signer needs to be finer than you think.

Just because a withdrawal service can sign transfers doesn't mean it can sign delegations. Categorizing "signing requests" by semantics is more important than sharding the private key: low-risk operations (small transfers) go through automatic signing; high-risk operations (modifying authorizations, batch operations, cross-chain) force manual or independent approval channels. Having two semantically different keys in the same HSM is the same as having no isolation.

Third, detection cost is extremely low — don't skip this step.

Any address delegated via EIP-7702 has a code field starting with 0xef0100. A single eth_getCode can detect it:

# Returns 0x if not delegated; returns 0xef0100<20-byte address> if delegated
curl -s <RPC_ENDPOINT> -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x28c6...1d60","latest"]}'

For exchanges, custodians, and any vault address holding large amounts, this should be a check that runs every minute, not a troubleshooting step you remember after an incident.

Fourth, this is especially important for people building AI Agents.

An Agent's tool-calling loop is essentially a signer: it decides "what to call, what parameters to pass" based on context. And prompt injection / plan injection is exactly trying to make it sign a payload it shouldn't — you don't need to steal its API key, just make your Agent think "this is part of the task."

This event gives a very direct mapping:

Binance this time Equivalent in Agent systems
DevOps laptop compromised Context pollution (retrieved web pages, read files)
Service container submits withdrawal request Agent calls a tool with parameters from untrusted input
Signer doesn't validate semantics Tool layer doesn't validate call intent, only token validity
50 consecutive nonce authorizations Multiple high-privilege calls in one task
Delegation lasted 3.5 hours without revocation Long-lived capability tokens nobody recycles
Stablecoin issuer emergency freeze Manual circuit breaker only after the fact

If your Agent has two tools, "read file" and "execute shell," and they share the same process privilege, then you've already copied EIP-7702's structural flaw into your own system. Least privilege isn't a compliance slogan; it's the only wall that remains after the signer gets fooled.

9. Four unanswered questions

As a record, listing the uncertainties separately is more valuable than pretending to know everything:

  1. Is EIP-7702 really the only vector? Blockaid and TRM both saw the 7702 delegation on-chain, but Binance's official announcement only said "unauthorized withdrawal transactions," without confirming the specific technical path. Until the formal post-mortem, this remains an on-chain inference.
  2. What are the "more intrusion points"? Binance's Oct 30 08:47 update mentioned "more intrusion points" but didn't specify which systems, how many, or whether third parties are involved.
  3. What is the final net loss? The $3.0B frozen is a dynamic number; TRM counted $2.7B, the difference comes from cutoff times and whether Arbitrum ecosystem disposals are counted. Whether frozen assets can be returned, and in what form (especially those converted to other assets), also has no statement.
  4. Is the payout really not touching user assets? The SAFU + company capital scope needs the Nov 1 PoR to verify. Whether reserve coverage truly dropped from 100% to 94% will be seen then.

In closing

This event is most easily misread as "Binance has poor security." I don't think so.

An institution that can coordinate Tether, Circle, Ripple, and Arbitrum to freeze $3.0B within an hour and promise full coverage is in the first tier of emergency response in the industry. Where it failed is more fundamental: it treated "custody of private keys" as the whole of security, but the attacker stopped living in that layer a long time ago.

Ten years ago, exchanges were hacked because private keys sat on internet-connected servers. Five years ago, because multi-sig signers could be socially engineered. Now, because the signer doesn't know what it's signing.

Each round of defense reinforces the previous battlefront. And this time, the battlefield has moved from "where the key is" to "who has the right to make it stamp."

If you take only one sentence from this article: granularity of permissions matters more than strength of permissions.

Data sources

Disclaimer

This article is technical analysis, not investment advice. The incident is still under investigation, and the technical review report Binance promised has not been released; the attack path described here partly relies on inferences from third-party on-chain analysis firms and may differ from the final official conclusion. All amounts are based on prices at the time of the event and change with market fluctuations. Please obtain event progress only through Binance's official channels, and be wary of any scams claiming to "help recover assets."