Bitget loses $351.6m — and the fund it says covers it is one we could not verify

Bitget lost $351.6m on 24 September, in what is now the largest confirmed theft from a centralised crypto exchange this year. The exchange’s systems flagged unauthorised transfers out of several hot wallets at 18:31 UTC, across nineteen separate transactions drawing on hot and warm wallet infrastructure. Cold storage was not touched. Withdrawals are suspended; deposits and trading remain open.

Bitget says customer balances are accurate and that the loss is fully absorbed by a User Protection Fund holding more than $464m. Chief executive Gracy Chen has said the attackers did not obtain private keys, and that investigators found IP addresses tied to VPN services a North Korean hacking group has used before.

“The private keys were not compromised” is not the reassurance it sounds like

That sentence has been the headline of Bitget’s response, and it is worth reading carefully. According to the company’s own account, attackers compromised a wallet backend, spoofed transaction data and fed it into the exchange’s authorisation process — which then approved the transfers.

Put plainly: nobody had to steal a key, because the system that decides which transactions get signed was persuaded to sign the attacker’s. In a straightforward key theft, the defence is to rotate keys and move the funds. Here the keys are fine and the thing that failed is the logic sitting in front of them, which is harder to audit, harder to prove clean afterwards, and the reason withdrawals are still off more than a day later. An exchange that could confidently distinguish its own instructions from a forged one would have reopened by now.

We looked at that protection fund before the hack

Bitget’s defence rests on the User Protection Fund, and this is where we can add something to the wire coverage. We examined that fund earlier this year while scoring exchanges for our crypto exchange rating, and the finding cuts in both directions.

The favourable half is real and unusual. Most exchange “insurance” funds are marketing: vague pools with no stated trigger, which quietly turn out not to cover the event that happens. Bitget’s is one of the few genuinely scoped to theft — several thousand BTC, held separately, which users can claim against if assets are stolen through no fault of their own. On the specific question of whether this hack is the kind of event the fund is for, the answer appears to be yes.

The unfavourable half is that we could not verify it. Bitget says the fund is monitorable through public wallet addresses and does not print those addresses on the fund page. Its own figures for the fund’s size disagree between that page and its blog. And when we opened Bitget’s proof-of-reserves page, the reserve-ratio table rendered “No data found”, with no attestor named anywhere on it. We scored Bitget 5 out of 10 on custody for those reasons, before any of this happened.

None of that means the money is not there. It means that at the moment users most need to check — withdrawals suspended, an exchange asking to be believed — the machinery for checking is the machinery we found empty. “Fully covered” is currently a statement by the party that owes the money.

What the withdrawal suspension actually tells you

Suspending withdrawals is the correct move if you do not yet know how the attacker got in, and it is also the action that has preceded every exchange insolvency in this industry’s history. The two are indistinguishable from outside on day one. What separates them is time: a security halt ends in days with a published post-mortem, and a solvency halt extends, acquires conditions, and ends in a restructuring announcement.

The signals worth watching are specific. Whether Bitget publishes the Protection Fund’s on-chain addresses, which would convert its central claim into something anyone can verify in a block explorer. Whether withdrawals resume in full rather than under caps. Whether the post-mortem names the backend component that was compromised. And whether an attestation of reserves appears with an actual firm’s name on it.

On the North Korea attribution

Chen has said state-linked hackers are “very likely” responsible, citing IP addresses associated with VPN services previously used by a North Korean group. She did not name the group, and some analysts have disputed a direct link to Lazarus.

This deserves less weight than it is getting. Infrastructure reuse is weak evidence — VPN endpoints are rented and shared, and North Korean attribution has become the default explanation for large exchange thefts partly because it is plausible and partly because it shifts the story from a company’s security failures to a nation-state adversary nobody expects a firm to stop. It may well be right. It changes nothing about whether the funds come back, and it is not a substitute for the post-mortem.

The second-order effect: BGB

Bitget’s exchange token carries this directly. BGB has no function outside Bitget, no claim on the company and no recourse if the company is impaired — its value is a bet on one firm’s continued operation, and the firm just demonstrated an unresolved failure in its transaction authorisation. Exchange tokens are typically discussed in terms of burn schedules and fee discounts. This is the risk they actually carry, arriving.

What we would tell a reader holding funds there

We do not give investment advice and the operational point is straightforward: an exchange balance is a claim on a company, not ownership of an asset, and that distinction only becomes visible on days like this one. Whatever is resolved here, the general lesson is the old one — assets you are not actively trading do not need to sit on an exchange, and self-custody removes this entire category of risk in exchange for a different one you control yourself.

We will update this story as Bitget publishes, and our exchange rating will be re-scored once there is a post-mortem to score against.