Binance-linked wallet incident: a delegated account, 1.615B USDT and the receiver’s branches

On 29 October 2026, a Binance-labelled Ethereum account was associated with a delegation transaction, followed by a large transfer of ETH and tokens to one receiver. A later transaction sent USDC from a different asset-holding account to that same receiver. The important question is how signing authority reached more than one pool of assets—and what the transaction records can actually prove.

This investigation follows that narrow Ethereum route: an operator calls a delegated account; assets converge at a receiver; the receiver splits USDT into two branches, and one branch makes a further transfer. A further USDT source also sends directly to the receiver with its own transaction sender, which is a separate signing path. The account labels describe explorer annotations. They do not independently establish custody, a person’s identity or the signing system that produced the authorization.

Scope and evidence

The selected transaction records below, excluding the explicitly attributed internal call path, are direct browser observations of Etherscan overview pages and receipt logs. SentinelTX adds a bounded trace and hypotheses; statements by Binance and an external analyst remain attributed statements. “Direct” here means the explorer record was read, not that a separate Ethereum node independently reproduced it.

USDT and USDC are dollar-linked tokens, while ETH is the network’s native asset. Token quantities are preserved separately. These quantities are movements in different assets, not a dollar-loss total. The 500M, 200M and 175M transfers below are later movements of USDT; adding them to the seed amount would count funds again. No balance is inferred by subtracting this selected list from an inflow.

The three findings that survive cross-checking

First, the explorer records a delegation before the sweep, but the evidence does not explain how its authorization signature was obtained. Second, the large USDC transfer starts from a different asset account, so the transaction caller and the asset sender must be kept separate. Third, USDT branches are directly visible, while a wBETH token-contract call is not proof of a custodial exchange deposit. The sections below explain each finding in time order.

Before the sweep: what changed at the account?

An Ethereum externally owned account normally authorizes actions with a signature. EIP-7702 allows such an account to delegate execution to code. That makes a signature about execution authority different from an ordinary payment: later calls can run the delegated code in the account’s context. This is the relevant mechanism described by the official EIP-7702 specification; it does not by itself establish this incident’s root cause.

At 20:20:59 UTC, the authorization transaction succeeded. The saved explorer table displays 50 authorization rows, of which one is marked True and 49 False. A nonce is an account sequence number used to prevent an authorization from being reused. The True row has nonce 18914809 and names the delegate in the appendix. These are explorer observations; signer recovery, chain-ID validation and historical account-code reconstruction have not been independently reproduced in this report.

The delegate’s current code page shows unverified runtime bytecode containing the operator address, and a creation link naming that operator. A matching byte sequence is not a complete control-flow audit or a historical proof. The analyst’s original thread describes an operator restriction and a rejection test, but those tests were not independently rerun. Key theft, signing-service misuse and a malicious authorization request remain alternative explanations, not findings.

Three minutes later: which assets actually moved?

At 20:24:23 UTC, the selected sweep transaction shows a successful outer call from the operator to the delegated account with zero ETH in the outer transaction’s value field. This does not mean no ETH moved: the explorer separately displays an internal transfer of 167,464.247856558836135296 ETH from that account to the receiver. The USDT receipt log records the same source and destination, with raw value 1615409498973240 and six token decimals.

The transaction overview counts 63 ERC-20 transfers. This report does not present an independently decoded 63-token inventory. A reverted child-call warning is also visible alongside outer success. SentinelTX reports a failed token-transfer frame inside a larger call tree; that supports checking individual subcalls rather than treating the entire sweep as reverted.

A different transaction sender appears 24 seconds later

At 20:24:47 UTC, another transaction sends 55,739,800.500000 USDT from a Binance 16-labelled address to the same receiver. The outer transaction’s From address is this asset sender itself, and its call target is canonical USDT. Receipt log 37 contains raw value 55739800500000. This is a direct token call, unlike the earlier operator calling the delegated account.

The shared receiver links the movement, but does not explain the signature. This record prevents an overly simple claim that every selected inflow came through one delegated-account execution path. It does not establish that a second key was stolen: an operational transfer, a misused signing service and other signing circumstances remain unresolved.

After receipt: the USDT split

The receiver sent 500,000,000 USDT at 20:30:11 UTC and 200,000,000 USDT at 20:33:23 UTC to two different addresses. Both canonical USDT Transfer logs were read directly. Following Branch A forward for one selected movement, it later sent 175,000,000 USDT to a third address at 20:59:11 UTC. This is one selected onward transfer within two transfers from the central receiver, not a complete account history.

Begin Figure 1 at the central receiver. The arrows show token transfers; the separate continuation from Branch A shows only the selected 175M movement. They do not show a sale, a freeze or an exchange deposit.

Figure 1. The 175M movement is part of the earlier 500M branch. It is not an additional incident inflow.

The split is consistent with dispersal, but round amounts do not prove a laundering intent or common control of recipients. Etherscan’s editorial Insight points to a third-party tracker describing later freezes and OTC activity. Those descriptions were not adopted as verified conclusions: a transfer alone cannot identify the consideration received, the counterparty or the legal status of funds.

Later, a separate USDC account reaches the same receiver

Returning to the other source account at 20:41:23 UTC, after the two initial USDT branches, the separate USDC transaction records 780,000,000 USDC reaching the same receiver, but from a different asset-holding address. Figure 2 selects the main delegated source and the separate USDC source for comparison; the direct-signed USDT movement described earlier is not drawn. Read from the two source cards toward the central receiver. Solid arrows represent the selected observed asset movements, not account ownership or signing permissions.

Figure 2. Two independently checked sources converge on one receiver. ETH is rounded in this figure; exact quantities, accounts and hashes are preserved in the evidence appendix.

The independent receipt confirms the USDC asset source and amount. A function selector is the first four bytes of a contract instruction; it is not a verified function name. The final SentinelTX response additionally returns a seven-frame execution path for this exact transaction. A CALL asks another account to execute; a DELEGATECALL runs implementation code while retaining the calling account’s context. That distinction explains why an implementation address is not another recipient of the 780M USDC.

The trace comes from SentinelTX and was not independently re-executed. Its source, destination and transfer quantity match the independently read USDC receipt; that corroborates the movement, not every execution frame. Function names for the two wallet selectors, owner/executor storage and historical privilege assignments remain unknown. It would be premature to call the delegated account the wallet’s owner, or to infer an allowance exploit from the transfer alone.

Why the wBETH leg is not an exchange-deposit finding

At 21:52:47 UTC, the wBETH transaction calls the wBETH token contract. Its receipt log transfers 29,934.013163146020067927 wBETH from the receiver to a separate recipient. The called contract and the asset recipient are different addresses. Treating the token contract’s Binance association as a deposit destination would misclassify the movement.

SentinelTX’s narrative corrects an earlier exchange-deposit classification; the independent receipt-log check supports that correction. No custodial exchange deposit has been established in the selected verified paths. That is a coverage-limited conclusion, not evidence that no such deposit occurred elsewhere. DEX interactions returned by the wider trace are also distinct from custodial deposits and do not establish fiat cash-out.

Frozen, recovered and returned are different states

In its statement published on 29 October at 23:22 UTC (30 October, 08:22 KST), Binance says its verified frozen total is USD2.54B and that an older USD1.8B figure is outdated. This is a historical company aggregate, not the latest total. It has not been reconstructed here from issuer event logs, asset quantities and a common valuation time.

In Security Incident Update #2, dated 30 October, read on 31 October, Binance reported approximately USD3B frozen on-chain. It also said it had identified additional breach points and had found no evidence at that stage that wallet private keys had leaked. These are company statements, not conclusions from this report’s selected Ethereum transactions. They neither establish how the observed authorizations were obtained nor turn a freeze into a verified return of assets.

A blacklist restriction can prevent movement of a token at an address. It does not itself prove that the assets were transferred to a recovery custodian or returned to users. The initial SentinelTX issuer-event queries failed. The final follow-up response lists prior-session blacklist events, but omits re-anchored transaction hashes and says current blacklist state was not read. It also reports only 15 of 55 Blacklisted-topic rows displayed. This incomplete list is retained as a lead, not a verified issuer inventory. Authorization signer recovery and USDC owner/executor privileges also remain unresolved. No zero-event or “not frozen” conclusion is drawn from a failed query.

Connections, alternatives and response points

The strongest links are the exact asset sender, recipient and Transfer log in each selected transaction. The same operator and called account provide additional execution context. Explorer tags, shared timing, similar amounts and token-contract branding provide weaker context and are not beneficial-ownership proofs.

These are evidence-preservation and verification priorities, not proof of a person’s responsibility. No issuer, exchange or law-enforcement message has been sent as part of this investigation.

Coverage and remaining uncertainty

The original SentinelTX trace reports 525 transactions and 52 addresses. Its live graph displays 71 nodes, which is a different representation and not a verified count of recipients. One displayed call tree contains 191 of 192 frames; 17 label queries and two address-history reads were incomplete. Only selected transactions were independently cross-checked for this report. A later continuation reports 23 incompletely read addresses; that belongs to the follow-up’s different coverage and is not merged with the initial graph counts.

The original report also contains different temporal boundaries: a query window from 29 September to 30 October 00:19:56.232761 UTC, a snapshot header through block 26301901, selected displayed routing rows through block 26301699, and a later token read at block 26301950. Those records are preserved separately. They cannot be presented as one exhaustive incident cutoff.

Bitcoin, TRON, full all-chain valuation, all 63 token transfers, complete receiver balances, onward ETH movements, final incident loss and user restitution are outside the independently verified scope. The observed 204-second interval between authorization and sweep is not the full attack duration. The evidence establishes a narrow sequence of authority-related activity and asset movements; it does not yet establish the signature’s origin or the final recovery outcome.

Evidence appendix: accounts

Evidence appendix: transaction anchors

Evidence appendix: exact token quantities