After a Crypto Exchange Hack: How to Verify Recovery Claims

Start with a timestamped record of confirmed claims

Bitget said it detected unauthorized transfers from some hot wallets at 18:31 UTC on September 24, 2026. Its first notice estimated approximately $351.6 million in affected funds, said cold wallets remained secure, paused withdrawals, and stated that its protection fund would cover the loss. These are direct statements from the operator; they are primary evidence of what Bitget reported, not independent proof that every statement is complete.

A September 25 update revised the amount transferred to attacker-controlled addresses to approximately $387.5 million after adding assets on Zcash and TRON. It also published identified receiving addresses and said Mandiant and SlowMist were supporting the investigation. The revision is a useful reminder to preserve each version of an incident timeline rather than treating the first figure as final.

• Record the publication time, incident time, affected services, and the exact language used.
• Label each point as operator-confirmed, independently observed, customer-reported, or unresolved.
• Keep later corrections beside the original figures instead of silently replacing them.
• Do not infer a cause or attacker identity before supporting evidence is published.

Do not confuse an account balance with access to funds

An exchange can keep internal balances visible while withdrawals are disabled. The displayed number shows what the platform’s ledger attributes to an account; it does not demonstrate that a user can settle the claim onchain or to a bank. Deposits and trading remaining open do not establish withdrawal availability either.

On September 26, Bitget published a phased schedule: Bitcoin withdrawals from September 28 at 08:00 UTC, selected ETH networks from September 29, selected USDT networks from September 30, and other tokens, fiat, and peer-to-peer services from October 2. Until each route actually processes withdrawals, the schedule is a forward-looking commitment rather than completed recovery.

• Check the exact asset and network; one restored route does not mean every route is open.
• Distinguish “withdrawal submitted,” “processing,” and a finalized destination transaction.
• Avoid adding funds merely because deposits or trading remain available.
• Once the official app shows the route as restored, consider a small test before a larger transfer.

Test a protection-fund claim in layers

A protection fund may improve the recovery options, but its headline value is only the first question. Determine which assets make up the fund, where they are held, who controls them, whether their market value can change, and which incidents and users are eligible. Then look for evidence that fund assets were actually deployed or losses were absorbed without impairing customer liabilities.

Bitget said its protection fund held more than $464 million at the time of the initial notice and would cover the incident. Researchers should preserve that as a dated company claim and follow the post-incident evidence: updated fund balances, transfers, audited or attested records, claim terms, and whether affected users regain access. “Covered” describes an intended outcome; it does not by itself document how or when that outcome was delivered.

• Fund assets, wallet addresses, valuation time, and price concentration.
• Custody, signing authority, encumbrances, and any ability to borrow against the fund.
• Eligibility rules, exclusions, approval process, and expected payment route.
• Post-event transfers and balances that reconcile with the stated use of the fund.

Recheck reserves after the event—not only before it

Proof of reserves can help show that specified assets existed at a stated time. It does not automatically prove complete customer liabilities, ownership free of other claims, operational security, or the ability to honor withdrawals during stress. A pre-incident reserve ratio cannot establish the financial position after assets have left controlled wallets.

Look for a new, post-incident reserve publication with a clear observation time and asset scope. Verify your own liability inclusion when a Merkle-tree method is available, examine whether all material networks and account types are included, and note whether an independent accountant or security firm is making a narrow finding or a broader assurance claim. Reserve evidence becomes more persuasive when it reconciles with functioning withdrawals over time.

• Post-incident asset balances and complete customer-liability scope.
• Wallet ownership or control and any borrowed or pledged assets.
• Coverage across spot, earn, margin, derivatives, and institutional accounts.
• The date, review scope, exceptions, and methodology of any third-party work.

Demand enough detail to evaluate the remediation

“The vulnerability has been remediated” is a status statement, not a root-cause report. A useful post-incident review should explain the affected component, initial access or exploit path, how controls were bypassed, the systems and networks in scope, the containment sequence, and the changes designed to prevent recurrence. It should also separate confirmed findings from hypotheses still under investigation.

Independent firms being involved is relevant, but their names alone do not reveal the engagement scope or conclusion. Look for a publication from the firm, a signed assessment, or a clearly described review boundary. Ask whether the work covers the exploit investigation, the repaired system, wallet architecture, key management, and the restored withdrawal infrastructure—or only a subset.

• Root cause and affected architecture.
• Whether private keys, signing systems, application logic, or internal access were involved.
• Detection gap, containment time, and the controls that failed or worked.
• Specific corrective actions, owners, deadlines, and independent validation.

Use onchain evidence without overstating it

Public transactions can confirm that assets moved between addresses and can help track later transfers. They do not, on their own, prove who controlled an address, how access was obtained, whether an internal record is accurate, or which legal entity owes a customer. Address attribution and transaction classification can change as investigators gather more information.

Save transaction hashes and the source of each address label. Compare the exchange’s published addresses with reputable independent tracing, and note freezes or recoveries only when the relevant issuer, venue, investigator, or transaction evidence supports them. Avoid turning a clustering heuristic into a definitive claim about the attacker.

Treat the recovery period as a phishing event

Attackers exploit uncertainty by impersonating support staff, promising priority withdrawals, or demanding an emergency wallet migration. The FTC warns that unexpected impersonation messages and requests to send crypto to “protect” funds are scam patterns. A real incident makes a fake rescue message more believable, not more legitimate.

Bitget Wallet separately warned users that no third-party connection, asset migration, transfer, private key, seed phrase, or verification code was required in response to the exchange incident. Whatever service you use, navigate through a saved official domain or installed app, verify announcements there, and never follow a recovery link from a direct message.

• No legitimate recovery requires a seed phrase or private key.
• Do not pay an unlock, verification, tax, or priority-withdrawal fee to an unsolicited contact.
• Verify the domain and announcement inside the official product before taking action.
• Preserve suspicious messages and report them through the platform’s official support route.

Grade recovery by observable milestones

A binary “safe” or “unsafe” verdict hides the parts of recovery that remain incomplete. Use milestones instead: incident acknowledged; unauthorized movement contained; affected scope revised; withdrawal plan published; individual routes processing; all material routes restored; post-event reserves published; customer losses reconciled; root-cause report released; remediation independently reviewed.

Date each milestone and link the evidence. If the exchange misses a deadline or changes the scope, record the change and explanation. Recovery confidence should rise because observable obligations were completed—not because the volume of reassuring posts increased.

• Can customers complete withdrawals on the promised assets and networks?
• Do post-incident reserves and liabilities reconcile after the loss?
• Is protection-fund use documented rather than merely pledged?
• Does a detailed root-cause report support the claimed remediation?
• Has an independent reviewer described what it actually tested?