Bitget initiated the restoration of customer withdrawals on September 28, starting with the Bitcoin network at 08:00 UTC. This move follows a security exploit reported on September 24, which The Block described as involving approximately $388 million. The exchange confirmed that the vulnerability has been patched and stated that its protection fund will cover losses. However, the recovery is proceeding in phases, with separate stages assigned to ETH, USDT, and remaining services rather than an immediate full return to normal operations.
The phased approach means that asset availability varies by network and specific withdrawal route, requiring users to check individual account statuses rather than relying on general headlines. Operational targets for subsequent stages may shift as security checks continue, and a scheduled opening does not guarantee that individual requests have cleared screening or entered processing queues. Investigators are still reconciling assets and valuation times, meaning the initial loss figure is not yet a final customer-loss calculation. Distinct quantities such as amounts transferred by attackers, recovered funds, and costs borne by the company remain under review.
This development highlights the critical distinction between blockchain functionality and centralized exchange operational readiness. While the underlying Bitcoin network remained uninterrupted, the exchange’s internal systems required extensive verification before safely reopening withdrawal endpoints. The phased restart underscores that restoring access controls, transaction authorization, and balance accuracy are complex processes that extend beyond simply patching a vulnerability. For institutional participants, this serves as a reminder that liquidity is not solely defined by market price but also by reliable settlement routes and provider concentration risks.
From a compliance and credibility perspective, the gap between company assurances and independent confirmation remains significant. Bitget’s statement regarding coverage via its protection fund requires scrutiny against the evolving accounting of the incident, particularly given the discrepancies often found between attacker-transferred amounts and actual customer liabilities. The episode reinforces the need for transparent post-incident reporting, including detailed explanations of the compromise and evidence of consistent request clearing. Users must remain vigilant against impersonation attempts exploiting the confusion of partial service restoration, while businesses should reassess treasury planning to account for temporary access disruptions even when assets appear economically valuable.
