Two weeks after the Binance drain: where the $6.3 billion is now (all chains)

1. What happened (timeline, UTC)

2. How the intrusion happened (according to Binance's report)

This section covers things that cannot be checked from on-chain records. It is based on the preliminary report Binance published on 3 November^[1]. The report is provisional: the investigation is ongoing, and its conclusions are to be verified by outside experts.

According to the report, the preparation took months.

1. June — a tampered installer. While setting up development tools, Engineer A downloaded a tampered installer for Homebrew (a tool for installing software on macOS). Binance noticed something was wrong, replaced the machine and rotated the credentials, but by then the attacker is said to have obtained information about the team members responsible for the wallet infrastructure.
2. September — a fake job interview. Engineer B went through several interviews with a person who had made contact through a job site, and ran a set of code handed over as an "assignment" on a work machine. It contained malware (a malicious program).
3. 20 October — moving sideways inside the company. Using B's machine and an internal AI tool as a foothold, the attacker gained control of A's and C's machines and found a token with permission to deploy containers (packages that programs run in).
4. 29 October — into the signing service. After preparations from 17:15 to 19:56 UTC, the attacker deployed a container using credentials stolen from A. It ran a malicious script that made the internal wallet signing service sign transactions without going through the normal withdrawal process.

On the keys themselves, Binance said in a statement on 31 October that "at this stage, we have found no evidence that any wallet private keys were compromised"^[2]. The hot wallets were managed with MPC (a method in which no single private key exists, and transactions are signed with pieces held by several parties). The report explains that, because of this, the permission given to the attacker through EIP-7702 could not be revoked straight away: even with normal withdrawals stopped, the delegation written on-chain was still live on its own. The delegation was removed at 00:10 UTC on 30 October, about four hours after the first outflow.

What ChainAnalyzer can check on-chain is the outcome. We have confirmed from Ethereum's records that the delegation of Binance 14 was made in a single transaction carrying 50 authorizations, that the sweep was executed three minutes later, and that the delegation has since been removed.

Binance says it is covering the full loss itself, and that as of 31 October it had replenished 98% of the affected assets^[1]. On attribution, the report names North Korea (DPRK), citing information from the FBI.

3. Where the funds are now (by asset)

These are the same figures as in "Where the funds are now" on the incident page. "Moved downstream" is the part that has left the attacker's addresses but has not yet reached an exit (a swap service or an exchange); it includes third-party addresses.

閉じる / Close

Four things to keep in mind when reading this table.

• "Frozen: ≥$2.39 billion" for USD stablecoins is the incident page's automatic tally, and does not include RLUSD, USD1, funds that arrived after a freeze, and so on. Counting the balances of the frozen addresses directly, token by token, gives about $2.65 billion; the breakdown is in the table in the next section.
• "Held" for ETH includes the current balances of the addresses published by the FBI. Because it includes ETH obtained by selling stablecoins and other assets, it is larger than the amount of ETH stolen.
• "Sold on DEXs" means swapped into another asset on a DEX (a way to swap tokens without going through an exchange). The asset received in the swap is counted in that asset's row.
• "Unidentified services" are destinations we judged, from their number of transactions and number of senders, to be wallets of services such as exchangers or bridges, but whose names we have not identified. ChainAnalyzer stops tracing there, because beyond that point other users' funds are mixed in.

4. How those who could stop the funds responded

Three kinds of party can stop stolen funds: issuers (the companies that issue a token), the organisations that run a chain, and the apps the funds pass through. This time all three acted. For each, we cite the official announcement and add what ChainAnalyzer confirmed from on-chain records.

Freezes by issuers

Stablecoin issuers can freeze (block transfers from) addresses that received stolen funds. The on-chain freeze records are below. Times are measured from the sweep on Ethereum (20:24:23 UTC on 29 October); for TRON alone, from the outflow on TRON.

"Frozen amount remaining" is the total balance still sitting in the frozen attacker-side addresses. Together it comes to about $2.65 billion. As of 14 November, Tether has not carried out a single burn-and-reissue of frozen funds (the step that amounts to recovering them).

The word "freeze" covers very different outcomes from one issuer to the next.

• USDC and USD1 stayed in full. The freezes landed before the attacker could move the funds out of the receiving addresses. For USD1, the 27.82 million USD1 received is frozen as it was^[5].
• About 700 million USDT moved in the 37 minutes before the freeze. Most of it was swapped into ETH on DEXs. On the other hand, some was added after the freeze. The attacker's receiving address held about 971 million USDT at the time of the freeze, but about 204 million more USDT was sent in from Binance 14 afterwards. Because a frozen USDT address can still receive funds, what arrived later cannot be moved either.
• XSGD froze empty addresses. The six frozen addresses already had a balance of 0 just before the freeze. Rather than stopping funds, it was a precaution against the addresses being used again.
• On TRON, two addresses that had been frozen (about 135,000 USDT in total) were unfrozen on 13 November. Both are contract addresses. They are not included in the table above.
• More than half of the RLUSD got out first. The attacker sent the 88.54 million RLUSD it received on three more times, leaving it at an address three steps away. Ripple froze that address, and in the 19 minutes before the freeze 48 million RLUSD was sent out. The remaining 40.54 million RLUSD was frozen^[6]. Media reports gave two figures for the frozen amount, about $200 million and 40.5 million; the one that can be confirmed on-chain is the latter.

Assets with no issuer, such as ETH and BTC, cannot be frozen by anyone. Note too that a freeze does not mean the funds were "recovered". Frozen funds simply sit at the attacker's address, unable to move.

The drained wallet was frozen too. Issuers froze not only the attacker's addresses but also Binance 14, the wallet the funds came from. The attacker could still operate this wallet, so this is likely a measure to keep the remaining funds from being taken out.

The delegation of Binance 14 was removed at 00:10 on 30 October. Every issuer freeze came before that.

Arbitrum — moving funds without the keys

On Arbitrum (a separate chain built on top of Ethereum), the Security Council, which handles emergency operations (a council that acts when 9 of its 12 members sign), forcibly moved the ETH and ARB held at the attacker's address to a holding address. The attacker's keys were not used. ChainAnalyzer checked what Arbitrum's notice^[3] says against transactions on both the Ethereum side and the Arbitrum side.

1. 29 October, 21:36–21:38 UTC — the attacker moves first. It moved 74,559,805.2 ARB and, after a 1 ETH test transfer, 8,425 ETH from the address that first received them to another address.
2. 30 October, 00:08:35 — one transaction on the Ethereum side^[7]. It was executed by the multisig (a wallet that acts only when several people have signed) listed in Arbitrum's official documentation as the emergency Security Council. It needs 9 of 12 signatures, and this transaction carried exactly 9.
3. Inside that one transaction, three things happen in turn. (1) The contract that serves as the intake window into Arbitrum is swapped for a temporary version. (2) Using a function that exists only in that version, two transactions "sent by the attacker's address" are put into the intake without a signature. (3) The intake window is switched back to the original version. The swap and the restore were done for each of the two. Because the whole transaction is undone if it stops partway, there is no moment when the altered state remains.
4. 00:18:20 — the two transactions run on the Arbitrum side^[8]. All of the ARB and about 8,426 ETH moved to the holding address (0x…0DA0), about 10 minutes after the operation on the Ethereum side.
5. As of 14 November, the holding address still has 74,559,805.2 ARB and about 8,426 ETH.

The source code of the temporary version used in the swap is public. It adds just one function, which lets the caller set the sender freely; the original version has no such function. The intake window is now back on the original version.

Moving the held funds requires a vote of the ArbitrumDAO.

While this response stopped the stolen funds, it also showed in practice that "if nine people agree, funds can be moved from anyone's address". Arbitrum took the same step in a different incident in April 2026.

Aave — borrowing against deposit receipts, later liquidated

Aave (a lending service where you deposit crypto assets and borrow other assets against them) was used by the attacker as an exit. The report by LlamaRisk, which handles Aave's risk management^[4], matches the on-chain records.

1. 29 October, 20:57:59 and 21:00:11 UTC — the attacker's address deposits a total of 60 million USDT on Aave.
2. 20:59:11 and 21:00:59 — against that, it borrows a total of 19,762 WETH (a token that can be exchanged 1:1 for ETH), converts it back to ETH and receives it.
3. 21:02 — it sends 23,314.5 ETH, including the borrowed ETH, to another address.
4. Right after that, Tether freezes this address.

The deposited USDT had turned into a "deposit receipt" token, which Tether's freeze does not reach. Of the 60 million USDT that would otherwise have been frozen, the attacker was able to take out about $44.6 million worth (at the time) as ETH, which cannot be frozen. It is the same loophole used on TRON.

From 21:42, Aave paused new deposits and borrowing in 292 markets (withdrawals, repayments and liquidations were not paused). It reopened them step by step from the next day.

Later, as the price of the borrowed ETH rose, the collateral margin ran out, and part of the position was liquidated at 14:49:23 UTC on 4 November. In a liquidation, a third party (the liquidator) repays the debt of a borrower whose collateral is no longer enough, and receives collateral at a discount in return. The liquidator repaid 9,884 WETH and received 24,378,310 USDT^[9].

As of 14 November, the attacker's position still has about 35.61 million USDT of collateral and about 9,890 WETH of debt. The collateral exceeds the debt, and Aave's lenders have not lost money.

5. The method on each chain

Ethereum — one sweep transaction

Three minutes before the drain, Binance 14 had been delegated to the attacker's contract through EIP-7702, with 50 authorizations. The attacker called the delegated program and had it send ETH and 64 kinds of tokens together in a single transaction.

→ The Ethereum leg of the Binance drain

TRON — "deposit receipts" that dodge freezes

On TRON, 612,729,468 USDT left, and the receiving address was frozen 46 min 27 s later. Five minutes after that, the attacker made a test deposit into a lending service (where you deposit crypto assets to earn interest). The "deposit receipt" token you get for a deposit cannot be frozen, so by moving it to a new wallet and withdrawing from there, the attacker can stay one step ahead of the freeze list.

→ The TRON leg of the Binance drain

Solana — small swaps and CCTP

On Solana, after swaps every few minutes and spreading across, then regathering from, dozens of wallets, at least 31.66 million USDC was moved to other chains through Circle CCTP (the official way to move USDC between chains).

→ The Solana leg of the Binance drain

XRP — from more than 100 relay accounts into THORChain

The roughly 233.46 million XRP was split across six accounts, gathered into one account, and handed out from there to 286 relay accounts. The relay accounts send XRP to THORChain and mostly receive Bitcoin. THORChain refunds orders it cannot fill, so the same XRP was sent again and again. Net of refunds, about 206.6 million XRP went through.

→ The XRP leg of the Binance drain

NEAR — handing funds on by buying and selling brand-new meme coins

Most of the NEAR has not moved, but part of it was moved in an unusual way. An account holding stolen funds buys one of six meme coins that had just been created. Another account, which had received the token free from its issuer, sells it straight away. There is no direct transfer between buyer and seller, yet NEAR moves from one to the other. About 140,000 NEAR moved this way; further on, about 310,000 USDC went to Ethereum and became Bitcoin through Chainflip (a cross-chain swap service, like THORChain).

→ The NEAR leg of the Binance drain

6. Where the exits were

These are the services used to turn the stolen funds into "assets that cannot be frozen" or move them to "another chain", in order of amount.

We recorded 13 deposits to named centralised exchanges, but every one is either small or many steps away from the attacker. They often pass through a service's wallet on the way, so we cannot say that the stolen funds themselves went in.

Where is the Bitcoin that came out of THORChain?

In a THORChain swap, the sender writes into the instruction "which address should receive the Bitcoin". ChainAnalyzer reads these instructions and has recorded 145 Bitcoin addresses that the attacker named to receive funds (98 from swaps out of XRP, 31 from TRON, 12 from Ethereum, 3 from Avalanche and 1 from Base).

These 145 addresses are pass-throughs, and no Bitcoin stays in them. Their combined balance is about 23 BTC.

One step further on, there is a place where funds have stopped: 400 addresses that each received a single deposit and have never spent it, holding about 1,317 BTC between them. The deposits arrived between 3 and 9 November, and in four checks, on 10, 11, 12 and 14 November, not one of them had moved. 364 of the 400 hold 1 BTC or more.

These figures cover only what we have confirmed. We have traced only some of the transfers out of the pass-through addresses, and much of what was swapped after 9 November is not yet in this count.

7. Funds that have not moved yet

For tracing purposes, these are the three large blocks that could move from here.

• About 18,276 BTC — unspent, at addresses it was split into on 29 October.
• About 551,600 ETH — at the Ethereum addresses published by the FBI.
• About 11.62 million NEAR — in the single account that first received it.

ChainAnalyzer checks these balances on every cycle, and any movement will show up on the incident page.

8. Using this in deposit screening

• Incident page: Binance hot wallet drain (2026) — the list of attacker addresses, where the funds are now, the flow diagram and the network diagram.
• Address lookup: paste an address into "Is this address involved?" on the page, and it tells you how many steps it is from the stolen funds. The same lookup is available through the API.
• Issuer freeze records are imported every six hours and reflected in scan results.

9. About the figures in this article

• All figures are lower bounds counted from on-chain records. Only the total loss (about $6.34 billion) and the total frozen and recovered (about $2.85 billion) come from Binance's announcements.
• Crypto assets are given as quantities, not converted to dollars, because converting would make the figures change with daily price moves.
• ChainAnalyzer has not made its own judgement on who the attacker is. Attribution follows the FBI's announcement.
• Tracing continues. For the latest figures, see the incident page.

Sources and on-chain records

Announcements and reports (sources for things ChainAnalyzer cannot check independently)

1. Binance, "Binance Security Incident on October 30, 2026: Update on Preliminary Investigation Findings and Response" (3 November 2026; the date in the title is in UTC+8). https://www.binance.com/square/post/384314395829022
2. Binance, "Security Incident Update Announcement #2" (31 October 2026). The original wording is "At this stage, we have found no evidence that any wallet private keys were compromised." https://www.binance.com/en/square/post/382974122328634
3. Arbitrum, "Security Council Emergency Action 30/10/2026" (Arbitrum Foundation forum). https://forum.arbitrum.foundation/t/security-council-emergency-action-30-10-2026/31625
4. LlamaRisk, "Binance Hot Wallet Exploit: Aave's Response" (Aave governance forum, 30 October 2026). https://governance.aave.com/t/binance-hot-wallet-exploit-aaves-response/25954

On-chain records (transactions anyone can check)

5. USD1 freeze (Ethereum, 2026-10-29 22:10:35 UTC): 0x171ad4552ef6e3958bd62febeb0b3ac7567577dfda909a505b6a1a5b9edf9dbc
6. RLUSD freeze (Ethereum, 2026-10-29 22:00:59 UTC, target 0xE7024aB8…958d): 0xafd52fb222019aa5eefd5a8331e7a1197484863184b589cc458fc0c8442c8c0f
7. Operation on the Ethereum side (2026-10-30 00:08:35 UTC): 0xb69c81774f507d46ce776aeaed8b4d31df96dd66ce6fd05073481011835355d6. Executing multisig 0xF06E95eF589D9c38af242a8AAee8375f14023F85 (signature threshold 9, 12 signers). Intake window (Delayed Inbox) 0x4Dbd4fc535Ac27206064B68FfCf827b0A60BAB3f, temporary version 0x980d1f93fc5809c828539c46084801673fa6a859, original version 0x7c058ad1d0ee415f7e7f30e62db1bcf568470a10
8. Transfers on Arbitrum One (2026-10-30 00:18:20 UTC): ARB 0x75e81a231a86e26a61e22dd2e6521504873a71a7ac1b2143c06e52796ceeedb6, ETH 0x410af166c81f9c0f26cc19b4d970c984f526225eeea2aea169179856fd615f70
9. Aave v3 liquidation (Ethereum, 2026-11-04 14:49:23 UTC): 0xf5ff0c7106886a61fddb7a03ab7da7b3ae50cd4ba62e1f418b7a07f98434a3eb. Deposits 0x420e7401…14eb, 0x65bd82f1…c3f6; borrows 0x01b3406c…d870, 0xa85ad480…9d5f