On September 26, Bitget announced a withdrawal suspension. Two days later, on September 28, Bitcoin withdrawals resumed. Ethereum followed on September 29. USDT on September 30. Everything else โ other tokens, fiat rails, P2P โ was pushed to October 2.
That ordering is not a marketing decision. It is a diagnostic artifact.
When a centralized exchange restores withdrawal capability, the sequence in which assets come back online records the order in which internal systems were deemed safe to trust again. Read it the way you read a stack trace after a crash. Bitcoin first means the cold-to-hot signing path was validated for the simplest asset. Ethereum second means account-model signing logic cleared review. USDT third means multi-chain custody across Ethereum, BSC, Solana, and Tron passed a second inspection. P2P last means fiat corridors and manual risk review remained the least trusted component. The announcement says "fixed." The schedule says something far more specific.
To understand what actually happened, reconstruct the protocol from first principles. A CEX withdrawal is not one operation. It is a pipeline: user request, risk engine, balance debit, signing service, hot wallet, broadcast, chain confirmation. Each stage has its own failure mode. A compromised API key breaks stage one. A manipulated risk engine breaks stage two. A leaked hot wallet private key breaks stage four โ and that is the stage that matters most, because it is the only one where an attacker can move funds without internal approval.
That is why withdrawal suspension is such a blunt instrument. You cannot pause a subset of a signature system when you do not yet know which key or approval path was abused. You close everything, then reopen in order of confidence.
Mandiant and SlowMist were named as assisting the investigation. This raises the forensic credibility of the process. It does not raise the verifiability of the outcome. "Assisting an investigation" is not the same as "publishing a conclusion," and the distinction matters enormously here. SlowMist routinely publishes detailed post-mortems for DeFi exploits. In this case, no root cause, no affected range, no loss figure, and no key-rotation disclosure has reached the public.
Three things can be inferred from the visible surface, each at a different confidence level.
First, the staggered schedule implies key rotation or hot wallet reconstruction rather than a simple restart. If the issue had been a frontend or API bug, restoration would have been simultaneous โ signing infrastructure is largely asset-agnostic in most exchange architectures. Splitting by chain and asset class suggests the remediating team needed to re-derive, re-sign, or re-threshold signing authority for each custody domain separately. In my own audit history, the closest parallel is the 2020 Curve stableswap review: the flaw there was not a missing function, but a rounding path producing a value the designers never intended to be reachable. Fixing it required rebuilding the invariant path, not flipping a switch. The same logic governs custody. You do not patch a signing system; you re-establish trust in every component that touches the key.
Second, the statement that losses are covered by a protection fund is an admission of material loss. A purely precautionary pause does not draw on a reserve. A reserve is drawn when assets have left. This does not mean user balances are impaired โ exchanges can absorb losses at the corporate level โ but it does mean the event was not cost-free, and the fund's size relative to the loss is undisclosed. Based on my experience auditing protocols, protection funds are almost never third-party insurance. They are self-funded reserves, sometimes denominated in the exchange's own token. If that is the case here, real coverage is a function of the fund's own market liquidity โ precisely the variable that collapses during a crisis.
Third, the multi-chain USDT restoration reveals where withdrawal demand concentrates. USDT was scheduled across Ethereum, BSC, Solana, and Tron. Tron's inclusion is not incidental. It is the lowest-fee rail for retail stablecoin movement, and it is where the largest queue of pending withdrawals would accumulate. Restoring the cheapest rail last, but before P2P, is a liquidity decision as much as a technical one.
Here is the counterintuitive point most coverage will miss. The phased restart is being read as a recovery. It is better understood as liquidity choreography.
Consider the incentives. An exchange that has suffered a custody compromise faces two simultaneous problems: it must verify that its signing systems are clean, and it must prevent a bank run from exhausting remaining liquidity. Staggering withdrawals by asset class solves both at once. It throttles aggregate outflow, it lets the exchange observe net flow per chain, and it creates the appearance of methodical control. That is not necessarily deceptive โ it is rational operational behavior under stress โ but it means the schedule cannot be used as evidence that the technical problem is resolved. The recovery timetable is a risk-management instrument, not a security attestation.
The second blind spot is verification. Every claim in this event โ "vulnerability fixed," "assets unaffected," "losses covered" โ originates from Bitget. The ledger remembers what the narrative forgets. On-chain, the only falsifiable signals are withdrawal transaction volume, exchange net outflow, and whether a reserve attestation appears. Until a Merkle-tree proof of reserves is published and independently checked, all of the above remains an unaudited assertion. Stability is not a feature; it is a discipline, and discipline is demonstrated by disclosure, not by scheduling.
Watch the first seventy-two hours of large withdrawals. If they clear without delay, the narrative may shift toward competent crisis management. If queue depth grows, or silent limits appear, the residual-vulnerability hypothesis strengthens. The forward question is not whether Bitget restores withdrawals. It is whether any exchange restoring them can prove, cryptographically, that the keys it signs with were never out of its hands. Protecting the user has always meant answering that question before it is asked.