Bitget halted XRP withdrawals on Sept. 26 following a security breach that occurred two days earlier, according to the exchange’s public status dashboard. The move came as blockchain analysts tracked nearly 28 million stolen XRP moving from attacker-controlled accounts toward cross-chain swap networks.
The Sept. 24 breach resulted in $387.5 million in total unauthorized transfers, Bitget announced on Sept. 25 after revising its initial loss estimate upward by $35.9 million. The revision reflected additional Zcash and TRON assets discovered among stolen funds, not further XRP transfers.
Bitquery, a blockchain analytics firm, traced 27.63 million XRP moving from two tracked attacker accounts by 02:54 UTC on Sept. 26. A separate 75.35 million XRP remained in six tracked accounts at the same timestamp. Bitquery’s total estimate of XRP taken from Bitget stands at 102.98 million tokens.
The stolen XRP flowed toward THORChain, a cross-chain swap network, with most being swapped toward Bitcoin, according to Bitquery’s analysis. The exchange did not specify which wallets or addresses ultimately received the converted proceeds.
Withdrawal Reopening Schedule
Bitget’s phased withdrawal reopening began Sept. 28 with Bitcoin at 08:00 UTC, followed by Ethereum on Sept. 29 and USDT on Sept. 30. A final phase scheduled for Oct. 2 at 08:00 UTC covers “other tokens,” fiat withdrawals, and peer-to-peer services. XRP does not appear as a separately listed asset in the reopening timeline, placing its restoration within the Oct. 2 final phase by exclusion.
The exchange identified and remedied the vulnerability underlying the Sept. 24 incident and was conducting further checks of withdrawal infrastructure as of the Sept. 26 status update. User balances remained unaffected. Trading and deposits continued on the platform throughout the incident.
Recovery and Impact
Bitget did not confirm whether any stolen funds have been recovered. The $387.5 million loss represents a potential 76% drain on the exchange’s protection fund, according to related analysis.
The attacker’s identity remains unconfirmed. Bitget did not disclose the specific nature of the vulnerability or provide a technical postmortem as of Sept. 26.
