Binance's incomplete RCA: signed delegation, unexplained access
Reproduced Ethereum authorizations explain how a Binance hot wallet was delegated and swept; how the attacker obtained those signatures, and how the laptop account connects to them, is still unexplained.
By the Maborak Engineering Team
Binance’s root-cause analysis of the 29 October 2026 incident is incomplete. Public chain data shows valid signatures from a Binance hot-wallet authority installing EIP-7702 code delegation, followed by a sweep sent from a different account. No public source explains how the attacker obtained those signatures, or how the possible laptop and container entry point that Binance described leads to them. The company estimates the total impact at around $6.3B. [vendor] (Binance (opens in a new tab)); [reproduced] (delegation (opens in a new tab))
Checked 30 October 2026. Latest source retrieval: 14:52:07.873 UTC. Later disclosures are not covered. Labels: [vendor] for statements by Binance and Richard Teng, its co-CEO; [reproduced] for read-only RPC queries and offline signature checks run for this note; [inferred] for analysis. Researcher findings are attributed by name. No endpoint, container or signer forensics were available.
Update, 31 October 2026, 02:20 UTC
Binance published Security Incident Update #2, signed by co-CEOs Yi He and Richard Teng. The same text appears as an X Article (opens in a new tab) posted at 19:58 UTC on 30 October and on Binance’s support site (opens in a new tab), where the page is labelled “Published on 2026-10-30 19:33”. Richard Teng summarised it (opens in a new tab) at 20:00 UTC. Binance’s support site returns an anti-bot challenge to automated requests, so its text was read from the Internet Archive’s capture at 22:01 UTC (opens in a new tab); it matches the X Article. [vendor]
No new technical finding. On the root cause, Update #2 repeats what was already known: the incident “may involve a compromised laptop”, the investigation “has uncovered additional points of breach”, and “we have found no evidence that wallet private keys were leaked.” It says the team is working “to establish the full attack sequence” and expects “to share further technical findings within about 48 hours”, followed by “a detailed technical report”. [vendor]
One line touches the chain record: Binance says it “revoked affected authorizations”. The only revocation reproduced here is the hot wallet’s own zero-address authorization at 00:10:35 UTC on 30 October, described below; Update #2 does not say whether it means that transaction or others. [inferred]
Funds, withdrawals and reserves. [vendor]
| Item | Update #2 |
|---|---|
| Impact | “approximately $6.3B USD worth of token assets”, from “around 2026-10-29 20:05 (UTC)” |
| Company cover | “more than $6.34B in company funds”, with “$5B held in the exact impacted token assets”, “approximately 80% of the impacted amount”; the rest being bought “through market and OTC channels” |
| Who pays | Binance will cover losses through SAFU “and our corporate treasury” |
| Frozen | “Approximately $3 billion has been frozen on-chain to date”, unchanged from 10:55 UTC |
| Withdrawals | Still paused; target to “start resuming the withdrawal service within approximately 34 hours”, in phases, “subject to the completion of security checks” |
| Deposits | “Deposits and other unaffected platform services remain operational” |
| Proof of Reserves | “an initial Proof Of Reserves snapshot in 12 hours”, results “by Monday 2026-11-02” |
| Investigation | “Further technical findings within about 48 hours”, then “a detailed technical report” |
Counted from the 19:58 UTC post, those deadlines fall at about 07:58 UTC on 31 October for the reserves snapshot, about 05:58 UTC on 1 November for the first withdrawals and about 19:58 UTC on 1 November for the technical findings. The earlier 04:36 UTC post had said withdrawals would resume “within 48 hours”, which also points to early 1 November. These are our arithmetic on Binance’s own wording, not commitments to a clock time. [inferred]
At 02:12 UTC on 31 October, Binance’s X timeline (opens in a new tab) showed Update #2 pinned and nothing newer. No statement of resumed withdrawals, a Proof of Reserves result or new recovery figures had been published. Update #2 attributes the attack to no one; the North Korea attribution remains TRM’s (opens in a new tab), made “with high confidence”. The gaps this article lists, how the signatures were obtained and which approval control was bypassed, remain open. [vendor]
Update, 30 October 2026, 17:36 UTC
The operator account’s history before the theft is now reproduced. It shows the funding, test runs and rehearsal that TRM (opens in a new tab) describes. Method: historical balance and nonce queries on 0x7c8601…5ca0, then blocks, receipts and traces, all through dRPC alone.
| UTC | Operator activity | Evidence |
|---|---|---|
| 28 Oct, 07:39:47 | First funding: 0.0983 ETH from the Tornado Cash 0.1 ETH pool, via relayer | 0xd9e590…9008 (opens in a new tab) |
| 28 Oct, 08:53:59 | Second Tornado Cash withdrawal, 0.0979 ETH | 0xa79503…221a (opens in a new tab) |
| 29 Oct, 02:28:59 | First transaction: creates contract 0x19bee2…f2bf |
0x6b76e8…06d8 (opens in a new tab) |
| 29 Oct, 08:23:11 | Third Tornado Cash withdrawal, 0.0979 ETH | 0x18ae9a…1cae (opens in a new tab) |
| 29 Oct, 13:51:35–14:24:11 | Delegates two test wallets to that contract, with 2 and 3 consecutive-nonce authorizations, then calls each | 0x16b5ac…9dca (opens in a new tab), 0xec5af2…21d9 (opens in a new tab) |
| 29 Oct, 15:59:11 | Creates the final delegate 0x63e842…6fae |
0x97408e…329c (opens in a new tab) |
| 29 Oct, 16:20:47–16:47:23 | Rehearsal: delegates a third wallet to the final delegate, then calls it twice | 0xb2148e…5782 (opens in a new tab), 0x2b8eb6…f58f (opens in a new tab) |
| 29 Oct, 18:20:47 | Receives 1.0822 ETH from unidentified account 0xe4f907…74cd |
0x96cae1…ebe5 (opens in a new tab) |
| 29 Oct, 20:20:59 | Installs the delegation on the Binance hot wallet with 50 authorizations | Reproduced above |
[reproduced] The pool 0x12D66f…B8Fc and the router 0xd90e2f…F31b used by all three withdrawals are on Treasury’s 8 August 2022 Tornado Cash designation (opens in a new tab). The first funding came 36h25m before the first XRP outflows. The rehearsal delegation came 4h00m12s before the Binance installation, which matches TRM’s “four hours after that rehearsal.” The test wallets used the same consecutive-nonce batching later used against Binance. All three still carry their delegation code. The test wallets’ owners are not identified.
These transactions establish that the attack code was deployed, tested and rehearsed on-chain during the 18 hours before the theft. They do not date the Binance signatures or show how they were obtained. TRM notes that “early indicators” suggested phished authorizations, but says that explanation “leaves the other chains unexplained.” [inferred]
TRM also reports a later wave around 23:05 UTC reaching Binance wallets on Avalanche and Polygon; this was not reproduced here. On attribution, TRM states “high confidence” in North Korea’s TraderTraitor. Investigator ZachXBT (opens in a new tab) reported at 04:51 UTC on 30 October that Binance funds arriving via THORChain were commingled at 0x15104a…feb7 with proceeds of the $388M Bitget exploit, which he says “indicates the same actor is likely behind both incidents.” Neither attribution was reproduced here.
Update, 30 October 2026, 16:09 UTC
Two further read-only chain checks extend the reproduced path. Both follow leads first published by Blockaid (opens in a new tab). They used dRPC only (eth_getTransactionByHash, eth_getTransactionReceipt, eth_getTransactionCount, eth_getCode, trace_transaction and debug_traceTransaction), without a second provider. The two trace methods agree. The original article below is unchanged.
Preparation started hours earlier. The account that later submitted the 50 authorizations created the delegate contract 0x63e842…6fae in 0x97408e…329c (opens in a new tab), block 26,299,449, at 15:59:11 UTC on 29 October. That is 4h21m48s before the delegation and about four hours before the first XRP outflows TRM reports. The account’s nonce was already 5, so it had sent five earlier transactions. [reproduced] This dates the attacker’s on-chain preparation, not the signatures: a contract address created this way can be computed in advance from the sender and its nonce, so the authorizations could have named the delegate before it existed. [inferred]
The delegation reached a contract that trusted the wallet. In 0xdc102d…7481 (opens in a new tab), block 26,300,855 at 20:41:23 UTC, the same outer sender called the delegated hot wallet. The call trace shows the hot wallet calling smart account 0xee7ae85f2fe2239e27d9c1e23fffe168d63b4055 with selector 0xb61d27f6, commonly execute(address,uint256,bytes). The smart account accepted the call and transferred 780,000,000 USDC to the sweep destination. [reproduced] The smart account authorized its caller by address. Once that address ran attacker-chosen code, a contract that trusted it was exposed as well. Blockaid labels the smart account as Binance’s and reports a further 43m USDC. The account’s authorization rules were not decompiled. [inferred]
Sweeps continued after the first burst. A later call through the delegated wallet, 0x55ba4d…0556 (opens in a new tab) at 21:44:11 UTC, moved 200,397,771.82 USDT and other tokens to the same destination. [reproduced]
These findings do not change the open question: how the attacker obtained the hot wallet’s authorization signatures.
The timeline from chain data and company statements
| UTC | Event | Evidence |
|---|---|---|
| 29 Oct, 20:05 | TRM reports XRP Ledger outflows beginning, before any Ethereum delegation | TRM report |
| 29 Oct, 20:20:59 | Type-4 transaction installs delegation on the hot wallet, block 26,300,753 | [reproduced] |
| 29 Oct, 20:24:23 | Same outer sender calls the delegated wallet; 167,464.2479 ETH moves out | [reproduced] |
| 30 Oct, 00:10:35 | Zero-address authorization; wallet code is empty at block 26,301,896 | [reproduced] |
| 30 Oct, 02:25 | Initial statement, visible “last edited” time: possible laptop, container, withdrawals | [vendor] |
| 30 Oct, 04:36 | “Multiple factors”; the computer “may be the entry point” | [vendor] |
| 30 Oct, 07:37 | Teng: not one engineer’s permissions, not a single “one-click” action | [vendor] |
| 30 Oct, 08:47 | “Additional points of breach”, not named | [vendor] |
| 30 Oct, 14:33:37 | Teng’s written transcript names EIP-7702 delegation outside normal approvals | [vendor] |
(TRM (opens in a new tab), initial (opens in a new tab), 04:36 (opens in a new tab), 07:37 (opens in a new tab), 08:47 (opens in a new tab), 14:33:37 (opens in a new tab))
The initial post’s 02:25 timestamp is an edit label, so it does not show what the first version said. The 14:33:37 transcript accompanies a video posted at 14:32:09, and Binance’s account shared it at 14:34:37. The written transcript was checked; the audio was not transcribed independently.
What Binance has said about access and approvals
The initial statement says the 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 adds: “We have found no evidence of any wallet private key leak.” [vendor] (initial (opens in a new tab))
Teng’s 14:33 transcript says: “Our initial investigation suggested that the security incident may have involved a compromised laptop, however our subsequent investigation has uncovered additional points of breach.” On the mechanism, it says exactly: “The attacker used a known multi-signature protocol EIP-7702, to obtain on-chain execution approval over a hot wallet. That delegation did not pass through our normal approval controls.” [vendor] (transcript (opens in a new tab))
The description of EIP-7702 in that quote is inaccurate. The specification (opens in a new tab), titled “Set Code for EOAs”, lets an account’s key sign an authorization that points the account at contract code. It is code delegation, not a multisignature scheme, and the quote says nothing about Binance’s internal signing topology. What the statement does add is a company finding that the delegation bypassed normal approval controls. It does not say which control was skipped, who or what requested the signature, or why the request was not stopped.
The transcript also says: “The attacker also used a self-destruct mechanism that destroyed tooling and traces as they went, making it more difficult for us to trace and investigate.” No host, artifact or timestamp accompanies it. This is a company statement that was not reproduced here, and it does not refer to the EVM SELFDESTRUCT opcode. [vendor] (transcript (opens in a new tab))
The reproduced Ethereum path
The reproduction used read-only JSON-RPC methods (eth_getTransactionByHash, eth_getBlockByNumber, eth_getTransactionReceipt, eth_getCode, eth_getTransactionCount, trace_transaction) against dRPC (opens in a new tab) and PublicNode (opens in a new tab). Both returned the same signed transactions and block headers. Historical code, nonces and the sweep trace come from dRPC alone: PublicNode answered all six historical code requests with HTTP 403. Transaction hashes and signatures were then recomputed offline. No local node, state proofs or full block replay were used, so the results reflect provider-returned data checked for internal consistency.
The installation transaction, 0xad9926…1298b (opens in a new tab), is type 4, in block 26,300,753 at 20:20:59 UTC. Its outer signature recovers 0x7c8601d4645b93cea45f71e118a729332e6b5ca0. It targets 0x28c6c06298d514db089934071355e5743bf21d60, which Blockaid (opens in a new tab) labels “Binance 14”; that ownership label is researcher attribution, not chain data. The transaction carries 50 authorization tuples, and the signature in every one of them recovers the hot-wallet address, not the outer sender. All 50 point at delegate 0x63e842b054bd624a465454d533c33f573e9c6fae. The wallet’s code is empty at block 26,300,752 and 0xef0100 plus the delegate address at 26,300,753. [reproduced]
The signatures are valid under the protocol’s recovery rules. The chain did not accept a forged signature; the wallet’s own authority signed these delegations. Someone else submitted them.
The tuples carry nonces 18,914,824 down to 18,914,775. EIP-7702 applies a tuple only when its nonce equals the authority’s current nonce, then increments it, so the 49 others fail even though their signatures are authentic. The wallet’s nonce was 18,914,808 at the end of the previous block. In the same block, an ordinary wallet-originated transaction (opens in a new tab) at position 133 used nonce 18,914,808, before the installation at position 138. That left 18,914,809 current, which is the tuple Etherscan’s authorization table (opens in a new tab) marks valid. The end-of-block nonce, 18,914,810, agrees. [reproduced], with the valid-tuple flag taken from the explorer.
At 20:24:23 UTC, 204 seconds after installation, the same outer sender called the wallet in 0x53bd38…e2f3 (opens in a new tab). The outer transaction has zero value and no authorization list; the trace shows the wallet sending 167,464.2479 ETH to 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c. Once installed, the delegation needed no further wallet signature. [reproduced]
The clearing transaction (opens in a new tab) is signed by the hot wallet itself, with outer nonce 18,914,903 and a zero-address authorization at 18,914,904; the sender nonce increments before authorizations are processed. Code is still delegated at block 26,301,895 and empty at 26,301,896, 00:10:35 UTC on 30 October, 3h49m36s after installation. These are sampled block states, not continuous observation, and clearing a delegation is not evidence about key rotation or remediation. [reproduced]
What each type of evidence can and cannot prove
| Evidence | Establishes | Does not establish |
|---|---|---|
| Company statements | Binance’s current findings: possible laptop entry, container access, extra breach points, approval bypass, self-destruct claim | Infection route, container identity, the breach points, the control that failed |
| Recovered signatures | The hot-wallet authority signed 50 delegations; another account submitted them | When, where or through which interface they were signed; whether a key was extracted |
| Nonces and block order | Which tuple applied and why | That the attacker lacked the live nonce, or how long access lasted |
| Code and trace (dRPC) | Delegation installed, used for the sweep, cleared later | Consensus-validated state; continuous state between samples |
| Researcher reports | Ordinary signed transfers from other wallets and chains | Internal forensics; key custody |
An EIP-7702 authorization signs only the chain ID, delegate address and nonce. It contains no signing time and nothing about the later sweep. The signatures existed by 20:20:59; they could have been produced long before. Neither the 50-nonce window nor the 204-second gap measures how long anyone had access to a signer. Valid signatures are also equally consistent with a misused signing service and with an extracted key, so Binance’s “no evidence” of a key leak is a statement of investigative status, not an exclusion. [inferred] (EIP-7702 behaviour (opens in a new tab))
Signer-service compromise is an assessment
TRM writes that “the most likely explanation is that the attacker gained the ability to make Binance’s hot wallet signing system sign transactions of its choosing across chains,” and says the 50 authorizations suggest “the access may have been limited in time, or that signatures had to be requested through a system.” Elliptic says the attacker “appears to have been able to get Binance’s own systems to sign transactions on their behalf.” (TRM (opens in a new tab), Elliptic (opens in a new tab))
Their strongest supporting observation is that other wallets, including one on Ethereum and wallets on several other chains, sent funds through ordinary signed transfers with no delegation. One such Ethereum transfer, 0x51f263…d39f (opens in a new tab), was retrieved for this note: a direct value transfer with no authorization list, signed by the wallet Blockaid labels “Binance 16”. [reproduced] This rules out delegation as the explanation for the whole incident. It does not show whether the attacker drove one signing service or held several keys.
Blockaid’s current text calls it a “hijacked signing service”; a saved comparison with an earlier snapshot shows the wording became stronger without new signer logs. Chainalysis (opens in a new tab) describes “valid signed authorizations” and ordinary transfers without an internal path. The evidence these firms publish is chain data; none of it demonstrates access to Binance’s hosts or signer logs. (Blockaid (opens in a new tab))
The unestablished links
The laptop and container account and the reproduced path describe different layers. Binance says a container was used to “submit unauthorized withdrawal transactions”; on Ethereum, the delegation and sweep were submitted by an outside account carrying the wallet’s signatures. No public source says whether the container produced those signatures, requested them from a signer, or played no part in them. [inferred]
Still undisclosed in the sources checked: the laptop’s infection route; the container and the credential used; what the “additional points of breach” are and how they relate to the laptop; the signing request behind the 50 authorizations and the system that served it; the approval control the delegation avoided and why; and any key-export audit.
The Ethereum execution path is reproducible. The path from the laptop to the signatures is not established. Binance has said a technical post-mortem will follow; until then, the root cause remains a company account with a gap where the signature acquisition should be.
Sources
- Binance and Richard Teng on X, 30 October 2026: initial statement, last edited 02:25 UTC (opens in a new tab) (impact estimate, laptop and container, key-leak wording); 04:36 (opens in a new tab); Teng, 07:37 (opens in a new tab); 08:47 (opens in a new tab); Teng video, 14:32:09 (opens in a new tab); Teng transcript, 14:33:37 (opens in a new tab); Binance share, 14:34:37 (opens in a new tab). Binance support and Square pages returned WAF challenges and were not read.
- Researcher reports, current versions retrieved 30 October 2026, 14:50 UTC: TRM (opens in a new tab) (metadata: published 02:10, modified 02:38 UTC); Elliptic (opens in a new tab) (modified 13:16 UTC); Blockaid (opens in a new tab) (modified 14:27:54 UTC); Chainalysis (opens in a new tab) (modified 10:41 UTC).
- EIP-7702: Set Code for EOAs (opens in a new tab), checked 30 October 2026: authorization digest, nonce rules, delegation and clearing.
- Transactions: installation (opens in a new tab), same-block wallet transaction (opens in a new tab), sweep (opens in a new tab), clearing (opens in a new tab), Binance 16 transfer (opens in a new tab).
- Read-only reproduction, 30 October 2026, 14:50 to 14:52 UTC: dRPC (opens in a new tab) and PublicNode (opens in a new tab) JSON-RPC, chain ID 1, head block 26,306,279. Offline reserialization reproduced the installation, sweep and clearing hashes and outer senders from both endpoints, and recovered the hot-wallet authority from all 50 installation authorizations. Historical code, nonce and trace results depend on dRPC; PublicNode returned HTTP 403 for historical code. No local node, state proofs, full block replay, delegate decompilation or non-Ethereum replay.
