Regulation

Bitget Lost $388m but Its Protection Fund Covers All of It

The attacker never touched Bitget's private keys. Valid administrator credentials were enough, and a $465m fund is absorbing the whole loss.

⏱ 2 min read Regulation
Quick Summary
  • Transfers ran for 64 minutes after the reconciliation system flagged the discrepancy.
  • Bitget's 135% reserve ratio attests to wallet control, not to who can authorise a withdrawal.
  • A $465m protection fund covers the $388m loss, backed by corporate reserves above $1.4bn.

Bitget lost $388 million on the evening of 24 September. Its user protection fund is absorbing all of it, and withdrawals are reopening in stages.

The exchange’s private keys were never compromised. The attacker held valid administrator credentials instead.

Chief executive Gracy Chen has published a minute-by-minute account of what those credentials allowed.

One Hour, Seventeen Transactions

It began with two small transfers at 6:31pm UTC. The attacker moved 0.184 ETH out of an Ethereum hot wallet and 193 TRX out of a Tron hot wallet. Both were small enough to clear the exchange’s risk-control thresholds without raising an alert, which Chen describes as the attacker testing those controls before committing.

The real withdrawals started 27 minutes later. From 6:58pm, seventeen transactions moved funds across eight separate blockchain networks.

At 7:05pm Bitget’s reconciliation system caught a discrepancy, seven minutes after the first of those transfers.

The final transfer left at 8:09pm, 64 minutes after that alarm.

How the Credentials Were Used

Bitget says a zero-day vulnerability in a third-party security product yielded valid administrator credentials. Those were used to insert fraudulent withdrawal commands directly into wallet backend systems, and the traces were deleted afterwards. Chen called the deletion “the trickiest part.”

Cold wallets were untouched throughout.

That account is Bitget’s own and the vendor has not been named. Mandiant and SlowMist are running independent forensics, so it may change. North Korean involvement has been suggested and is unconfirmed.

What a Reserve Report Would Not Have Caught

Bitget publishes monthly proof-of-reserves attestations, self-verified with an open-source tool, and reported a 135% reserve ratio this month across 19 assets.

None of it bears on this. A proof of reserves shows that an exchange controlled wallets holding certain assets on a given date. It says nothing about who inside the company can authorise a withdrawal, or what a valid credential in the wrong hands is able to move.

The keys held. The authorisation path did not. Only one of those gets attested to every month.

Customers Are Covered

The user protection fund held $465 million and is absorbing the full loss. Chen says it will be back above $300 million within a week, drawn from corporate reserves she put above $1.4 billion as of 31 August. The fund itself is held as 5,500 BTC.

Bitcoin withdrawals resumed on Sunday. Ether and the layer-2 networks follow on Tuesday, USDT on four chains on Wednesday. Everything else, fiat and peer-to-peer included, stays suspended until 2 October.

One detail sits awkwardly against that. The loss was first put at $352 million and later revised to $388 million, a 10% increase. Being unable to size a loss immediately is a different failure from being unable to cover it, and Bitget could cover it.

⚖️ Our Verdict ⚖️ Watch and Wait

For anyone holding funds at Bitget the answer is reassuring: a $465 million protection fund is covering a $388 million loss in full and withdrawals are reopening in stages. The concerning part is operational rather than financial. Detection took seven minutes and the draining continued for 64 more, the test transfers passed under the thresholds unnoticed, and the vendor behind the zero-day has not been named while forensics continue.