From developer access to wallet authority
Binance’s preliminary account links a tampered installer in June, a malicious interview assignment in September and a compromised internal AI tool on October 20. The attackers obtained a container-deployment token and used it in the wallet environment on October 29. Binance reports 233.46 million XRP leaving five hot wallets between 20:05 and 20:09 UTC, followed by activity across other networks and malicious Ethereum delegation. It places the last unauthorized transfer, 2,961.9 ETH, at 23:56 UTC, and the delegation reset at 00:10 UTC on October 30.
Jepeta’s interpretation is that this sequence crossed different authority boundaries: running code on a workstation, deploying software into a privileged environment, requesting wallet signatures, and retaining authority on Ethereum. A control that interrupts one transition need not stop the next. The report does not establish that an AI model independently planned the intrusion; it describes attackers using an internal tool as a pivot.
What the evidence establishes
| Evidence class | Supported statement | What it does not establish |
|---|---|---|
| Binance claim | Approximately $6.34 billion in digital assets were impacted, in its November 3 initial report | A final reconciled loss, or an independently verified dollar total |
| Binance claim | Approximately $2.85 billion was frozen or intercepted | That all of it was returned or is immediately spendable |
| Binance recovery claims | Update #5 describes about 95% of the impacted amount covered; the initial report describes 98% of impacted token assets replenished as of October 31 | A common denominator or recovery of the stolen assets |
| Official attribution | The FBI’s October 31 alert attributes the theft to North Korea-linked TraderTraitor actors | Independent identification of the operators by Jepeta |
| Verified protocol text | EIP-7702 specifies persistent delegation and a zero-address clearing mechanism | Proof of the reported incident transactions |
| Independent indexer check | Blockscout records a successful type-4 transaction carrying 50 EIP-7702 authorizations on October 29 (one valid by nonce) and a successful zero-address clearing authorization on October 30 for the same wallet. | A historical state replay, the compromise mechanism inside Binance, incident-wide asset flows, attacker identity or a final reconciled loss. |
| Jepeta interpretation | Withdrawal controls and delegation recovery protect different boundaries | A tested counterfactual showing which control would have stopped this intrusion |
The November 2 recovery update and November 3 initial report do not reconcile their replenishment percentages. We retain their different wording rather than treating the figures as interchangeable. Replenishment from Binance’s own funds is also different from recovering an attacker’s funds. Subtracting the frozen amount from the affected amount would not establish a final loss: restrictions on frozen assets, reconciliation and valuation still matter.
In recovery update #6, Binance announced further phased withdrawals from November 3 after an initial reopening on November 1. Availability is specific to an asset and network. The notice directs users to the official withdrawal or network-status page; it does not announce unrestricted availability for every pair.
Why stopping withdrawals did not clear the permission
EIP-7702 lets an Ethereum account point to contract code that executes in that account’s context. This is an account-level delegation, not merely an ERC-20 spending allowance. Once a valid authorization has been processed, stopping an exchange’s withdrawal interface does not change Ethereum account state. The specification also says a later execution failure does not roll back a processed delegation.
Ethereum’s implementation guidance explains that the original account key retains authority after delegation. Delegating to a contract with a multisignature policy does not, by itself, remove the original key’s ability to bypass that policy. An operator must therefore evaluate the controlling key path as well as the delegated contract’s rules.
Binance says clearing the delegation required an additional on-chain authorization, complicated by its multi-party computation (MPC) signing arrangement. That is not evidence that MPC cryptography failed. In Jepeta’s analysis, keeping key shares separate and deciding whether a signing request is legitimate are distinct controls. If a compromised system can satisfy the operative signing process, key secrecy alone does not demonstrate that the resulting authorization was intended.
Which controls address which failure
The comparison below is Jepeta’s analysis of the reported boundaries and protocol rules. It describes controls to evaluate, not controls we tested against Binance or proved would have prevented the incident.
| Control | Boundary it can constrain | Remaining exposure |
|---|---|---|
| Isolated review of untrusted code | Keeps interview assignments and installers away from work credentials | Isolation is ineffective if production secrets or privileged sessions are available inside it |
| Short-lived, narrowly scoped deployment identity | Reduces how long and where a stolen deployment credential can work | A valid credential can still be abused within its permitted scope and lifetime |
| Independent signing-policy approval | Separates authority to deploy software from authority to approve a transfer or delegation | Two approvals add little independence if the same compromised system controls both |
| MPC, HSM or hardware key custody | Can reduce exposure of complete signing-key material | Key protection does not determine whether a requested action is legitimate |
| Decoding, simulation and delegation allowlists | Can expose unexpected recipients, code targets and permissions before signing | They depend on accurate inputs and enforcement; allowlisted code can still have unsafe behavior |
| Withdrawal pause | Stops activity that depends on the paused service | Does not itself clear an existing Ethereum delegation or reverse a confirmed transfer |
| Tested delegation-recovery procedure | Provides a separate route to inspect and clear unwanted account authority | Requires trustworthy authorization, correct account state and successful on-chain inclusion |
A useful acceptance question is: can deployment access change the policy that approves signing? If the same authority can replace both the requester and its approval gate, an extra approval screen may leave the trust boundary unchanged. A second question is whether responders can inspect and clear delegations while the ordinary withdrawal service is unavailable. Those questions test separation of responsibility; they do not depend on a particular wallet brand.
Clearing a delegation is not complete incident recovery. An exposed deployment identity, compromised endpoint or still-authorized signing path can enable another unauthorized action. Recovery planning should address both the account permission and the authority that could recreate it. This is a design implication of the reported chain, not a claim that Binance left those paths open.
Independent Ethereum check: EIP-7702 delegation and revocation
Jepeta examined two Ethereum mainnet transactions through Blockscout's read-only index on November 4, 2026. The records connect a type-4 delegation authorization with a later type-4 clearing authorization for the address labeled Binance 14 (`0x28C6c06298d514Db089934071355E5743bf21d60`). The label comes from public explorer data; this is a transaction-record check, not an audit of Binance's signing infrastructure.
| Event | On-chain observation | Transaction evidence |
|---|---|---|
| Delegation installation — October 29, 20:20:59 UTC; block 26,300,753 | A successful type-4 transaction submitted 50 authorization tuples for Binance 14, all on Ethereum mainnet and all naming `0x63e842B054Bd624a465454D533C33F573e9c6fAe` as delegate. The nonces ran from 18,914,775 to 18,914,824. Blockscout marks one tuple valid (nonce 18,914,809) and 49 invalid due to nonce mismatch. | Delegation transaction |
| Delegation clearing — October 30, 00:10:35 UTC; block 26,301,896 | A successful type-4 transaction from Binance 14 to itself included one valid authorization for the same authority, nonce 18,914,904, pointing to the zero address (`0x0000000000000000000000000000000000000000`). | Clearing transaction |
The transactions are 3 hours, 49 minutes and 36 seconds apart. EIP-7702 requires authorization nonce matching and defines a zero-address authorization as clearing the account's delegation code. That means the 50 submitted tuples must not be described as 50 successful delegations. The later clearing record supports Binance's reported recovery step, but a signed on-chain authorization does not show whether a private key was exported or how an internal signing approval was compromised.
Verification boundary: Jepeta checked indexed transaction records and authorization-list status. We did not replay either transaction with our own node, independently compare historical account code before and after revocation, identify the attacker from chain data, or reconstruct incident-wide flows. The previous 0.001 ETH incoming transfer is not used as incident proof because an unrelated payment to a listed address does not establish when unauthorized transfers stopped.
Practical checks for operators and users
For wallet operators: inventory which identities can deploy, change signing rules, authorize delegations and execute recovery. Exercise a withdrawal-service outage in an isolated test environment and verify that the recovery route remains usable. Review the target contract, chain context, authority and account state when approving delegation changes. A written runbook without a successful recovery exercise leaves that dependency untested.
For self-custody users: use the wallet provider’s documented, read-only account or delegation inspection. An ERC-20 allowance checker alone does not establish that account-level delegation is clear. If something is unexpected, stop signing and consult the wallet’s authenticated support documentation. Do not use an unsolicited “revocation” link or disclose a seed phrase. Our EIP-7702 account-state guide explains why the transaction result alone is insufficient.
For Binance customers: check the exact asset/network pair through the official app or website, and review account activity without assuming the internal wallet incident proves your personal login was breached. Exchange custody and self-custody allocate different responsibilities. A personal hardware wallet cannot repair an exchange’s internal signing environment, and a device cannot make every action you approve safe.
Questions the evidence can answer
Did all 50 EIP-7702 authorizations take effect? No. The October 29 transaction contained 50 authorization tuples, but Blockscout classifies one as valid and 49 as invalid due to nonce mismatch. A submitted authorization is not the same as an executed delegation.
Why didn't stopping withdrawals remove the risk? A withdrawal pause restricts exchange-controlled operations. It cannot, by itself, clear a delegation already stored in Ethereum account state. A separate valid zero-address authorization was needed to clear that delegated code.
Does the chain prove Binance's private-key material was stolen? No. The two transactions demonstrate that valid account authorizations were produced and later cleared. They do not distinguish stolen key material from abuse of a compromised signing system. Binance's description of its internal compromise remains a vendor account, not an independently audited finding by Jepeta.
Evidence and source-review method
- structured comparison — Jepeta maps each proposed control to its permission boundary and remaining exposure, and distinguishes reported loss, freezing and replenishment measures. This is analytical comparison, not a tested prevention claim. · evidence · observed Nov 4, 2026
- source audit — Read-only Blockscout checks of two Ethereum mainnet type-4 transactions compared timestamps, blocks, the wallet authority, delegate address, nonce range and authorization-list status. Of 50 tuples in the installation transaction, only one is marked valid by the indexer; the later transaction includes a valid zero-address clearing authorization. This is an indexer-record review, not an archive-node replay, internal-security audit or incident-wide loss calculation. · installation evidence · clearing evidence · observed Nov 4, 2026
Editorial transparency
Jepeta is the accountable publisher. AI-assisted drafting and source verification were separate passes of the same AI workflow. We inspected the cited documents, compared permission controls and examined two Ethereum type-4 transaction records through Blockscout, including their authorization lists and status. We did not access Binance's internal systems, audit reserves, independently identify the operators, replay historical Ethereum state or obtain a human expert review. See About, Editorial Standards and Sources and Trust Center. Report a correction with this article's URL and supporting evidence through Contact.
Sources
- Binance: October 29 incident initial findings, November 3 · primary · verified Nov 4, 2026
- FBI: North Korea responsible for Binance attack, October 31 · primary · verified Nov 4, 2026
- Ethereum EIP-7702: Set Code for EOAs · primary · verified Nov 4, 2026
- Ethereum.org: EIP-7702 implementation guidelines · primary · verified Nov 4, 2026
- Binance: Recovery Update #6, November 3 · primary · verified Nov 4, 2026
- Jepeta: EIP-7702 delegation after a failed transaction · jepeta · verified Nov 4, 2026
- Ethereum.org: wallet types, custody and key responsibilities · primary · verified Nov 4, 2026
- Binance: Recovery Update #5, November 2 · primary · verified Nov 4, 2026
- Blockscout: Binance 14 delegation authorization transaction, October 29 · indexed Ethereum transaction · checked Nov 4, 2026
- Blockscout: Binance 14 zero-address clearing authorization, October 30 · indexed Ethereum transaction · checked Nov 4, 2026
