Bitget revises breach figure to $387.5 million as fuller on-chain tracing adds Zcash and TRON transfers
Bitget has increased its estimate of losses from last week’s security breach to $387.5 million, up from the $351.6 million first reported, after deeper on-chain tracing revealed transfers that the exchange had missed in its initial accounting.
The revision, disclosed by the exchange following the incident of Sept. 24, 2026, stems largely from the discovery of movements in Zcash (ZEC) and TRON (TRX) that were not captured in the first pass of forensic work. Bitget stressed that the higher figure does not indicate any new unauthorised transfers after the attack took place. Rather, it represents a more complete picture of what was moved during the incident itself.
That distinction matters for market participants. In the days after a major breach, the difference between an ongoing haemorrhage and a delayed accounting correction is significant. Bitget’s framing, delivered by CEO Gracy Chen, is that the theft was contained within the original incident window and that the additional $35.9 million now on the books reflects the difficulty of tracking stolen value across chains with very different transparency profiles.
The affected assets spanned Ethereum and several EVM-compatible networks, the XRP Ledger, Zcash and TRON. Reported holdings moved to attacker-controlled addresses included XRP, ETH, USDT, USDC, USDT0, XAUt, BNB, AVAX, ZEC and TRX. Bitget has published receiving addresses it attributes to the attackers on each of those chains, including a designated EVM address, an XRP address, a ZEC address and a TRX address.
The inclusion of Zcash in the mix is notable. Unlike Ethereum or Tron, where transaction histories are publicly readable, Zcash offers shielded transactions that can obscure sender, recipient and amount. It is precisely this property that can make post-incident tracing slower and less complete, which may explain why the ZEC leg of the theft surfaced only after the initial estimate had been published.
How the attackers got in: a compromised backend, not a broken key
According to Chen, the attackers compromised a critical backend system within Bitget’s wallet infrastructure, spoofed transaction data, and then triggered the exchange’s own authorisation process to move funds out. In other words, this was not a private key leak in the conventional sense, nor a smart contract exploit. The exchange’s approval machinery appears to have been fed falsified data and executed transfers it believed to be legitimate.
That mechanism carries uncomfortable implications for the industry. Most post-mortem guidance after exchange breaches focuses on key management, multisignature schemes and cold storage. Bitget’s cold wallets did remain secure, and the breach was confined to parts of its hot and warm wallet layers. But the attack vector described here targets the layer above the keys: the systems that decide, sign and sequence withdrawals. If those systems can be made to lie to themselves, hardware-grade key custody does not prevent the loss.
The incident therefore sits alongside a broader pattern of increasingly sophisticated operations against crypto intermediaries, in which attackers invest in compromising internal infrastructure rather than attempting to break cryptography. Bitget has said the attack bears the hallmarks of a North Korea-linked operation, though the company itself has framed this as an assessment rather than a confirmed finding. No legal attribution has been established, and readers should treat the claim accordingly.
Containment, compensation and the bounty programme
Bitget moved quickly on several fronts after the breach. Withdrawals were suspended in the immediate aftermath, with one report indicating the exchange expected to resume them on Sept. 28. A suspension of that length, roughly four days, is consistent with an exchange rebuilding confidence in its withdrawal pipeline before reopening the gates.
The company has stated that its protection fund covers the loss. For customers, that is the single most consequential reassurance: a breach of this scale that is absorbed by an exchange’s own reserves rather than passed to users is a very different event, commercially and reputationally, from one that leaves depositors holding the shortfall. The credibility of that protection fund, its actual size and composition, will now be scrutinised closely by users and competitors alike.
Bitget has also launched a Fund Tracing and Recovery Bounty Programme, an appeal to on-chain analysts, forensic firms and the wider community to help trace and recover the stolen assets. Bounty programmes of this kind have become a standard part of the post-breach playbook. They work in part because stolen crypto, once moved through mixers, bridges or privacy chains, often leaves fragments that third-party analysts are better positioned to catch than the victim’s own team. The published attacker addresses across EVM chains, XRP Ledger, Zcash and TRON give trackers concrete starting points, and the presence of stablecoins such as USDT and USDC among the stolen assets raises the possibility of issuer freezes, one of the few recovery levers that has worked in past incidents.
For continuing coverage of exchange security incidents and their market consequences, see our exchange security coverage.
What the revision tells us about breach accounting
The jump from $351.6 million to $387.5 million, roughly $35 million in additional identified losses, is worth pausing on. Initial loss figures after any major hack are almost always preliminary. Exchanges under pressure to communicate quickly publish numbers based on what their monitoring can see in the first hours. Cross-chain thefts complicate this further, because the tooling that tracks Ethereum and EVM movements is far more mature than the tooling for older or privacy-oriented chains.
Zcash is the clearest example. A ZEC transfer, particularly if shielded, may simply not appear in the dashboards most exchanges rely on. TRON presents its own tracing frictions, with high throughput and heavy stablecoin activity making manual reconciliation slower. The lesson for the market is that first-day loss estimates should be read as floors, not totals, and that a headline revision upward is not necessarily evidence of continued compromise. In Bitget’s case, the company has been explicit that no new unauthorised transfers occurred after the incident, and the revised figure is an accounting of the same event.
There is also a competitive and regulatory dimension. An exchange that revises a loss figure upward by about ten percent within days invites questions about its internal visibility into its own wallets. Regulators in major jurisdictions have been pushing for proof-of-reserves reporting, real-time attestation and clearer disclosure of custody architecture. An incident in which spoofed transaction data successfully triggered an authorisation process will almost certainly feed into that debate. If a backend compromise can bypass controls, then reserve attestations that assume honest signing systems provide only partial comfort.
The reputational stakes are high in another sense. Bitget operates in a market where users can move between venues at near-zero cost. A breach handled well, with prompt disclosure, a funded compensation commitment and a functioning bounty programme, can be survived. What users punish hardest is opacity, repeated revisions without explanation, or any sign that losses are being socialised. The next few weeks, as the recovery programme plays out and as independent analysts publish their own tracing of the attacker addresses, will determine how durable the damage is.
The wider read
Strip away the specifics and the Bitget incident is a reminder of an uncomfortable asymmetry in crypto infrastructure. Blockchains themselves have proven remarkably resistant to direct attack. The losses keep coming from the human and institutional layer above them: backend systems, authorisation workflows, signing processes and the people who run them. Bitget’s cold wallets held. Its key management, by the company’s own account, was not the point of failure. What failed was the machinery that tells keys what to do.
For exchanges, the actionable lesson is that transaction integrity checks, segregation of backend privileges and independent verification of withdrawal requests deserve the same engineering rigour traditionally lavished on key custody. For users, the lesson is older and simpler: size and brand are not substitutes for custody discipline, and funds held on any exchange, hot or otherwise, carry counterparty risk that self-custody does not.
The final loss number, $387.5 million, places this among the larger exchange breaches on record. Whether it stays there depends on recovery efforts now underway. The stablecoin component may prove freezable. The Zcash component may prove the hardest to claw back. And the attribution question, currently an allegation of North Korean involvement, will be settled by investigators rather than press releases. What is already clear is that the incident will shape how exchanges account for, disclose and defend against breaches for some time to come.