Bitget Sets Withdrawal Phases: What XRP Holders Can Verify

What Bitget’s latest update means for XRP withdrawals

Bitget plans to restore withdrawals in stages after its September 24 security breach. Its September 27 update keeps other tokens in an October 2 phase, without naming XRP separately. For XRP holders, the decisive evidence is actual withdrawal availability and completed delivery, distinct from balance assurances or recovery of stolen funds.

Confirmed record: Bitget’s latest explainer maintains that its identified vulnerability has been repaired, while investigation and security validation continue. These remain exchange statements, also reported by The Crypto Times. A customer can therefore read the schedule as an operational plan without treating it as an independent certification that every withdrawal route is already safe or available.

The practical question is narrower than whether the exchange has announced a recovery plan: when can a particular customer move the particular asset they hold? A Bitcoin reopening can demonstrate progress in one service without answering that question for XRP. This report separates the scheduled service restoration, the exchange’s financial assurances and the evidence of asset recovery so each can be assessed on its own terms.

Section sources[1][2][3]

The October 2 phase is a timetable, not an XRP completion receipt

Bitget’s September 26 notice schedules Bitcoin withdrawals for September 28, Ether for September 29 and USDT for September 30. Each phase starts at 08:00 UTC. The remaining category, covering other tokens, fiat and peer-to-peer services, is scheduled for October 2 at the same time. The Crypto Times independently reported this sequence and placed XRP in that final group.

Interpretation: XRP’s expected placement follows from the catch-all category; the official table does not provide an individually named XRP row. A useful record should preserve that distinction. An amended notice could specify networks or conditions more precisely, and an actual enabled route would provide stronger evidence than a broad date. Until then, describe October 2 as the schedule’s applicable category, not a successfully completed XRP reopening.

For an operations team, that difference changes what goes into a cash-access calendar. A planned date belongs in the forecast column. A confirmed withdrawal route belongs in the available-services column. A transfer received at its intended destination belongs in the completed-delivery column. Moving an entry between those columns should require new evidence. This is an editorial verification framework, not a claim about Bitget’s internal accounting or a recommendation to initiate a transaction.

Section sources[2][3]

Bitget’s loss estimate and customer balances answer different questions

Bitget’s September 25 tracing update raised its affected-asset estimate from approximately $351.6 million to $387.5 million. It attributed the revision to additional Zcash and TRON transfers classified from the original incident, rather than a further theft. CoinDesk and The Crypto Times reported the same explanation. These are exchange-wide dollar estimates across several assets, not a valuation of stolen XRP alone.

The exchange also says customer balances remain unaffected and its Protection Fund covers the incident’s financial impact. Independent reporting confirms that Bitget made those assurances; it does not turn them into an independent audit of the fund or a completed withdrawal. A balance statement describes what the platform credits to a customer. Access describes whether the customer can actually transfer that value through the relevant service.

Analysis: a useful hypothetical shows why those records cannot substitute for each other. Suppose a customer sees an unchanged XRP balance while the withdrawal route is unavailable. The unchanged number does not measure the time until delivery. Conversely, if a later withdrawal reaches the customer, that proves the particular transfer completed; it does not reveal whether Bitget financed it from existing resources, replacement funds or recovered assets. The example makes no claim about any actual customer’s experience.

Section sources[1][3][4][5]

An exchange withdrawal pause does not freeze native XRP on the ledger

XRPL’s official documentation distinguishes native XRP from tokens issued on the network. Its issuer-freeze functionality does not apply to XRP. CoinDesk’s September 26 reporting corroborates the consequence for this incident: Ripple cannot use that functionality to prevent the attacker’s XRP transfers, although an exchange can restrict an account receiving stolen assets on its own platform.

That distinction explains how customer withdrawal restrictions and attacker-controlled transfers can coexist. They concern different control points. Bitget controls whether its service processes a customer request. Native XRP already controlled elsewhere is governed by the ledger’s transaction rules, not by a withdrawal toggle inside Bitget. No contradiction follows merely because one channel is closed while activity continues through another.

For readers assessing recovery announcements, identify both the asset and the place where a restriction operates. A statement that some funds were frozen does not establish that native XRP was frozen. A restriction on an exchange account also does not establish that the assets have returned to the victim. Those distinctions preserve the significance of genuine containment while preventing a partial intervention from being mistaken for a complete recovery.

Section sources[4][5][6]

Dated XRP traces show movement, with limits on what can be inferred

Bitquery’s investigation recorded 27.63 million XRP moving onward and approximately 75.35 million remaining in six tracked accounts at 02:54 UTC on September 26. Its analysis describes subsequent routing and swaps toward Bitcoin. CoinDesk then reported about 54 million XRP leaving the original holding accounts by 12:41 UTC that day, based on its own review of ledger records. The observations support movement, but their timestamps and tracked account sets differ.

Uncertainty: those figures are historical snapshots, not a current balance claim. They should not be subtracted from each other to manufacture a precise later flow without reconciling the address populations and counting method. Nor should a reader add successive transfers of the same XRP as though every hop were another asset stolen. A changing location and a changing amount of ownership are different measurements.

For market analysis, the next useful question is what happened after each transfer, not simply how large the transfer was. A route into a swap service can support a claim about conversion when the matching transaction is verified. It still cannot, on its own, establish the effect on a particular exchange’s order book or explain an XRP price move. This article makes no estimate of price impact or total XRP sale proceeds.

Section sources[5][7][8]

What XRP customers and counterparties should verify after reopening

Bitget’s official notice says availability will be shown directly on its platform and that users do not need to act before the rollout. The Crypto Times reports the same instruction. The immediate task is therefore to check the official status for the required asset and network when the relevant phase arrives, rather than treating an announcement about another asset as permission or proof of XRP access.

A practical evidence record can stay simple: retain the dated service notice, record the displayed availability, and, for any transfer a customer independently chooses to make, reconcile the requested asset and destination with the resulting receipt. This proposed checklist does not imply that AllAboutXRP has tested Bitget withdrawals. It also avoids making a customer transaction the test of broader claims about the exchange’s security architecture.

For businesses depending on an exchange balance, analysis should track two separate outcomes: restoration of usable customer access and verified recovery of the assets taken. Either can improve before the other. A later reopening would be a meaningful operational milestone, while a recovery report would require its own amounts, assets, timestamps and evidence of return. The unresolved question is how those outcomes will develop after the announced phases begin, not whether one headline can stand in for both.

Section sources[1][2][3][4]