On 29 October 2026 at 20:20:59 UTC, one Ethereum transaction carried 50 signatures from Binance's hot wallet "Binance14", each authorizing that wallet to run a contract the attacker's account had deployed 13. A hot wallet is an exchange account kept online so it can pay customers quickly. All 50 signatures are cryptographically valid, but only one took effect 16. With it, Binance 14 ran the attacker's code as its own for 3 hours 49 minutes 36 seconds, until Binance cleared it. In that window the attacker took assets seven times 15. These are our own measurements from the replies of two public Ethereum data providers, and we compute no dollar values. Apart from a small sample re-read from an explorer's index, they have not been independently reproduced 1. How the signatures were obtained is known only from Binance's own account, which describes unauthorized access to an internal signing service and gives no mechanism 2. That route, and where the assets went, are the subject of Part Two. Our thesis is a reading, not a finding: a signing service can produce valid signatures for actions the organization never meant to approve, and those signatures can create authority outside the path the organization uses to stop withdrawals. Sources are read through 12 November 2026.

• Thesis (our reading). Valid signatures from a signing service created an authority on chain that Binance's withdrawal suspension did not reach 2.
• Fifty signatures, one landed. One transaction carried 50 authorizations, all signed by Binance 14's key. One took effect, chosen by the wallet's transaction counter at that moment 16.
• The authority stood 3 hours 49 minutes 36 seconds1. Binance says suspending withdrawals "could not stop all unauthorized asset movements" 2.
• What went through. Seven asset-taking calls, while automated deposits kept refilling the wallet 1.
• A counterfactual. For roughly the first three minutes, clearing the delegation could have been undone with an unused signature, depending on how the revocation was sent16.
• Not established. How the attacker reached the signing service, when the signatures were made, and when withdrawals were suspended 2.

What does the record offer? It depends on which desk you sit at.

• Incident responders. For roughly three minutes after the delegation was installed, revoking the attacker's access could have been undone with a leftover signature, and how long depends on how the revocation is sent 16.
• Wallet and custody engineers. The 50 signatures were not withdrawals. They were EIP-7702 authorizations, whose signed message has three fields and no timestamp 16.
• SOC analysts and detection engineers. Binance 14 went from having no code to running the attacker's code at 20:20:59 UTC, 3 minutes 24 seconds before the first sweep 1.
• Treasury and operations teams. Automated transfers kept refilling the compromised wallet, including one of 200,000,000 USDT that was swept 72 seconds after it arrived1.
• Trust and safety teams. Tether froze the main receiving address 37 minutes 12 seconds after the first sweep. 700,000,000 USDT had already left it 115.

"We" is hwtn.io's research pipeline. AI models read the sources, ran the measurements and drafted this text. Three AI models from three different labs fact-checked the text it was split from, and a person, the author, made the rulings.

We decoded the transactions ourselves from the replies of two public Ethereum data providers, scanning blocks 26,300,640 to 26,301,940 (19:58:23 UTC on 29 October to 00:19:23 UTC on 30 October 2026) 1. A node is a computer running Ethereum's software with a copy of the shared record. JSON-RPC is the standard way to ask a node questions, and a provider answers through an endpoint that may sit in front of several nodes or shared infrastructure, so two providers are not proven to be two independent nodes. A block is a batch of transactions added to the record together, about every 12 seconds. A transaction is mined when it is included in a block. An address is the public identifier of an account, a string beginning 0x. A comparison of 53 sampled block fingerprints between the two providers found no mismatch 1. That checks the data we received, not our code or our accounting. We used no explorer for these values. An explorer is a website, such as Etherscan or Blockscout, that indexes the chain for searching. We computed no dollar values, so every USD figure here belongs to the party named beside it 1. (If you see a dollar sign, it isn't ours.) Three Etherscan pages, read on 11 November 2026, show the delegation, the first sweep and the revocation. Their "Exploiter" labels are Etherscan's statement, not chain data 345. Where another publisher reported an observation before we measured it, we name the publisher. Several of them, such as ChainWard, Maborak, Hakhub and Oligamy, are small outfits, individuals' blogs or a software company's blog, cited only to credit who published a fact first 891014.

A factual point appears only if it rests on a primary source, a legitimate secondary source marked for what it is, or two weak sources that do not derive from each other. Our own readings stay in, labeled as readings. The claim register at the end gives each claim's status.

Binance's 3 November report is the victim's own account, and it calls itself "our initial report" 2. Our copy is text saved on 11 November 2026, not compared with the live page. We have read no later Binance statement. Chain times and our conversions are UTC. Chainalysis's start time of "around 4:20 p.m. ET" is 20:20 UTC, the minute of the delegation, because US daylight saving time was still in force on 29 October 11. This is Part One of two. Each part is meant to stand alone. If a term is new, it is in bold where it first appears and again in the glossary at the end. The long strings beginning 0x are addresses and transaction IDs. They are there so anyone can check our work. You can skip them.

The odd fact at the center of this theft is that a signature can be perfectly valid and still do nothing. To see why, you need three ideas first: a signature, a nonce and a delegation.

A signature is cryptographic proof that the holder of a secret key approved a particular message. From the signature and the message, anyone can work out which account signed. This is called "recovering" the signer. Every Ethereum account that is controlled by a key has a nonce, a counter that goes up by one each time the account acts. Ethereum uses it to put an account's actions in order and to stop an old instruction being replayed. A delegation comes from EIP-7702, a 2025 change to Ethereum. It lets an ordinary key-controlled account point at a smart contract, a program stored on the chain, and run that program's code as if it were the account's own. The account's owner grants it by signing an authorization, a small message with three fields: the chain it is for, the contract to run and a nonce. The specification warns that the code named this way "has unrestricted access to the account" 6.

The transaction. At index 138 (its position in the block) of block 26,300,753, mined at 20:20:59 UTC, the attacker's account (0x7c8601d4645b93cea45f71e118a729332e6b5ca0) sent Binance 14 (0x28C6c06298d514Db089934071355E5743bf21d60) a type-4 transaction, the kind that carries authorizations 13. Its hash, the fingerprint that identifies it, is 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b. It carried 50 authorizations, one for each nonce from 18,914,775 to 18,914,824, all for chain id 1 (Ethereum's main network) and all naming one contract, 0x63e842B054Bd624a465454d533C33F573e9c6fAe13. That contract is a 1,674-byte sweeper, a program for moving everything out of an account, which the attacker's account had deployed at 15:59:11 the same day 1. To deploy a contract is to publish its code to the chain, where it gets an address of its own.

Valid, and took effect. All 50 signatures recover to Binance 14 under EIP-7702's message format 16. Exactly one took effect 1.

The rule. EIP-7702 checks each authorization's nonce against the signer's nonce at the moment the transaction runs 6. The signed message carries no time at all 16. Our paraphrase, with the other checks left out:

# Pseudocode. Our paraphrase of one part of EIP-7702. Not runnable.
for each authorization in the list, in list order:
    signer = the account recovered from the authorization's signature
    if authorization.nonce != signer's nonce right now:  skip it
    signer's nonce = signer's nonce + 1
    point signer's code at authorization.address    # the all-zeros address clears it
# A skipped authorization does not stop the list. No step reads a clock.

So why that one? Binance 14's nonce stood at 18,914,809 when the transaction ran. The authorization for 18,914,809 matched, the nonce became 18,914,810, and the wallet's code went from empty to 0xef0100 followed by the sweeper's address 1. 0xef0100 is the marker Ethereum writes to show that an account's code is delegated. The chain's end-of-block state, the record of every account as it stood when the block closed, agrees with the rule 16. The short version: each of the 50 signatures was good for one value of the wallet's counter, and the counter stood at 18,914,809, so that signature was the one that worked. No source we read alleges a flaw in EIP-7702 1217.

What chose the one. Five places earlier in the same block, at index 133, Binance 14 used its nonce 18,914,808 for an ordinary-looking transaction: it called a function on a second wallet, which Blockaid's write-up labels Hot Wallet 34, and Hot Wallet 34 sent 5.000000 USDC to an outside address 1213. That moved Binance 14's nonce to 18,914,809. Without that transfer, the authorization for 18,914,808 would have matched instead and installed the same delegation 1. Different ticket, same result. Our inference, which changes nothing above, is that it was an ordinary customer withdrawal. At 20:25:35 the same route sent that address 3,156.562125 USDC, a small test followed by the rest 1. The address forwards to a wallet that took in USDC from thousands of small deposit-style addresses in the two months to 12 November and sent one daily batch on, consistent with an ordinary service 1. We have not identified the recipient and print nothing more about either address.

The 5 USDC transfer did not let anyone in; it only decided which of 50 waiting signatures the chain would accept.

The band of signed nonces. The 50 authorizations covered a band of nonces, and the delegation would install whenever the wallet's own nonce stood anywhere inside it. Binance 14 used the lowest signed nonce, 18,914,775, at 20:17:47 and the highest, 18,914,824, at 20:24:23, so the band spanned 6 minutes 36 seconds of the wallet's own traffic 1. ChainWard published the 20:17:47 observation, and Maborak the index-133 transaction, before we measured them 89.

Data: Hawthorne's on-chain measurements 1: Binance 14's account nonce at 60 points from 20:15 to 20:27 UTC, and the 50 signed nonces, as measured 12 November 2026.

The order. The list runs in descending nonce order 1, which Hakhub and Maborak published before we measured it 109. With the same authorizations in ascending order and the same starting nonce, 16 would have taken effect one after another, 18,914,809 through 18,914,824 16. That is a computed counterfactual, a what-if worked out from the rules, not an observed event. Our reading is that the descending order was a choice, since it spends one of the wallet's nonces instead of sixteen. (A reading. We cannot see the attacker's reasons, only the list.)

The rehearsal. Earlier the same day, the attacker practiced the technique in public on accounts of its own. The attacker's account first held ETH on 28 October at 07:39:47 (0.098257 ETH) and deployed a 1,256-byte contract on 29 October at 02:28:59 1. Between 13:51:35 and 16:25:59 it sent type-4 transactions delegating three fresh accounts, each carrying 2 or 3 authorizations in descending nonce order, and made sweep calls that moved a few USDT and USDC 1. We read these as a rehearsal. TRM Labs, a tracing vendor, also reports one 7. Oligamy published the descending order before we measured it 114.

Binance's wording. Binance writes that the attackers "submitted 50 signing transactions"2. We take that to mean the 50 authorizations, because the chain shows one transaction carrying them 1. Binance does not say so. The chain does not record when the 50 were signed.

A signature being valid and a signature taking effect are separate facts, and the second depends on whether the nonce the signer wrote down matches the account's nonce at the moment of execution, not on when the signature was made.

Once installed, the delegation stayed until someone removed it, and the usual emergency control was not built to remove it.

The revocation, the transaction that cleared the delegation, 0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209, was mined at 00:10:35 on 30 October, 3 hours 49 minutes 36 seconds after the delegation 15. It is a type-4 transaction from Binance 14 to itself, carrying one authorization that names the all-zeros address. Afterward the wallet's code is empty 15. Binance's account matches it and gives the time as 00:10 UTC 2.

Binance says that "suspending withdrawals alone could not stop all unauthorized asset movements. The malicious EIP-7702 authorizations existed on-chain and operated independently of Binance's normal withdrawal infrastructure" 2. Elliptic, a tracing vendor, also writes that the delegation "remained in place, so no new signatures were needed". Its page, last updated on 1 November, also reports that Binance "paused withdrawals, which it says stopped the outflows" 12.

Binance says its wallet used multi-party computation (MPC), an arrangement in which the private key, the secret number that controls an account, is split into shares held by separate machines, so that no single machine can sign alone. Binance writes that, because of MPC, "there was no single private key that could be used to immediately revoke the malicious EIP-7702 authorizations", and that its team "developed and executed a specialized procedure" 2. The report as we hold it gives no time for the suspension, so we do not say which of the attacker's calls came after it 2.

While the delegation stood, Binance 14 itself sent exactly 93 transactions, nonces 18,914,810 to 18,914,902. Three failed, and no other authorization signed by Binance 14 appears in the window 1. It sent 6 to 21 transactions per minute from 19:58 to 20:20, then 1 to 5 per minute from 20:21 until that run ended at 20:33:59 1. After that came seven single transactions, then 46 calls between 22:55:35 and 23:07:59, each moving a different token by that token's standard transfer function, then one transaction at 00:07:11, then the revocation 1. It looks as if routine withdrawals ended at about 20:33:59, 9 minutes 36 seconds after the first sweep. But that is one wallet's traffic on the chain, not Binance's internal suspension time. Who directed the 46 transfers is not established.

Data: Hawthorne's on-chain measurements 1: the transactions Binance 14 sent, counted per minute over 262 minutes from 19:58 to 00:19 UTC, as measured 12 November 2026.

The attacker's account sent 13 transactions to Binance 14, from the delegation to a last call at 23:56:47, 13 minutes 48 seconds before the revocation 1. The token issuers acted before that last call, which moved only ETH. A blacklist is a token issuer's freeze: the issuer's token contract refuses to move its tokens from a listed address. Tether blacklisted Binance 14 at 22:06:23. Circle blacklisted Binance 14 at 23:53:35 and Hot Wallet 34 at 23:54:59 1.

Data: the rows above restate figures given in this essay, from Hawthorne's on-chain measurements 1 of the delegation, the sweeps and the revocation, as measured 12 November 2026.

The leftover signatures. Clearing a delegation and keeping it cleared are two different jobs. When the delegation took effect, Binance 14's nonce became 18,914,810, and 15 of the unused authorizations named nonces the wallet had not yet reached: 18,914,810 to 18,914,824 1. Under EIP-7702 a skipped authorization is not marked as used, so each of those stayed valid until the wallet's nonce passed it 6. That last point is our inference from the specification's nonce rule, which does not state it in so many words.

This is the hardest stretch of Part One, so here is the short version first. For roughly the first three minutes after the delegation, a revocation could have been reversed with one of the unused signatures, depending on how it was sent. After that, the wallet's own ordinary transactions had used up every nonce the signatures named, and none of them could match again. (If that is all you carry out of this section, it's enough.) The long version follows.

Could a leftover have undone a revocation? That depends on how the revocation was sent. A revocation is itself a type-4 transaction carrying an authorization that names the all-zeros address. The specification raises the sender's nonce before it processes any authorization, and raises the signer's nonce again for each authorization that takes effect 6. So a revocation that Binance 14 sends itself, as Binance did at 00:10:35, uses two of the wallet's nonces. One sent by another account uses one 16. A leftover could reinstall the delegation only if it named the wallet's nonce after the revocation. Our computation, a counterfactual and not an event: a self-sent revocation would have left a leftover in reach only if the revocation transaction used nonce 18,914,822 or lower; one sent by another account, only if the wallet's nonce was 18,914,823 or lower when it ran. Binance 14's routine transactions used 18,914,822 at 20:23:59 and 18,914,823 at 20:24:11 1. So depending on the method, for roughly the first three minutes after the delegation, clearing it could have been undone with one more transaction. Binance 14 used the last signed nonce, 18,914,824, at 20:24:23, in the same block as the first sweep 1. After that block, every one of the 50 named a nonce already in the past, and no revocation of either kind could have been undone this way. Our reading is that Binance's own withdrawal traffic retired the leftover signatures, and nothing else did.

The attacker used the delegation by calling Binance 14 directly. Each call ran the sweeper's code inside Binance 14's account.

The first sweep, 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3, mined at 20:24:23, 3 minutes 24 seconds after the delegation, moved 167,464.2479 ETH and made 63 token transfers, including 1,615,409,498.97 USDT 14. ETH is Ethereum's own currency. A token is an asset whose balances are kept inside a smart contract; a token transfer is a call to that contract. USDT, issued by Tether, and USDC, issued by Circle, are stablecoins: tokens designed to hold the value of one US dollar. Each is a separate asset from a separate company. Amounts here are rounded: ETH to four decimal places, USDT to two 14. Six later calls by the attacker's account also took assets 1:

Hot Wallet 34 was not the delegated account. So how was it drained? Binance 14 could already call a function on it, as it had for the 5 USDC, and the attacker's calls on Binance 14 used that reach 1. The first four bytes of a call's input name the function being called, much as a menu number names a dish without saying what is in it. That four-byte name is the function selector. These calls carried the selector 0x043ff9d21. Blockaid published the 20:41:23 drain, and TRM Labs listed sweeps at these times, before we measured them 137.

What we have not established. We measured what the sweeper did, not everything it could do. We have not read its code to learn who could call it, whether its destinations were fixed or chosen per call, or what else it could reach through Binance 14. Because delegated code has unrestricted access to the account, those limits, if any, sit in the sweeper alone 6.

After the first sweep, the attacker's calls took 5,160.1567 ETH and 204,315,411.59 USDT from Binance 14, and 823,000,000 USDC from Hot Wallet 34 1. All five sweeps of Binance 14 together took 172,624.4046 ETH, each leaving exactly 1 ETH behind 1. (The same remainder, each time. We have not read the sweeper's code, so we offer no reason.) No block in the window shows Binance 14 losing more than 50 ETH that these calls and its own sends do not explain 1. These totals cover those two wallets only.

For the whole theft, Binance says approximately USD 6.34 billion was "impacted" 2. TRM Labs estimates USD 6.36 billion across ten chains, and Elliptic's estimate goes to eleven, at USD 6.43 billion 712. With no price source, we have valued neither the measured units nor the other tokens, so we do not size the delegation's part of the loss or compute a share of those totals.

Three different quantities. How big was the failure? The tempting answer is to count what moved after the alarm, and that number answers a narrower question than it seems to. At least three quantities are in play. Realized loss is what actually left the wallets. Accessible exposure is what the attacker could have reached with the authority it held, given the sweeper's code and the controls in its way. Containment effectiveness is how much the response changed either of those. They are related, but they are not interchangeable. Put simply: what was taken, what could have been taken, and how much the response changed either. The record does not say when Binance's response took hold, so even the amount that moved after it cannot yet be computed. Assets also kept arriving after the first sweep, as the next section shows, so an amount counted from the alarm is not simply what was there at the alarm.

What moved after the alarm measures a realized consequence of the compromise. It does not, by itself, measure the authority the attacker acquired, or the losses that authority could have produced.

A consolidation job is an automated process that moves funds from many deposit addresses into a central wallet. One of them, as far as we can tell, kept feeding Binance 14 after the attacker controlled it.

Between the first sweep and the 21:04:23 sweep, Binance 14 received 1,700.8708 ETH and 3,917,719.27 USDT. Between then and the 21:44:11 sweep it received 369.8538 ETH and 200,397,771.82 USDT 1. Each later sweep took about what had arrived. The larger inflows came at 20:30:11, 21:00:11 and 21:30:11 1, which looks like a half-hourly consolidation job that kept running. (Looks like. We have not identified it.)

Data: Hawthorne's on-chain measurements 1: Binance 14's ETH balance at each of 1,301 blocks, and the five sweeps, as measured 12 November 2026.

The largest refill, 200,000,000 USDT, reached Binance 14 at 21:42:59. It stayed 72 seconds before the sweep took it 1. Its sender has sent Binance 14 76 transfers of exactly 200,000,000 USDT since 22 January 2026, and on 1 November it returned 800,000,000 USDT to its funder 1. The pattern reads as an automated reserve, a wallet that tops up a hot wallet when it runs low. We hold no label or Binance statement for this wallet, and who owns it is not measured.

The fee cap. Every Ethereum transaction pays a fee for the computing it uses, priced in gwei, a billionth of an ETH. Under the fee rules known as EIP-1559, the network sets a base fee each block that rises and falls with demand. A sender sets a fee cap, the most it will pay, and a transaction cannot be included in any block whose base fee is above its cap 16. The last nine of the reserve's transfers, the top-up included, carried a 50 gwei fee cap 1. The base fee was 0.17 gwei at the first sweep, 0.14 gwei at 20:34:23 and 0.67 gwei at 20:38:23, and crossed 2 gwei between 20:40:23 (1.92 gwei) and 20:40:35 (2.16 gwei), by Blockscout's block records read on 12 November 2026 15. It was above 50 gwei in every block from 20:47:59 to 21:42:35, peaking at 252.8 gwei, and first at or under 50 gwei at 21:42:47. The top-up was mined in the next block 1.

The fee cap establishes only that the top-up could not have been mined in that span 16. To broadcast a transaction is to send it to the network before it is included. Broadcast times are not recorded on the chain. Our reading, not established, is that the top-up was broadcast during the span, after the 20:47:47 block (45.87 gwei, the last under its cap) and so at least 23 minutes 24 seconds after the first sweep, and waited for the fee to fall 15. It may instead have been sent seconds before it was mined, or earlier and held back for another reason. The fee spike overlapped the theft, beginning ten to fourteen minutes after the first sweep 15. We have not measured the theft's share of the fees in those blocks, so we offer a link only as a hypothesis.

Data: Hawthorne's on-chain measurements 1: the base fee of each of 657 blocks, as measured 12 November 2026; the 2 gwei crossing is from Blockscout's block records 15.

The blacklists. Tether blacklisted the first receiving address, 0x5227f603…2f8c, at 21:01:35, 37 minutes 12 seconds after the first sweep, and Circle blacklisted it at 21:04:59 1. The USDT swept at 21:04:23 and 21:44:11, top-up included, reached that address after Tether's blacklist 1. Our reading is that the attacker could not move the top-up's USDT while the address stayed blacklisted, and that Binance still lost control of it.

The address received 1,819,724,910.56 USDT from Binance 14 in three sweeps. On 12 November 2026 it held 1,175,464,712.88 USDT and exactly 823,000,000 USDC 1. A wallet Blockaid labels Binance 16 also sent it 55,739,800.50 USDT at 20:24:47, a transfer Blockaid had reported, and dust transfers, tiny amounts, added under 2 USDT 11315. Before Tether's blacklist, two transfers took 700,000,000 USDT out: 500,000,000 at 20:30:11 and 200,000,000 at 20:33:23. Blockscout's index, read on 12 November 2026, lists the same two that we measured 115. The listed inflows less these two transfers come to 1,175,464,711.06 USDT (1,819,724,910.56 + 55,739,800.50 − 700,000,000), which is 1.82 USDT under the measured balance, a gap the dust transfers can cover. That is consistent with no balance having been destroyed, but it is not a reconciliation to the smallest unit, and we report no check of the event Tether's contract emits when it destroys a blacklisted balance. Where the 700,000,000 USDT went is traced in Part Two.

The last transfer. The last refill was one deposit of 2,961.9909 ETH at 23:55:47, and the attacker's call took 2,961.9108 ETH 60 seconds later 1. ChainWard published that pair first8. Binance's report says the final 2,961.9 ETH transfer "had previously been broadcast and remained pending" 2. The first five of the attacker's six calls from 23:36:47 to 23:56:47 moved nothing. The sixth, with the same 132-byte input, took the ETH 1. Their fee caps fell from 21.9 to 8.8 gwei, each about twice its own block's base fee, which fell from 11.14 to 3.97 gwei 1. Our reading, not established, is that each call was priced shortly before it was mined. Fee caps do not date a broadcast. Binance does not say how long the transfer was pending, so the chain neither confirms nor contradicts its sentence.

A compromised wallet that automation keeps refilling can go on being emptied for as long as the authority over it stands, unless another control, such as a token issuer's freeze, blocks the transfer.

Where does the record invite a stronger conclusion than it supports? Four places.

• A block time is not a broadcast time. Both of our fee readings rest on that gap, and neither is proved.
• One wallet's traffic is not a company's decision. Binance 14's routine traffic thinning at 20:33:59 does not date the suspension 1.
• Token units are not dollars, and frozen is not returned. The USDC and USDT measured on 12 November sit in the attacker's receiving address 1. Binance reports approximately USD 2.85 billion "frozen or intercepted" and, separately, says "As of 31 October 2026, 98% of the impacted token assets have been replenished". The report as we hold it gives no method for the percentage and no absolute amount 2. Both are self-reported, and we do not add them.
• What the sweeper did is not all it could do. We have not read its code 6.

Our recommendations are afterwit, the wisdom that arrives after it was needed, and none has been tested:

• Policy on the signing path. Treat delegation authorizations as their own class of signature. Approve or refuse each one by the contract it names, its chain and its nonce, before the signature exists, whoever later submits the transaction.
• Watch the authorization lists, not only the result. Alerting when one of your accounts gains code is necessary but late: one transaction can install a delegation and use it. Where you can see transactions before they are mined, inspect type-4 authorization lists that name your accounts.
• Rehearse revocation, including the leftovers. A revocation playbook should ask whether any signed authorizations for future nonces are still outstanding, and should be tested with the real custody setup, MPC approvals included. Binance says its team "developed and executed a specialized procedure" 2.
• Cut a compromised wallet out of every refill path. Consolidation jobs and reserve top-ups should stop for a compromised destination, not only the ordinary withdrawal system. We have not established which system sent the 200,000,000 USDT top-up 1.

• What the delegation allowed. A disassembly of the sweeper's code and a trace of its calls. We have done neither.
• When the 50 authorizations were signed, and by what request. Binance's signing-service logs. The chain cannot answer.
• When withdrawals were suspended. A timestamped Binance statement.
• Whether the top-up and the last call were sent when their fee caps suggest. The senders' own submission logs. Records of when a transaction was first seen waiting to be mined could disprove our readings by showing an earlier send, but not confirm them, since a transaction can be submitted privately.
• Who owns the 200,000,000 USDT sender, what sent the half-hourly inflows, and who directed the 46 token transfers. Binance's ownership, scheduling and authorization records.
• What the measured units were worth. A stated price source applied to each transfer. We applied none.

Each claim names the result that would disprove it. Claims not marked as readings are measurements.

• FC1. The delegation transaction carries 50 authorizations for nonces 18,914,775 to 18,914,824, in descending order, all recovering to Binance 14. Exactly one, 18,914,809, took effect 1. Disproof: a decode from any full node shows another count, range, order or signer, or Binance 14's nonce at the end of block 26,300,753 is not 18,914,810.
• FC2. Binance 14 sent exactly 93 transactions between delegation and revocation 1. Disproof: any nonce from 18,914,810 to 18,914,902 was consumed by an authorization, not a transaction.
• FC3. After the first sweep, attacker calls moved 5,160.1567 ETH and 204,315,411.59 USDT from Binance 14 and 823,000,000 USDC from Hot Wallet 34 1. Disproof: a ledger rebuilt from node data gives different totals.
• FC4. The USDT swept at 21:04:23 and 21:44:11 entered the receiving address after Tether blacklisted it at 21:01:35 1. Disproof: the blacklist event has a later block time than either sweep.
• FC5 (reading, not established). An untested hypothesis: the attacker's 23:56:47 call was first broadcast after the 23:55:47 deposit. The fee caps suggest only that the call was priced shortly before it was mined. Disproof: a record showing it broadcast before that deposit.
• FC6 (reading, not established). The 200,000,000 USDT top-up was first broadcast after the 20:47:47 block. Disproof: a record or Binance log showing it sent earlier.
• FC7 (computed counterfactual). Binance 14's transaction with nonce 18,914,824 was mined at 20:24:23, so from the end of that block no authorization in the delegation transaction could match the wallet's nonce 16. Disproof: a node shows nonce 18,914,824 used in a different block, or Binance 14's nonce at the end of the 20:24:23 block is not 18,914,825.

• What the delegation could do. We measured the sweeper's effects, not its code. The authority's actual limits are not established.
• One interested source for the intrusion. How the attacker reached the signing service rests on Binance's own initial report 2. Part Two examines it.
• Scope. We measured Binance 14, Hot Wallet 34, the attacker's sending account, and issuer blacklist events on Ethereum, and read the three rehearsal accounts and the 200,000,000 USDT sender's transfers to Binance 14 1. Sweep totals cover the first two wallets only. We measured no other chain.
• What a chain cannot show. Signing times, broadcast times, and who directed a transaction.
• One measurer. The measurements come from one set of scripts, cross-checked against a second data provider, not a second analyst 1. A second provider is not a second opinion, and may not even be a second, independent node. The evidence folder has no public address. A sample re-read from Blockscout's index during fact-checking (the delegation transaction, 18 blocks' base fees and the receiving address's USDT transfers) 15 agreed with our figures except on two points, both corrected. The rest has not been independently reproduced.
• Checking. Code confirmed 62 of the 73 excerpts behind the v6 fact-check rulings word for word against the pages. No automated check has covered every reference. This Part One text has not yet been fact-checked as a separate essay.
• Paraphrase. Our pseudocode paraphrases EIP-7702 and leaves out checks 6.
• Sources. The cited vendors sell related services. Chainalysis and Elliptic have revised their pages 1112.
• Held back. Points that met no admission test are absent by decision.
• Shelf life. Sources are read through 12 November 2026, and we have read no Binance statement after its 3 November report. A fuller Binance report would supersede parts of this essay, which is how it ought to go.

Every term below is also defined where it first appears.

• Address. The public identifier of an account on the chain, a string beginning 0x.
• Afterwit. The wisdom that arrives after it was needed. Our word for our recommendations.
• Authorization (EIP-7702). A signed message with three fields (chain id, contract address, nonce) that lets an account run a contract's code as its own while the nonce matches.
• Base fee. The network's going price per unit of computing, set every block according to demand.
• Blacklist. A token issuer's freeze. The token's contract refuses to move tokens from a listed address.
• Block; index. A block is a batch of transactions added to the chain together, about every 12 seconds. The index is a transaction's position within its block.
• Broadcast. Sending a transaction to the network before it is included in a block. Not recorded on the chain.
• Chain id. A number naming the blockchain a signature is for. 1 is Ethereum's main network.
• Computed counterfactual. A what-if worked out from the rules, not an observed event.
• Consolidation job. An automated process that moves funds from many addresses into a central wallet.
• Deploy. To publish a contract's code to the chain, where it gets an address of its own.
• Delegation. Under EIP-7702, an account pointing at a smart contract and running that contract's code as its own.
• Dust. Tiny token amounts sent to an address.
• EIP-7702; EIP-1559. Ethereum Improvement Proposals. 7702 adds delegation. 1559 sets the fee rules.
• Explorer. A website that indexes the chain for searching, such as Etherscan or Blockscout.
• ETH. Ethereum's own currency.
• Fee cap. The most a sender will pay per unit of computing. A transaction cannot be included while the base fee is above it.
• Full node. A node that keeps and checks the whole chain itself.
• Function selector. The first four bytes of a call's input, naming the function called.
• Gwei. A billionth of an ETH, the usual unit for fees.
• Hash. A fixed-length fingerprint of data. A transaction's hash is its ID.
• Hot wallet. An exchange account kept online so it can pay customers quickly.
• Mined. Included in a block.
• Multi-party computation (MPC). A way of splitting a private key into shares held by separate machines so that no one machine can sign alone.
• Node; JSON-RPC; data provider. A node is a computer running Ethereum's software with a copy of the chain. JSON-RPC is the standard way to ask it questions. A data provider answers JSON-RPC requests through an endpoint that may front several nodes.
• Nonce. An account's counter, which goes up by one each time it acts.
• Private key. The secret number that controls an account.
• Signature; recovering the signer. Cryptographic proof that a key holder approved a message. Recovering is computing which account signed.
• Smart contract. A program stored on the chain that runs when called.
• Stablecoin. A token designed to hold the value of one US dollar. USDT is Tether's and USDC is Circle's.
• Sweeper. A contract built to move everything out of an account.
• Token. An asset whose balances are kept inside a smart contract.
• Type-4 transaction. The Ethereum transaction format that carries EIP-7702 authorizations.

"Measured" means read or computed by us from node data on 12 November 2026. It is our own provenance label, and apart from the Blockscout sample described under Limits, no second party has reproduced the values. "Stated" means the named party says it and we have not verified it. "Our reading" is editorial.