Deep Dive: Bitget One Week Later — The Calendar Held, the Money Did Not Come Back

📋Promises vs Delivery: The Scorecard

🔎What the Root Cause Actually Was — and How Long It Lasted

The September 30 reports from Mandiant and SlowMist confirmed the account we sketched last week and filled in the detail that matters most. The attackers did not steal keys and did not forge user requests. They compromised third-party security products used by Bitget — two of them, per both reports — used that foothold to reach the production wallet environment, deployed malicious packages on wallet infrastructure, and sent fraudulent withdrawal commands through Bitget's own approval flow. The exchange's systems signed what its compromised tooling asked them to sign.

SlowMist's log analysis set the timeline's most uncomfortable number: the earliest malicious activity traces to August 31 — 24 days before detection on September 24. For nearly a month, the attacker held working internal credentials and used them only twice: two small test withdrawals at 18:31 UTC on September 24 that stayed below risk-control thresholds, then the main haul beginning about 30 minutes later. Chen described operations masked as routine administrative work, with logs cleaned behind them.

Neither report attributes the attack to a named group, and Bitget has explicitly declined to speculate. Chen has said preliminary technical indicators were consistent with known North Korean actors, while stressing that attribution awaits the investigation's conclusion. The affected vendors have not been named.

Takeaway: the breach was a supply-chain intrusion with a 24-day dwell time, executed through the tools whose job was to prevent it. No proof-of-reserves page attests to any of this layer.

🧮The Recovery Ledger, as of October 2

🔀Why So Little Came Back: Three Routers, Three Answers

The laundering split explains the freeze arithmetic better than any single number. The attacker routed funds through infrastructure where different rules apply, and got three different results. Through THORChain, an attacker-linked wallet converted roughly $6.3 million of ETH into 75.2 Bitcoin — permissionless liquidity, no chokepoint, conversion succeeded despite Bitget's request to block. Through NEAR Intents, more than $50 million of related transfers were stopped. Through Chainflip, one deposit was refused at the broker interface and returned to the attacker's own address — not frozen, declined.

Layer the asset classes on top and the pattern completes: about $83 million of stolen XRP moved early and freely — XRP has no issuer with a pause button — while the stablecoin freezes, though instant and surgical, caught under 0.3% of the total. The attacker's portfolio consolidation (roughly 68,000 ETH per Arkham's tracing) was itself a freeze-avoidance step: ETH converts anywhere.

This is the structural lesson of the whole affair, and it applies to every stablecoin user including this site's readers: freezability is a feature of the asset you hold, but recoverability depends on the route the thief picks. The attacker needs one permissive route; defenders need all of them.

Takeaway: the ~$1.1 million is not a failure of the freeze mechanism — it is the mechanism working exactly to its boundary, and the boundary is small.

🏦What Users Were Actually Covered By

It is worth being precise about what protected depositors, because none of it was retrieval. User balances never changed in the accounting records — the loss landed on Bitget's balance sheet. The User Protection Fund absorbed the loss and was refilled above $300 million with Bitget's own capital within six days — on-chain verifiable, separate from the reserves backing customer balances. The proof-of-reserves snapshot taken September 29, five days into the crisis, showed 131% coverage across 19 assets.

That is the honest description of how depositor protection works at a well-capitalized venue in 2026: not recovery of stolen funds — under 0.3% so far — but capital adequacy plus the ability to keep operating while absorbing the loss. The fund refill is a solvency statement, not recovered money, and the two ledgers should never be conflated in headlines.

The performance record is still genuinely good by industry standards: attacker addresses published within a day, two independent forensics firms engaged, a dated restoration calendar with no priority tiers (the same schedule for retail, VIPs and employees), a CEO AMA before the first resumption batch, and every date held. Against the sector's failure modes — CoinEx converting missed exits into a 5% monthly fee, venues that freeze and go quiet — this is close to the best execution of a bad week we have documented. It was also, by the exchange's own account, preventable.

💷The Practical Rewrite: Sizing Balances for a 7.5-Day Outage

Before this incident, our standing guidance sized exchange balances against withdrawal fees and transfer costs — the arithmetic this site publishes weekly. The incident adds a second, harder number: the realistic duration of a full withdrawal outage at a major, well-run venue. Bitget's answer was about seven and a half days, with BTC available after roughly four. Even the best-case 2026 execution — calendar published in two days, every date held — means a week without an exit.

The rules that follow are unchanged from last week's checklist but now carry evidence. Keep exchange balances sized to what you need on the venue — not to what you cannot afford to lose. Keep a second venue you have actually tested with a small withdrawal. When a calendar is published, diarize your asset's date and treat the slot as the start of a verification process, not the end — first transfer small, confirmed arrived, then size up.

And note what did not matter: the fee table. Bitget's $1 never changed. Through eight weeks of tracking, every user-level cost surprise has been an availability event — a suspension, a deadline, a shutdown — while the price of moving funds held perfectly still.

Takeaway: withdrawal fees are stable enough to plan around; withdrawal availability is the variable that actually moves. Size for the second, optimize for the first.