Bitget confirms $351.6M unauthorized transfers, pauses withdrawals during security review
The exchange says trading and deposits remain live, and its $464M+ User Protection Fund can cover the affected amount.
Bitget says it detected unauthorized transfers totaling about $351.6 million from a limited number of hot wallets and temporarily suspended withdrawals while it investigates. The exchange says user balances remain accurate, trading and deposits are operating normally, and a $464 million-plus protection fund is positioned as the backstop.
Key Takeaways
- Bitget confirmed unauthorized transfers affecting approximately $351.6 million in assets and temporarily suspended withdrawals during a security review.
- The exchange said the incident was contained to parts of its hot and warm wallet layers, while cold wallets remained secure.
- Deposits and trading stayed operational and user account balances remained accurate, even as withdrawals were paused.
- CEO Gracy Chen said the affected amount is covered by Bitget’s User Protection Fund, which she said holds more than $464 million.
Bitget Confirms $351.6M Unauthorized Transfers, Freezes Withdrawals During Review
Bitget has confirmed unauthorized transfers affecting approximately $351.6 million in assets and said it temporarily suspended withdrawals while it investigates what happened. The exchange framed the pause as a security review rather than a broader platform outage, and it kept trading and deposits running.
Bitget said its security systems detected the transfers at 18:31 UTC on “Thursday,” and that the activity involved a limited number of hot wallets. The exchange said it activated emergency response procedures after detection.
For traders, the immediate distinction is operational. Bitget’s statement draws a line between matching-engine continuity and cash-and-carry reality: deposits and trading are still available, but the ability to move assets off-platform is not. That makes withdrawal availability the near-term counterparty variable, even if the order book remains open.
Bitget also said user account balances remained accurate during the incident. That claim matters because it is the exchange’s way of saying the internal ledger is intact, even as it works through what left the wallets.
What Bitget Says Was Hit: Hot/Warm Wallet Layers, Not Cold Storage
Bitget’s containment narrative is specific: CEO Gracy Chen said the breach was limited to a portion of the exchange’s hot and warm wallet layers, while cold wallets remained secure. The exchange also said “most platform assets” were unaffected.
Mechanically, that scope claim is doing a lot of work. A hot wallet is the internet-connected wallet layer exchanges use for day-to-day withdrawals and deposits, which makes it operationally necessary and structurally higher risk. A warm wallet typically sits between hot and cold storage as a partially online layer that can replenish hot wallets without exposing the deepest reserves. Cold wallets are designed to be offline custody, used for longer-term storage precisely to reduce the attack surface.
If Bitget’s description holds, the incident looks more like a compromise of the withdrawal pipeline than a full reserve impairment event. That does not make it small, but it changes the failure mode traders should model. A cold-wallet compromise tends to raise existential questions about reserves and long-term solvency. A hot or warm wallet incident more often turns into a liquidity and operations problem: how fast the exchange can contain, reconcile, and safely reopen withdrawals without creating a second incident during the restart.
The catch is that Bitget has not disclosed how the wallets were compromised and said it would not speculate on the attack vector while the investigation is ongoing. Without that root cause, “hot/warm only” is a claim that can’t be independently stress-tested from the packet’s information, because there are no transaction identifiers, asset breakdowns, or third-party forensic notes included.
Protection Fund Backstop, Address Flagging, and the 24-Hour Incident Report Promise
Bitget is positioning its User Protection Fund as the financial backstop for the incident. Chen said the full amount affected falls within Bitget’s User Protection Fund, which she said currently holds more than $464 million. On the numbers alone, that implies coverage capacity exceeds the approximately $351.6 million the exchange says was transferred without authorization.
A User Protection Fund is an exchange-managed reserve intended to cover user losses from incidents like hacks or security breaches. In practice, the fund only matters to users to the extent it is both real and liquid at the moment it is needed, and to the extent the exchange is willing to deploy it quickly rather than turning the event into a prolonged claims process.
On the response side, Bitget said it flagged addresses associated with the transfers and contacted law enforcement and onchain security firms. That is the standard first move when an exchange believes funds have moved onchain and wants to increase the odds of freezes or recoveries, but the packet contains no confirmation that any funds have been frozen or recovered.
Bitget also committed to a tight disclosure cadence. Chen said the exchange would provide hourly updates and publish a full incident report within 24 hours, including a root-cause analysis and corrective actions. That promise is now the procedural hinge for the story: it is the point at which the exchange either turns a high-level incident statement into a verifiable narrative, or it does not.
What remains unresolved is substantial. Bitget has not specified which assets comprised the approximately $351.6 million, which hot wallets were affected, or whether the figure could change as reconciliation continues. The exchange’s own language leaves room for updates, and the hourly cadence is implicitly an admission that the first number may not be the last.
Traders’ Checklist: Signals to Monitor Until Withdrawals Resume
The first signal that matters is whether Bitget resumes withdrawals, and what “resume” actually means in practice. A restart can come with limits, queues, or asset-by-asset gating, and the difference between a full reopen and a throttled reopen is the difference between operational inconvenience and a longer-lived counterparty risk premium.
The second is whether Bitget publishes its promised incident report within 24 hours, and whether that report contains a concrete root-cause analysis and corrective actions rather than a narrative summary. The useful version names what failed in the wallet stack, what was changed, and what controls were added, because that is what lets users judge whether the same class of compromise is still possible.
Third, the hourly updates should be read for two kinds of drift: any change in the stated affected amount (about $351.6 million) and any change in the stated scope (hot/warm layers versus cold storage). If either moves, the market’s interpretation of “contained” changes with it.
Finally, watch for confirmation that the flagged addresses led to freezes or recoveries after Bitget said it contacted law enforcement and onchain security firms. The exchange has described the escalation path, but it has not stated an outcome, and recoveries are the difference between a protection-fund payout and a partial unwind of the loss.
My Read: The Withdrawal Pause Is the Real Risk Variable Until Root Cause Is Public
The part most traders will misread is the fact that trading is still live. That can look like normalcy, but in incidents like this the matching engine is rarely the binding constraint. The binding constraint is operational: whether withdrawals reopen cleanly, and whether they reopen in a way that does not create a second wave of failures when pent-up outflows hit the hot-wallet pipeline.
Bitget is trying to frame this as a contained hot/warm wallet event, and if that is accurate it reduces the probability of a deeper reserve impairment compared with a cold-wallet compromise. But “contained” is not a vibe, it is a root cause plus a fix. Until Bitget publishes the promised incident report, the market is being asked to accept the scope claim without the mechanism that explains it.
There are two plausible near-term paths from here. If withdrawals resume quickly, the affected amount stays stable around $351.6 million, and the 24-hour report names a specific control failure with corrective actions that map to the failure, this becomes a painful but bounded incident where the protection fund is a credible backstop and the main damage is reputational. If withdrawals resume but only with heavy throttling, or if the hourly updates revise the number upward or broaden the scope beyond hot/warm layers, then the risk shifts from “incident response” to “liquidity management,” and the protection fund claim becomes less about headline coverage and more about how fast Bitget can deploy it without destabilizing operations.
The threshold that matters is procedural and observable: a timely root-cause report that explains the compromise, followed by a withdrawal restart that works at scale. If Bitget can deliver both without moving the scope beyond hot and warm wallets, the incident stays operational rather than existential.
