The Bitget hack refers to the September 24 incident in which Bitget detected abnormal fund transfers from parts of its hot-wallet and related online wallet infrastructure, with the estimated amount affected later revised from roughly $351.6 million to approximately $387.5 million. The increase mainly reflected Zcash and TRON transactions that had not been fully included in the initial estimate, rather than additional abnormal transfers occurring after the incident had been contained, and Bitget said user balances were not directly affected because losses were covered by its protection reserves.
According to Bitget’s official disclosure of the affected funds, the incident involved Ethereum and multiple EVM networks, XRP Ledger, Zcash, and TRON. Bitget said its cold wallets were not affected and that the incident had been brought under control, while Mandiant and SlowMist joined the subsequent investigation and fund-tracing efforts.
For crypto traders, investors, security-conscious exchange users, and institutions assessing counterparty risk, the key question is not just the headline loss but what it reveals about exchange design and recovery capacity. This analysis examines how the attack likely worked, what it meant for withdrawals and wallet exposure, where phishing and follow-on risks can emerge after a breach, and why the case matters for anyone comparing exchange security controls, asset segregation, and financial backstops such as user protection funds.
Why Was the Bitget Wallet Hacked? The Problem Was Not Simply a Private-Key Leak
According to Bitget’s subsequent investigation, the attacker compromised a critical backend system within its wallet infrastructure and used it to manipulate transaction data, bypass existing security controls, and trigger unauthorized transfers.
This makes the incident different from the more familiar scenario in which an attacker simply obtains a wallet’s private key. Large crypto exchanges operate complex wallet systems involving transaction generation, permission checks, signing, risk controls, and on-chain broadcasting. A compromise at one critical point in that chain can still result in substantial losses even when the underlying private keys themselves have not been directly exposed.
The incident primarily affected hot wallets and related online wallet systems, while Bitget’s cold wallets remained unaffected. For exchanges, hot wallets are necessary to support routine deposits, withdrawals, and asset transfers, so they cannot be kept fully offline.
The key question is therefore not whether an exchange uses hot wallets at all, but how much capital is exposed online, how effectively different wallet layers are isolated, and how quickly abnormal transfers can be detected and stopped.
Why Didn’t the $387.5 Million Loss Directly Reduce User Funds or Balances?
An exchange wallet being compromised does not necessarily mean the same amount is automatically deducted from users’ account balances.
After the incident, Bitget said user balances were unaffected and that the financial impact fell within the coverage of its User Protection Fund. In its initial announcement, Bitget said the fund was worth more than $464 million. As the confirmed amount affected was later revised to roughly $387.5 million, the company continued to publicly claim that the Protection Fund would cover the platform-level financial impact.
This is where a user protection fund becomes particularly relevant during a major security incident. If an exchange suffers an abnormal loss but has dedicated funds available to absorb that impact, the incident may be less likely to spread into user balances or routine withdrawals.
The amount stolen is therefore only one part of the picture. Customers and users also need to consider who ultimately bears the loss, whether the platform has sufficient financial buffers, and whether normal asset movement can be restored. A large loss at the platform level does not always translate into an equivalent loss for users.
Why Does Customer Withdrawals Recovery Matter After a Security Incident?
Bitget paused customer withdrawals after detecting the abnormal transfers and later announced a phased restoration plan following vulnerability remediation and additional security checks. Under the schedule announced on September 26, BTC withdrawals were set to resume from September 28, followed by ETH and USDT, with other tokens as well as fiat and C2C services scheduled to return from October 2. Trading continued while withdrawals were being restored.
A temporary withdrawal suspension does not automatically mean an exchange has a solvency problem. Once a vulnerability has been identified in wallet infrastructure, the platform needs to recheck withdrawal systems, transaction authorization, and risk controls. Reopening fund outflows before those checks are complete could increase the damage.
What matters more is how the recovery develops. Users can look at whether the platform clearly explains why withdrawals were paused, should continue updating the restoration schedule, and actually reopens different assets according to plan.
In incidents like this, the orderly recovery of withdrawals is one of the more useful signals for assessing the condition of both the platform’s infrastructure and its fund flows.
The Bitget Incident Exposes More Than Just Hot-Wallet Risk
The attack occurred within exchange wallet infrastructure, but crypto asset risk extends well beyond the possibility of hackers compromising a single exchange wallet.
On the platform side, vulnerabilities may arise from wallet systems, backend permissions, signing services, or internal risk controls. Once the technical defense is breached, the exchange’s financial capacity becomes another important factor. A loss that initially appears to be a technical issue can become a liquidity problem if the platform does not have enough capital or risk reserves to absorb it.
For ordinary users, many losses happen at the account level instead. Compromised email accounts, reused passwords, overly broad API permissions, malicious browser extensions, fake customer-service accounts, and phishing websites can all result in asset losses even when the exchange itself is operating normally.
Self-custody does not eliminate risk either. It shifts responsibility away from the platform and onto the user. Private keys, seed phrases, malicious signatures, and smart-contract approvals can all become points of failure. For long-term holdings, hardware wallets are generally the recommended option.
Exchange custody and self-custody are therefore better understood as different risk structures rather than one being absolutely safe and the other unsafe. For users, avoiding long-term concentration of all assets in a single platform, account, or custody model can reduce exposure to any one type of failure, especially as broader industry threats such as north korea-linked exchange thefts continue to surface.
After a Major Security Incident, Phishing Can Become the Second Wave of Risk
When a large exchange suffers a security incident, users often become highly focused on withdrawals, compensation, and account status. That anxiety can create another opportunity for attackers.
Messages offering "withdrawal restoration," "compensation claims," "account security verification," or "protection fund access" can easily be disguised as fake support messages or phishing pages. Attackers do not need to breach the exchange again if they can persuade users to reveal passwords, verification codes, or sign malicious on-chain transactions.
Bitget also warned users to rely only on its official website, app, Support Center, and verified social channels for incident updates, while remaining cautious of phishing links, impersonation accounts, and unofficial asset-recovery services.
During incidents like this, withdrawal and compensation information should be checked through official channels rather than links received through private messages or unfamiliar websites. Reviewing login devices, API permissions, and account security settings can also reduce the chance that a platform-level incident turns into an individual account compromise.
Platform infrastructure recovery and personal account security are two separate risk layers.
What Platform Security Indicators Matter More After the Bitget Incident?
A single security incident does not fully define the long-term security of an exchange. More useful signals come from how the platform manages risk before, during, and after an incident.
Wallet segregation affects how far an attack can spread. Whether long-term reserves are separated from everyday online liquidity, whether cold wallets remain isolated, and how permissions and signing systems are managed all influence the amount of capital that can be exposed during a breach.
A user security asset fund shows whether a platform has additional financial resources available when a major loss occurs. In Bitget’s case, the User Protection Fund became a central factor in determining whether the platform-level loss would affect customer assets.
Response speed and transparency also become highly visible once an incident occurs. How quickly abnormal activity is identified, whether the vulnerability is fixed, when withdrawals resume, and whether confirmed findings are continuously updated all provide more useful information than a broad statement that "user funds are safe."
How Does Gate Build an Additional Protection Fund as a Financial Buffer for Major Security Incidents?
Within Gate’s asset security framework, the Gate Secure Asset Fund for Users (SAFU) is designed specifically to provide an additional financial buffer for major security and asset-risk events. Gate has disclosed that the SAFU was worth approximately $500 million as of August 8, 2025.
Gate also regularly publishes information about its platform reserves. As of August 19, 2026, Gate reported total reserves of approximately $8.215 billion and an overall reserve ratio of 127%, providing users with visibility into the platform’s asset coverage.
These mechanisms sit alongside wallet management, account-level risk controls, and withdrawal security measures. The broader point is that exchange security depends on several layers working together: technical controls help reduce the chance and scope of an attack, while dedicated financial buffers can provide additional support when an extreme event still occurs.
Exchange Security Is Expanding Beyond Simply "Preventing Hacks"
When the Bitget incident first emerged, attention naturally focused on how the attack happened and how much had been stolen. CEO Gracy Chen said the incident was being investigated and that customer protections remained in focus, while Chen also pointed to the exchange’s latest loss estimate as the working figure. As the investigation developed, the discussion quickly shifted toward whether cold wallets had been affected, whether the Protection Fund could absorb the loss, and when withdrawals would resume.
That shift reflects a broader change in how exchange security is being evaluated.
Technical defenses remain essential, but no complex online system can guarantee that a breach will never occur. Similar exchange thefts in Sep fit a pattern that continues across the sector. When security controls do fail, asset segregation, dedicated financial buffers, withdrawal recovery, and transparent communication all influence how severe the final impact becomes.
For exchanges, security is increasingly not only about stopping attackers from entering a system. It also includes containing damage, maintaining financial resilience, restoring services, and communicating clearly when an incident occurs.
Conclusion
Bitget’s more than $380 million security incident shows that even without a direct private-key leak, wallet infrastructure and transaction authorization systems can still become attack vectors.
For users, the size of the theft is only part of what matters. It is equally important to understand which asset layers were affected, whether the platform can absorb the loss, and whether withdrawals and normal fund movements can be restored.
Crypto assets cannot be made completely risk-free. Exchanges can reduce the likelihood and impact of attacks through stronger isolation, security controls, and financial buffers, while users can reduce their own exposure by avoiding excessive concentration in a single platform, account, or custody model.
