Binance Oct-29: 50 EIP-7702 tuples and a single delegation

In the Binance attack on Oct-29-2026, the 50 EIP-7702 authorizations traveling in the 20:20:59 UTC transaction on Ethereum all pointed to the same contract and the same chain, with consecutive nonces from 18,914,775 to 18,914,824. The actual nonce of the signing account in that block was 18,914,810: position 36 of the 50. Read field by field, the batch is the same delegation written fifty times, one for each sequence number the account could have upon processing. Above the actual nonce, 14 signatures remained, and at that account's pace over the previous 24 hours—9.12 nonces per minute—those 14 represent 1.54 minutes of coverage. The second measurement is the issuer freeze, event by event: the USDT contract blacklist checks who signs a transfer rather than who receives it, so the address that received the sweep added 204,315,411.59 USDT after being blacklisted, and as of Nov-3-2026, it continued to accumulate. The USDC contract does check the receiver, and the USDC balance of that same address remained unchanged. The two measurements are contrasted with the EIP-7702 census from Oct-21-2026, eight days prior to the attack.

What is an EIP-7702 authorization tuple?

An authorization tuple is the new unit of content carried by a type 4 transaction, the type introduced to Ethereum by EIP-7702 with the Pectra fork, active since May 2025. The tuple has four meaningful fields: chainId, the chain where it is valid; address, the contract whose code the account will execute; nonce, the sequence number the account must have when processed; and the signature, from which the node recovers the signer.

The specification calls the signer of the tuple the "authority," which is the account being delegated, while the sender of the transaction transporting it can be anyone else. In the Oct-29 batch, this separation is measured: it was sent by an address whose own nonce was 10, while the tuples had been signed by an account at nonce eighteen million nine hundred fourteen thousand eight hundred ten.

The tuple's nonce functions like a direct debit sequence number: the bank executes it if the number matches the next one in your ledger, and rejects it if it does not. The mapping is direct—the bank is the node, the ledger is the account state, the number is the nonce—and so is the limit: a tuple does not move funds. Upon successful processing, it writes a 23-byte pointer to the account's code starting with 0xef0100 followed by the delegated address, so that from that block onward, any call to the account executes that contract's code using its own balance and storage. The pointer and the count of how many accounts carry it are in our EIP-7702 census from Oct-22.

Why were the 50 tuples in the Binance batch a single EIP-7702 delegation?

Because the three things that distinguish one delegation from another match across all 50: the chain (chainId 0x1), the delegated contract (0x63e842b054bd624a465454d533c33f573e9c6fae), and the signing account. The only thing that changes between tuples is the fourth field, the nonce, and the 50 values form a gapless series.

The protocol can only accept one of the 50: the 35 below the actual nonce had already expired and the node discards them while charging the gas for verification; the 14 above requested a number the account had not yet reached; and the thirty-sixth wrote the pointer.

The batch size, therefore, measures something else. A series of 50 consecutive nonces covers a data point unknown at the time of signing: how many more transactions the account will have sent by the time the block arrives. If the first nonce in the range was the one the account had at the time of signing, it spent 35 nonces between signing and inclusion; the measurement provides the nonce at inclusion rather than at signing, so that reading reflects the batch design rather than a measured data point. The transaction gas—1,258,562 to write a 23-byte pointer—is the price of verifying 49 signatures that the node discards.

How many minutes of validity remained for the Binance 50-authorization batch?

The coverage of such a batch exhausts itself, and the account's pace quantifies it. Reading eth_getTransactionCount per block on an archive node, the signing account spent 9.12 nonces per minute in the preceding 24 hours, from 20:14:23 UTC on Oct-28 to 20:20:59 on Oct-29. At that pace, the entire series of 50 nonces is worth 5.49 minutes. What remained upon transaction inclusion are the 14 tuples above the actual nonce: 14 divided by 9.12 equals 1.54 minutes. The count that matters is the one for tuples not yet reached.

Put another way: had the batch taken roughly 92 seconds longer to enter a block, all 50 signatures would have expired, and the transaction would have written nothing in exchange for 1.2 million gas.

What happened in the Binance account since 20:20 UTC on Oct-29-2026?

With the pointer written, any call to the account address executes the delegated contract with its balances and permissions. The Oct-30-2026 measurement covers three calls and the first blacklist events.

The USDT in that batch totals 1,615,409,498.97324 units, read from the log with the contract's six decimals. The generic mechanism of a drain—how an account is made to sign something it did not intend to—is in our piece on wallet drainers, and is precisely the part not found on-chain.

Following the sweep, the account's pace dropped to 3.60 per minute, then 2.60, then 1.60; it hit zero between 20:35:59 and 20:40:59, remained there for about two hours and twenty minutes, and returned between 00:21:59 and 00:32:23 on Oct-30 with a peak of 31.35 per minute, 3.4 times its baseline. No corporate decision can be deduced from this, nor can any announcement be dated: the nonce measures whether an address signed, and at what times.

What does the USDT blacklist prevent for a blocked address?

In the window from block 26,300,693 to 26,302,100, there are 13 blacklist events: nine AddedBlackList events from the USDT contract on Ethereum and four Blacklisted events from the USDC contract. No destruction of funds (DestroyedBlackFunds) occurred in that window.

Three takeaways from the table. First: five of the nine USDT addresses had a zero balance in the block prior to their event, so counting addresses and counting piles of money are two different things. Second: the first listed address is exactly the destination of the 63 transfers, and the first event arrived 37.2 minutes after the sweep.

The third is the mechanism, which depends on the contract. In the USDT contract on Ethereum, the blacklist check falls on the transfer signer, meaning a blocked address can no longer send but can still receive. Measured at the sweep destination: 971,149,299.48324 USDT in the block prior to its event, 1,175,464,711.075362 at window close—204,315,411.59 units more while already blocked—and 1,175,464,712.876362 in a balanceOf re-reading on Nov-3-2026: 1.801 USDT more than at window close, five days later. This is not verified on Tron.

USDC does the opposite, as the table shows: the USDC balance of that same address is identical at both points. Its implementation also checks the receiver, so a transfer to a blocked address reverts with "Blacklistable: account is blacklisted" (proprietary transfer simulation from a non-listed address, Nov-3-2026). The two largest stablecoin issuers apply the same tool with different scopes, and the difference lies in the code. This nuance necessitated a correction to CleanSky's Tether self-custody wallet guide.

What this table does not reconcile: the sweep moved 1,615,409,498.97324 USDT units, yet the destination appears with 971,149,299.48 before its event. The measurement does not read its balance prior to the sweep nor what left afterward, so the difference is not attributed to any specific movement.

From this follows how to read any "frozen" figure in USDT: it marks a time rather than a total, because the balance of a blocked address rises as long as transfers continue to arrive. Loss figures that have circulated differ between media outlets, with different chains and different times behind each; Decrypt headlines with $6.4 billion while other publications handle smaller amounts. No figure is adopted here: this measurement covers 13 events across two contracts on a single chain. Furthermore, one should not confuse loss with freezing: the "roughly $2.8B" cited by Fireblocks is what issuers blocked, not what left.

The table also captures an effect of the pointer: the emptied account appears on both blacklists, in USDT at 22:06:23 for 1,351,530.01 units and in USDC at 23:53:35 for 52,363.12. The delegation pointer remained written in its code, so any USDT or USDC reaching it remained accessible by the delegated contract. The other issuer freeze measured at CleanSky, the Bitget hack, has a different focus: there, scope—which assets have a freeze button—and the issuer's clock were measured; here, zero balances and the pile that grows after blocking it.

Was a 50-tuple batch like the Binance attack rare on Ethereum?

The question of whether an alarm would have sounded requires a snapshot of the network prior to the attack, provided by the EIP-7702 census of Oct-21-2026, with two samples—a dense window of 2,000 consecutive blocks and a systematic sample of one in every thousand blocks since Pectra.

By size, the Oct-29 batch did not stand out. Between one-third and one-half of baseline authorizations traveled in batches of 20 or more, with a maximum of 650 tuples in a single transaction. The two samples share four transactions, totaling 14,230 distinct type 4 transactions; among those with 50 or more tuples, none overlap, so the 81 are 81 different transactions. An alarm triggered by "large batch" would have sounded every day in October.

By form, however, the batch is nearly unique in that snapshot, and that can be counted. Reviewing the 81 transactions of 50 or more tuples from the Oct-21 baseline (proprietary calculation from Nov-3-2026 on their authorization files): all 81 point to a single delegated contract, just like the incident batch, so that trait distinguishes nothing. What distinguishes it is the nonce. In 80 of the 81, there are repeated nonces within the same batch—up to 222 signatures with the same number, and 19 transactions where all carry the same value—as expected when a batch moves many different accounts, each with its own counter. Only one of the 81 repeats no nonce: the 650-tuple batch from block 26,172,584, with 650 strictly consecutive nonces from 123,500 to 124,149 and the zero address as destination: a revocation batch. That is the same form as the Oct-29 batch. Recovering the signing account would require one ecrecover per tuple, which this measurement does not perform, so the form is what is comparable.

The consequence is concrete for those designing surveillance: the trait that would have flagged this transaction is the combination of consecutive nonces without repetition and a single destination contract, rather than its number of tuples. With that filter, there is one precedent among the 81 baseline batches of 50 or more tuples; with the size filter, 81. Below 50 tuples, the form has not been reviewed, so the count applies to that segment and not the entire sample.

Why does CleanSky's EIP-7702 census show 51 large batches while this measurement shows 81?

Because they are not the same figure. The two series have different units, thresholds, and anchors, and placed side-by-side without their denominator, they would appear to contradict each other.

With the same unit and threshold, the two series nearly align: 24.99% of instructions in the Oct-14 census versus 20.01% in the Oct-21 baseline. The 0.101% appearing earlier in this piece is a different fraction—transactions with exactly 50 tuples over the dense window—which is why it sits so far apart: both unit and threshold change simultaneously.

What this case adds is a layer that an instruction count alone does not separate: nonce repetition within a single account. With consecutive nonces, the number of instructions and the number of affected accounts diverge by design, because from that series only one instruction can take effect: 50 instructions and, at most, one effective delegation. In the baseline, that form appears in one transaction out of 81.

What had been published regarding the Binance 50 EIP-7702 authorizations?

Of the three coverage pieces read for this measurement—techreport.com, Fireblocks, and Decrypt—the one that goes furthest is techreport.com, which writes that a transaction "carried fifty EIP-7702 authorizations signed by the Binance 14 hot wallet for consecutive nonces," attributing it to "an analysis shared in the security community" without naming the author and warning that it rests on a single researcher's reading and that Binance has not confirmed the detail. The reading of consecutive nonces was published, then. What does not appear in that text is the range, the position of the actual nonce, the delegated contract, or the account's pace. The Fireblocks note stops a step earlier: "One transaction carried 50 authorizations, so at least one would be valid when processed," without the range, position, delegated contract address, pace, or network baseline, and with a single mention of freezes—"roughly $2.8B was frozen by stablecoin issuers and others"—that does not delve into the mechanism.

In those three pieces, the nonce range, the 36-of-50 position, the 1.54 minutes of remaining coverage, the 13 blacklist events with their balances, and the form of batches in a pre-attack network snapshot do not appear. The general explanation from Decrypt does provide the highest loss figure circulating and attributes the attack to a state actor citing analysts; that attribution remains outside this piece due to the lack of a public, dated forensic source we can verify.

What is checked on Nov-6-2026 regarding the Binance batch?

Four thresholds, set after data collection. (a) If contract 0x63e842b0…6fae receives authorizations from other accounts after Oct-30, it ceases to be a single-use piece. (b) If in a new dense window, batches of 50 or more exceed 1% of type 4 transactions—currently 0.45% in the dense and 0.65% in the systematic—the pattern has become common and "did not stand out by size" changes meaning. (c) If the balance of listed addresses drops by more than 1% between window close and control, the freeze was incomplete; as of Nov-3, the main one has risen by 1.801 units. (d) If the emptied account's nonce does not recover its previous pace of 9.12 per minute before Nov-6, that address's silence remains open.

Four limits. The measurement is Ethereum-only, and according to cited coverage, the attack also touched Tron and Bitcoin: this is compatible with published amounts exceeding those measured here. The historical state comes from a single archive node, though the Nov-3 re-reading is independent in time. The form of batches below 50 tuples has not been reviewed. And how the account signature was obtained is not on-chain.

On Nov-6-2026, the four rows are read again with the same script and block height. The one most likely to move is (b): batches of 50 or more are already at 0.65% of type 4 transactions in the systematic sample, one-third of the way to the 1% that would make the pattern common.

Sources and links: EIP-7702, specification (authorization tuple structure) · USDT contract on Ethereum (blacklist function) · techreport.com: the fifty authorizations and consecutive nonces · Fireblocks: technical note on the incident · Decrypt: general explanation of EIP-7702 · Proprietary frozen extractions from Oct-30-2026 and Oct-21-2026, and balance re-reading from Nov-3-2026 with balanceOf.