Bitget said $351.6 million. We followed it across eight chains.

On 24 September 2026, at 18:31 UTC, Bitget's security systems flagged unauthorised transfers out of a limited number of hot wallets. Bitget puts the affected assets at about $351.6 million. It says it has flagged the transfer addresses. It has not published a list.

So we read the chains instead. Every figure below with a transaction hash next to it was read from a public node or explorer, one transfer at a time, across eight networks — including the XRP Ledger half, traced here address by address. Our total is $357.3 million.

Two days after we finished reading, on 27 September, every address in this article that was holding funds is empty — including the five XRP Ledger accounts that held 102 million XRP between them. That is below, with the times each was drained.

We are a blockchain forensics company and this is the kind of work we do, so a second question was unavoidable: does our own product get the same answer? At the end of this piece we run it against the same address and publish what it returns, including the parts where it answers a different question from the one we asked by hand.

What Bitget says

At 18:31 UTC Bitget's security systems identified unauthorized transfers from a limited number of hot wallets. Bitget puts the affected assets at about $351.6 million, says cold wallets are unaffected, that a user protection fund covers the loss, and that withdrawals are suspended. It says it has flagged the transfer addresses; it has not published a list. The CEO's notice describes a three-tier wallet architecture and says the incident touched a portion of the hot and warm layers.

In her later written summary the CEO says the affected assets include ETH, XRP ("the largest single chain loss"), BNB, AVAX, USDT and USDC, across Ethereum, the XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base; that some foundations have already frozen attacker addresses; and that IP patterns and on-chain signatures are consistent with techniques used by DPRK-linked groups. That last point is Bitget's assessment; we do not repeat it as ours.

The sources, all read on x.com:

• Bitget, 2026-09-24 21:34 UTC — x.com/bitget/status/2103236552482848927
• CEO Gracy Chen, 2026-09-24 21:30 UTC — x.com/GracyBitget/status/2103235655879074084
• @bitget, 2026-09-25 03:10 UTC — the protection fund holds 5,500 BTC; losses from this incident will be borne by the fund.
• @GracyBitget, 2026-09-25 05:43 UTC — a written summary of the CEO's live session, which names the affected chains and assets.
• @bitget, 2026-09-25 07:10 UTC — ["[UPDATES]"](https://x.com/bitget/status/2103381494056288658): Mandiant and SlowMist are investigating; withdrawals remain paused; Bitget Wallet runs on separate infrastructure and was not affected. No addresses, no amount, no vector.

No written post on either profile lists addresses. We have not reviewed the live audio session.

The shape of it: two bursts, five networks each

Twenty transfers, eight networks, two hours and fifty-two minutes. Thirteen of the twenty land inside two windows of a quarter of a minute each.

What we measured

Times are UTC on 2026-09-24. The first transfer we find into the address that later received most of the funds — 0x770b10b273fC44Fe9197D6bF20F145c2e98463Ee, which had no prior history on any chain — is at 18:31:11, the minute Bitget gives for detection.

Inflows to 0x770b10b273fC44Fe9197D6bF20F145c2e98463Ee

Senders carry a "Bitget" label in third-party address data — a label, not a confirmation from Bitget. USD = amount × the DefiLlama historical price at the transfer's block time (one method throughout; see Method).

Valued at prices at the cut instead, the total is $192.2M — the choice of method moves it by less than 0.2%. Only labelled Bitget senders and native or real-contract transfers are counted. Treat the total as a floor: ERC-20 inflows were checked on Ethereum, Arbitrum, Optimism, Base and Avalanche; on BSC only BNB was confirmed independently.

Inflows on the XRP Ledger

The two XRP Ledger accounts that XRPScan's public name list labels "Bitget Global" (rGDreBvnHrX1get7na3J4oowN19ny4GzFn, rwTTsHVUDF8Ub2nzV2oAeWxfJzUvobXLEf) sent XRP to one account, rwNhefsz1UQEusxhCvHip3RANinWi4CTck. Successful payments only; USD by the same method.

Onward: rwNhefsz… sent 20,000,000 XRP to each of rDRV9nLg8xbLsafKZnhNgWuE1TiSLE95hs (21:42:02), r3UGfDM4ZyFSCzKH7TQEjgago9QoUJagtJ (22:03:41), rH7oMFKBgdK99TPQctFVzddD7srRzyCqZn (22:04:42), rwSjBrtxBC75TqZ5YvJ1TGfaRpQvVNsAKw (22:06:01), and 22,976,677 XRP to r6NcwN3dR5ciyBv9XsLyMNc9Kg2FBCs7Y (23:43:41), leaving 3 XRP behind. At about 10:00 UTC on 25 September those five still held roughly 19.45M / 20M / 20M / 20M / 22.98M XRP. They do not any more — see "Where it stands on 27 September" below.

Inflows on Tron

TBWNguTT… was created on 24 September, and the 93 TRX at 18:31:00 is the first transaction it ever received — eleven seconds before the first Ethereum transfer to 0x770b…, and in the minute Bitget gives for detection. A very small transfer to a new address before a very large one is the same shape as the 0.84 ETH and 0.65 ETH transfers on Ethereum. We do not know who initiated any of them, or why.

At 10:04 UTC on 25 September the account held 4,369,190 TRX. From 08:25 UTC that morning it sent 16.2M TRX onward in 19 transfers of 214K–1.75M TRX to about fifteen addresses; we did not follow them. The largest repeat recipients are TDcu2CMpyLK4M5wmE5tstAZv9ZjK7xPHNX and TSqLrg8UNatjcoy2ZBWmf7jsSnxmV8m52N. That account is empty today; again, see below.

How the Tron leg was found, and why it matters. TJxe1M… carries no label on Tronscan. It appeared because we read the recipient's history — not because we started from a list of Bitget-labelled wallets. Every label-first scan of ours (26.8K EVM addresses, 11 tagged Tron addresses) had missed it. The XRP Ledger leg, by contrast, was found through a public name list. A trace that only follows names finds only what somebody has already named.

All parts together: $192.5M (EVM chains) + $157.8M (XRP Ledger) + $7.0M (Tron) = $357.3M, against Bitget's approximately $351.6 million — $5.7M, or 1.6%, above it. Three things could explain a difference of that size: the date at which the assets are valued, the perimeter of what Bitget counts as "affected", and assets returned or frozen. We claim none of them.

For scale, one independent primary datum: Lookonchain's post on x.com (2026-09-24 ~23:39 UTC) reports 67,982 ETH ($183M) in the EVM part of the flows, and its Arkham entity screenshot shows $188.9M across 22 EVM addresses. Our EVM inflows are 31,889 ETH direct plus the stablecoins and XAUT later sold for ETH ($192.5M in all); the ETH those flows became sits on about nine addresses. We did not use anyone's XRP or Tron figure — those are ours, read on their ledgers.

The two bursts, in words

At 19:01:20–19:01:35 — fifteen seconds — transfers landed on Arbitrum, Ethereum (three of them), Optimism, the XRP Ledger and Base. Five networks. Four different sending addresses: 0x1AB4…8F23, 0x5bdf…F7Ef, 0x97b9…8689 and the XRP Ledger account rGDre…GzFn.

At 19:16:14–19:16:23 — nine seconds — transfers landed on BSC, Avalanche, Tron, the XRP Ledger and Ethereum. Five networks again, and this time three of them came from one sending address: 0xffa8…cD54 sent BNB on BSC at 19:16:14, AVAX on Avalanche at 19:16:15 and ETH on Ethereum at 19:16:23. One address, three independent networks, nine seconds — which points to automated execution by a single process able to sign for that address on all three. The other two legs of that burst, on Tron and the XRP Ledger, came from different addresses.

The second burst carries the largest single amount of the day, the 91.42M XRP at 19:16:20.

Not claimed: that one party controlled all the senders in either burst, how any transfer was authorised, that a key was compromised, that a contract was or was not exploited, or any attack vector. Bitget's written posts name none.

The same address on two chains

0x7c96279Ec1e888Aa56b9B836e0dB26ca48573E1C received funds from 0x770b… on both Ethereum (stablecoins and XAUT, 19:07–19:22) and BSC (12,719.45 BNB, tx 0x999c012afcec5ab171b8e7e61c859e2f2ec69fb5ae43d35b3ae0c52153fee4b1, 19:45:16). On Ethereum it is an EIP-7702 delegated account. On both chains it then made bridge calls with the same function selector (0x3ce33bff, bridge(string adapterId, address srcToken, uint256 amount, bytes data)): on Ethereum to the contract labelled MetaBridge (0x0439e60F…C3f1), on BSC to 0xaec23140408534b378bf5832defc426df8604b59 (2 × 1,000 BNB at 19:45:54 and 19:46:49; adapter id lifiAdapterV2). The BSC contract's identity is not verified beyond that matching selector and the calldata text; we do not name its operator.

Same address, same tooling, two networks: a fact about the chains, no inference about intent.

Onward movement

From the recipient outward. No labels involved.

At 23:00 UTC on 24 September roughly 66K ETH sat on nine Ethereum addresses, most with nothing sent since. That was true of that evening and is not true now. No address here is attributed to anyone.

What else happened around 20:40 UTC

Between 20:40:02 and 20:43:11, on six networks, Bitget-labelled wallets moved balances into a small set of destination addresses:

0xaDFf… and 0x2620… have months of history (first activity 20 May and April 2026); 0xaDFf… had also received smaller transfers from the same source wallets on a regular schedule since August.

What this shows: simultaneous balance movements on six networks inside three minutes. It is consistent with the emergency response Bitget describes.

What it does not show: that it *was* that response. A scheduled sweep would look similar.

The open point. One destination, 0xffa8…cD54, is the address that sent the 19:16 transfers to 0x770b…. So the 20:40 movements did not take everything away from an address involved in the earlier transfers. As of 23:00 UTC 0xffa8…, 0xaDFf… and 0x2620… had sent nothing since 20:40 on Ethereum, and 0x1AB4… and 0x5bdf… were still transacting normally until at least 21:54.

Now the other question: what does our own tool say?

Everything above is a chain read, done by hand. This section is our product's answer to the same question, run as anonymous, read-only requests to the public source-of-funds endpoint on 2026-09-27 at 10:37 UTC — three days after the hand-walk, on production, with no cached result (every response carried cached: false). The endpoint asks one question: who sent funds to this address?

It answers on all six EVM chains. Every provider leg reports ok — four chains served by Alchemy, BSC and Avalanche by Ankr — and every chain is scored: true, which is this product's way of saying it read the data rather than failing quietly.

Here is the part worth publishing. The hand-walk and the tool identify the same inflows, and the amounts agree to every digit the hand-walk recorded:

Sixteen transfers, ten asset legs, six chains, two completely separate ways of reading the same public data — the hand-walk through RPC nodes, Blockscout and Routescan, the tool through Alchemy and Ankr. Not one quantity differs.

The dollars differ, and it is worth saying exactly why

The tool's inbound totals for that address, from our run:

That is 0.63% above the hand-walk's $192.5M, and the reason is not a disagreement about what happened. The two numbers are valued on different dates. The hand-walk prices each transfer at its own block time on 24 September. The tool prices every leg at the price on the day you run it — so the same transfers, read on 27 September, are quoted in 27 September money.

Take the tool's own quantities and re-price them at each transfer's block-time price, and the total comes to $192,517,098.74 — the hand-walk's figure, to four significant figures.

The single biggest gap is Avalanche, where the tool reads 4.4% higher than one earlier summary of the hand-walk. It is entirely AVAX. DefiLlama quotes AVAX at $10.4440 at 19:16:15 on 24 September and $11.0509 on 27 September — the coin moved 5.8% in three days, and it is the only asset in the set that moved that far. The tool counts exactly the two Avalanche legs the hand-walk counts, at exactly the same amounts. Nothing is over-counted. On BSC the drift runs the other way (BNB fell), which is why the aggregate gap is smaller than Avalanche's.

We ran the endpoint twice, six minutes apart, over the same transfers. The totals differed by $38,608 — nothing had happened on any chain in between; the prices had simply moved. That is the cleanest proof that the dollar comparison was the weaker half of this: for a dated event, this endpoint reports today's value of what moved, not the value at the time it moved. It is a live screening tool, and on a historical incident that is a real limitation, not a rounding question. The quantities are what carry the claim.

What the tool reports that a table would not

Of the 69 inbound transfers it found across the six chains, 25 carried a price, 33 were valued below a cent, and 11 were assets nothing quotes a price for. It filtered 20 senders as address-poisoning lookalikes. Nothing was left unpriced because a price source failed to answer: price_unread and price_rejected were both zero on all six chains.

That residue is the real texture of a busy address. Most of the 69 "inflows" are dust sent by addresses whose first and last characters mimic the real participants — noise designed to be copied out of a wallet's history by someone in a hurry. It contributes nothing to the dollar figure, and it is the reason the transfer count and the money count are different numbers.

The tool also names 0x1ab4973a48dc892cd9971ece8e01dcc7688f8f23 as the largest single sender into this address on Ethereum: $72,636,407.12 over 6 transfers. We are naming the address and nothing else about it.

One number we deliberately do not quote is the sender count. On Ethereum the tool lists sixteen senders and reports *none* filtered as address poisoning — while twelve of those sixteen are dust from addresses whose characters mimic other addresses in this very case. On the other five chains the same filter removed twenty. A sender count on Ethereum would therefore be counting noise as counterparties, so every count in this piece is a count of transfers, not of senders. On Base there is a second reason: one of the senders the tool marks as "identified" is itself a poisoning address, and the name attached to it comes from an unverified row. We publish no name out of that field.

One limitation, stated because the response states it: an anonymous request reads a window of "25 transfers per asset class — the 13 newest and the 12 largest of the 75 most recent read." For this address, on 27 September, that window happens to contain every leg that matters. On a busier address, or later, it would not. A window that holds the answer today is not a promise about tomorrow.

What this is, and what it is not

It would be easy to call the agreement above a benchmark. It is not one, and we would rather say so than sell it.

A benchmark, in the sense we hold ourselves to, compares our answer against a total somebody outside this company computed and published — Sky Mavis's own disclosure of the Ronin Bridge theft, the FBI's Bybit advisory. We have run those, and they are the standard. What this piece contains is two of our own methods, run by the same team, agreeing with each other. That is a regression check on our pipeline, not external validation, and the fact that both methods now return the same sixteen amounts to the digit says only that our reading of the chain is internally consistent.

The one figure here that *was* established outside ChainHint is Bitget's "approximately $351.6 million", and we do not agree with it: we are $5.7M above, and we have named three ordinary reasons a difference of that size appears without claiming which of them applies. That is an honest disagreement, not a benchmark pass.

Where it stands on 27 September

The tables above are cut at 2026-09-25 ~10:30 UTC. This piece goes out two days later, so we re-read the balances from public nodes on 2026-09-27 between 11:07 and 11:09 UTC — the XRP Ledger from Ripple's public rippled server, Tron from TronGrid, Ethereum and Avalanche over public RPC. One thing changed, and it changed completely.

Every address in this article that was holding funds is now empty.

r3UGfDM4ZyFSCzKH7TQEjgago9QoUJagtJ returning "account not found" is not an error on our side: the XRP Ledger lets an account that has been emptied be deleted outright, and this one was. Its 20,000,000 XRP arrived at 22:03:41 on 24 September, and the account is gone.

The XRP Ledger accounts were emptied one at a time, in sequence, each over a few hours, each in dozens of payments of roughly 0.3M–2.4M XRP to a rotating set of further accounts:

Several destination accounts recur across more than one source — rGDKxwQWvAXbcTk1jgZrSQWrcGVjfR2ph2, r3ZqSCQ1MdYUc498XDW3gsumeN4PPJawAR, r4HFFpv8h7ZHotdJXsSku6Evj1MUEeukXp, rUMntqQwnFM3KQHHi3zBZFPW6981QqQs4C, rGkWhwBucjVatAEj5AXFwFY9e6MQhkgAX7 among them.

What we are not saying. We read the most recent 60 ledger transactions of each account, which is enough to establish when each was drained and the shape of it, and not enough to enumerate every payment or to total them — so no total for the onward movement appears above, and the per-account destination lists are partial. We did not follow the funds beyond that first onward hop, we do not attribute any destination account to anyone, and we do not claim the draining was done by the same party that received the funds on 24 September, or that it was not.

The 0x770b… Avalanche balance of 10.97 AVAX and the sub-cent Ethereum balances are the residue of gas, not a holding.

What we did not find

• Why our total ($357.3M) is $5.7M above Bitget's figure.
• The onward path of the 12,719 BNB after the BSC bridge calls, and of the TRX moving on Tron.
• Our scan covered labelled Bitget wallets (about 26.8K addresses on EVM chains, two

XRPScan-labelled XRP Ledger accounts, 11 Tronscan-tagged Tron addresses, a small set on Solana and Bitcoin) plus their direct recipients. The Tron sender TJxe1M… was found from the recipient side, not from a label: the labelled set alone would have missed it. Other unlabelled wallets, including the "warm layer" the CEO's notice mentions, are outside what we can see.

• The 14 labelled Bitcoin wallets sent nothing after 18:31 UTC.

Wallet tiers

Third-party data (Arkham) calls 0xffa8…cD54 a cold wallet. Bitget describes the affected layers as hot and warm. We have no basis to say which description is right, and do not.

What this page does not claim

• That any address is an attacker, thief or laundering wallet. Recipients are "recipients of

the transfers described", and unconfirmed as to attribution — all of them.

• Any attack vector, or how signing access was obtained.
• That Bitget's figure is right or wrong.
• That the 20:40 movements were Bitget's response.
• That the agreement between our hand-walk and our own tool is an external verification of

either. It is not; see above.

• Anything about funds beyond the addresses traced here.

Method and limits

Chain data read directly from public nodes and explorers: RPC nodes, Blockscout, Routescan, the Solana RPC and the XRP Ledger's public rippled server. The transfer tables are cut 2026-09-25 ~10:30 UTC, with the EVM tables cut 2026-09-24 ~23:10 UTC and re-verified. Balances were re-read on 2026-09-27 between 11:07 and 11:09 UTC and are reported separately, in "Where it stands on 27 September"; a balance is true of the moment it is read and of no other moment.

Prices: the DefiLlama historical price API at each transfer's block timestamp, retrieved 2026-09-24 ~23:10 UTC (EVM) and 2026-09-25 ~10:00 UTC (XRP, TRX); native assets by their market identifiers, tokens by contract address; stablecoins valued at market price, not at $1.

Transfers spoofed by lookalike tokens and lookalike addresses (address poisoning) are excluded — only native transfers and transfers emitted by the real token contracts count. An asset's identity is its contract, never the ticker it calls itself.

Labels are third-party (EVM, Solana, XRP Ledger) and are not confirmed by Bitget.

The product figures in "what does our own tool say" are a separate, later run — anonymous requests to the public source-of-funds endpoint at 2026-09-27 10:37 UTC, valued at that day's prices, as described in that section.