2,961 ETH warning: what Binance 14 delegation could mean for arriving funds

What the 2,961 ETH warning actually says

PANews attributes three observations to Shen Yu. The wallet labeled Binance 14 had reportedly retained its EIP-7702 delegation for more than two hours. A transfer of about 2,961 ETH to that address had remained pending because of low gas. If the transfer was included on-chain and the base fee fell below 4.4 gwei, an attacker might be able to move the arriving ETH again.

Those conditions belong together. The report does not establish that the ETH had arrived, that a second sweep had occurred, or that the delegation remained unchanged when a reader opened this article. It also does not identify the pending amount as a new deposit made by ordinary customers. Describing all 2,961 ETH as already stolen would go beyond the opened report. PANews sets out the conditional warning.

The report's value is the narrower question it raises: what happens to funds that arrive after a wallet has already experienced a suspected unauthorized transfer? If the same execution permission remains available, a later arrival needs a separate check. The earlier movement of a balance cannot, by itself, establish that the receiving address is ready to use again. This is our reading of the warning alongside the protocol's persistent-delegation design.

A public wallet label also needs care. Binance 14 is the label used in the report; it does not identify a particular customer's account balance. An exchange user's transfer history and an address-level chain record answer different questions. Start with the transaction you actually submitted and preserve its identifier, network and recorded status before interpreting a headline about a shared hot wallet.

Why delegation can outlast the first transfer

Ethereum's EIP-7702 specification allows an externally owned account to set a delegation indicator pointing to code at another address. When relevant execution operations reach the delegated account, they load and execute the code indicated by that pointer. The specification deliberately uses persistent delegation. The permission is not described as automatically disappearing at the end of one transfer. The EIP explains how delegation works.

That design helps explain why the warning concerns incoming ETH as well as funds already moved. The specification says an account balance can decrease through a call to a delegated account. In its security discussion, it also says poorly implemented delegate code can give a malicious actor near-complete control over the signer's account. These are properties and risks described by the standard; they do not independently prove how the suspected Binance incident happened.

The EIP includes a way to clear an account's code by using a valid authorization whose address field is the zero address. That is a protocol description, not a request for Binance users to sign a transaction from a website promising to repair an exchange wallet. An ordinary account holder cannot infer authority over an exchange's hot wallet from having a balance on the exchange.

There is another detail relevant to incident analysis. Under the specification, delegation processing occurs before the transaction's execution portion, and processed delegation indicators are not rolled back simply because that execution fails. A failed execution therefore needs to be interpreted with its authorization changes in view. A single failure label is insufficient evidence that every effect associated with the transaction was reversed.

These points make authorization state a useful subject for an incident follow-up. They still leave the original cause open. The existence of EIP-7702, or a technical path by which delegated code could move assets, does not show who obtained a signature or how it was obtained. That requires incident-specific evidence.

The method remains a reported hypothesis

An Odaily report published at 05:44 SGT on October 30 attributed to Bitcoin News an analysis suggesting EIP-7702 authorization had been used in the Binance-linked transfers. It described a suspected malicious-code route and said the way the authorization was obtained remained unclear. The same report said Binance was investigating and had said user funds were safe. Those are attributed statements in that report. Read Odaily's account.

We retain “suspected” for the incident and treat the proposed EIP-7702 route as an analysts' hypothesis. The cited reports do not supply a Binance technical postmortem confirming that route. It also does not give a fresh on-chain observation proving whether Binance 14's delegation has since been cleared. Shen Yu's warning and the protocol specification answer different parts of the story: one reports a wallet-specific concern, while the other explains why persistent delegation can matter.

The threshold of 4.4 gwei deserves the same restraint. It belongs to the conditions stated in the PANews report. It is not a general Ethereum safety threshold, a promise about when a transfer will confirm, or a level at which every wallet becomes exposed. Applying it to an unrelated transaction would require that transaction's own fee and execution details.

For a reader following several updates, the useful comparison is between timestamps, transaction states and new official statements. A later headline repeating the same pending amount does not establish a fresh transfer. A report that actually documents inclusion, a new authorization state or a confirmed subsequent movement would change the evidence more directly.

Market pressure is measurable, but does not confirm a wallet sweep

Our liquidations page, updated at 12:37 SGT on October 30, showed about $770 million in observed liquidations over the preceding 24 hours across Binance and OKX. The page split that total into about $649 million of long liquidations and $121 million of short liquidations. Its four-hour window showed about $83.7 million, while its one-hour window showed about $11.1 million. See the liquidations board.

Those windows describe different periods and overlap. Adding them together would count some orders more than once. The scope is the Binance and OKX observations on that page, rather than an all-exchange liquidation total. The figures measure forced position closures; they do not measure assets removed from a hot wallet.

The one-hour breakdown was about $1.44 million in longs and $9.71 million in shorts. That differs from the long-heavy 24-hour split and is a reason to inspect the window before repeating a directional market claim. It does not show that traders had established whether the wallet permission was fixed, nor does it identify the cause of each liquidation.

At the same 12:37 SGT observation, our funding board showed ETH at +0.0012% per period on Binance and −0.0088% on OKX. Positive funding means longs pay shorts; negative funding means shorts pay longs. The different signs describe the two contracts' funding conditions in that snapshot. See the funding-rate board.

We use these observations to separate two reader tasks. A transfer check concerns the destination, transaction status and custody of funds. A leveraged-position check concerns margin and the contract's funding conditions. A negative funding print cannot confirm a new theft, and a wallet warning cannot tell a trader their own liquidation price. Read each record for the question it can answer.

Check your transaction before responding to a recovery message

If you already sent funds, open your existing transaction record and compare its network, destination and status with the details you intended. Keep the transaction identifier and the status shown by your account. Where the transfer is still pending, describe it as pending in any support request; do not treat a circulating screenshot as evidence that your own transaction has completed.

Use Binance's official application or a previously established official channel to check service information. A stranger's message offering “Binance compensation” is not evidence that a compensation process exists. Do not connect a wallet, sign an authorization or send funds in response to an unsolicited compensation link or direct message. This is a precaution for this incident, not a report that we verified a particular compensation campaign.

If you hold funds in a self-custody address, the EIP's warning about delegated code is relevant to what a signature can authorize. Read what the wallet asks you to approve. A page claiming to cancel an exchange's authorization by asking for your personal-wallet signature should not be treated as part of Binance's incident response. The exchange's address and your address are separate accounts.

The next evidence to look for is specific: a new record of the pending transfer's inclusion, a documented change to the relevant delegation, or an official statement addressing the wallet and withdrawals. The PANews warning supplies a reported exposure of about 2,961 ETH under stated conditions. It does not supply a confirmed second sweep or a current clean bill for that address.

Quick answers

Has another 2,961 ETH loss been confirmed?

The PANews report describes a pending transfer and a conditional risk. It does not confirm that another sweep occurred. A later confirmed transaction record would be needed to establish that change.

Does a failed transaction remove delegated authority?

The EIP says processed delegation indicators are not rolled back when the execution portion fails. Authorization state needs its own inspection rather than an assumption based on the execution result.

Does the liquidation total show the size of the outflow?

The liquidation board measures observed forced position closures on Binance and OKX. Its 24-hour total is a market-position measure, not a wallet-loss tally.