Bitget hacked for $351.6M: Is Lazarus behind it?

The first transfer was small enough to look harmless: 0.84 Ether sent from a Bitget-labeled wallet to a newly created address. What followed was not. Stablecoins, tokenized gold, Ether, Avalanche, BNB, and possibly 93.7 million XRP moved across several networks while the recipient wallets converted and dispersed assets at speed.

Bitget CEO Gracy Chen’s security notice on the $351.6 million hot-wallet incident from X, as of September 24, 2026.

Bitget’s security notice puts the affected amount at around $351.6 million. The exchange says its systems detected unauthorized transfers at 18:31 UTC on September 24, cold wallets remained secure, user balances were accurate, and withdrawals were paused during a security review. Those are important disclosures, but they do not yet explain how a wallet service produced transactions the business did not intend to authorize.

That missing explanation is the center of the story. Bitget chief executive officer Gracy Chen has described a possible supply-chain compromise affecting a backend wallet service rather than a leaked private key. Separately, on-chain investigator Specter has connected part of the stolen XRP trail to funds associated with the July 2026 AFX hack. That earlier case was attributed to TraderTraitor, a threat cluster linked to the Democratic People’s Republic of Korea (DPRK). The connection is specific enough to investigate, but not complete enough to call the Bitget attacker Lazarus Group as a settled fact.

What happened in the Bitget hack

The public transaction trail developed in pieces, which is why the first estimates were much lower than Bitget’s final figure. Early trackers concentrated on Ethereum Virtual Machine (EVM)-compatible networks and counted around $170 million to $183.8 million. Bitget later included a broader set of assets and networks in its $351.6 million estimate. The apparent difference is not automatically a contradiction, but a transaction-by-transaction reconciliation has not been published.

The clearest early sequence looks like this:

• Initial test: A transfer of 0.84 Ether reached a fresh address at around the same minute Bitget says its security systems detected the incident.

• Stablecoin outflows: The address reportedly received around 34.75 million Tether, 12.85 million USD Coin, and 3,000 units of Tether Gold from exchange-labeled wallets.

• Rapid conversion: On Arbitrum, a separate fresh address used around 19.67 million USDT0 to buy roughly 7,111 Ether through UniswapX and 1inch Fusion. Some executions reportedly paid a premium of as much as 5%, suggesting that speed mattered more than price efficiency.

• Additional networks: Around 821,012 Avalanche and a later transfer of 8.2 million USD Coin were reported from Bitget-labeled infrastructure on Avalanche. BNB Chain activity also appeared in the broader reconstruction.

• XRP leg: Two Bitget-labeled wallets reportedly sent a combined 93.7 million XRP to a new XRP Ledger address. At prices cited during the incident, that leg was worth around $143 million and could explain much of the gap between the early EVM totals and Bitget’s estimate.

Bitget’s initial disclosure of the September 24, 2026 wallet incident, affected-funds estimate, and temporary withdrawal suspension from Bitget, accessed September 25, 2026, around 02:40 UTC.

For now, affected is the accurate word for the $351.6 million figure. It is not yet a final net-loss calculation. A final figure should subtract any assets that remained under Bitget’s control, were frozen by issuers or exchanges, were returned, or were recovered. None of those categories had been publicly reconciled by the research cutoff.

The timing also deserves attention. Detection at 18:31 UTC did not immediately end every reported movement. The 8.2 million USD Coin transfer on Avalanche was reconstructed at around 20:55 UTC, more than two hours later. Several explanations remain possible: signed transactions may already have been queued, different networks may have required separate containment steps, or the compromised path may have remained capable of submitting transactions. Until Bitget publishes the signing logs and containment timeline, detection and containment should not be treated as the same event.

Why the early loss estimates were lower

Blockchain incidents rarely arrive with a clean invoice. Analysts see different addresses at different times, wallet labels can lag, and a single pool of value can appear several times as it is swapped or bridged. Adding every number in a live feed would therefore exaggerate the loss.

Three accounting problems shaped the Bitget estimates:

• Transfers and swaps overlap: If 19.67 million USDT0 is converted into 7,111 Ether, the dollar value of both assets cannot be added as two separate losses.

• Bridges create two visible legs: An asset can leave one chain and appear on another. Counting both sides without matching the bridge event duplicates the same value.

• Prices moved during the attack: Ether was being bought aggressively while trackers valued the flow. A calculation made ten minutes later could produce a different dollar total without any new theft.

The XRP leg is the largest unresolved piece. If the 93.7 million XRP was controlled by the same attacker, the EVM activity plus the XRP transfer brings the external reconstruction much closer to $351.6 million. If that destination served an internal Bitget function or another legitimate counterparty, the gap would need a different explanation. Public labels alone cannot decide ownership.

Ethereum activity associated with the main reported Bitget incident address from Etherscan, accessed September 25, 2026. 

A proper postmortem would remove most of this ambiguity by publishing the affected addresses, transaction hashes, internal wallet roles, assets transferred, assets converted, frozen amounts, recovered amounts, and final outstanding loss. Without that ledger, the $351.6 million estimate is credible as Bitget’s internal total but not independently reproducible.

How a wallet can send a valid transaction that the exchange never intended

A blockchain only checks whether a transaction satisfies its cryptographic authorization rules. It does not know whether the exchange’s risk team approved the payment, whether an employee saw the correct destination, or whether a compromised backend supplied false transfer details to an otherwise functioning signer.

That distinction helps make sense of Chen’s preliminary explanation. She said the incident may resemble a supply-chain attack in which a third-party tool used by Bitget affected a critical backend wallet service. According to that account, forged transfer information reached a signing machine even though the attacker had not directly extracted a private key. The possibility of an insider was described as low, not impossible, and the final vector remained under investigation.

In a normal withdrawal path, several controls should agree before funds move:

1. A customer or internal treasury process creates a legitimate transfer request.

2. Account, device, address, and risk checks determine whether the request is allowed.

3. A policy engine checks the asset, network, destination, amount, velocity, and approval threshold.

4. One or more signing components authorize the exact transaction data.

5. A broadcast service sends the signed transaction to the network.

6. Monitoring systems compare the result with the approved business request and stop abnormal follow-on activity.

Compromising any one stage may not be enough if the remaining controls are genuinely independent. The concern in Bitget’s preliminary account is that a trusted software component may have sat close enough to the signing workflow to influence what the signer approved. If the signer validated only that a request came from an allowed service, rather than independently confirming the destination and amount against an immutable approval record, valid signatures could still authorize malicious transfers.

The most plausible control-failure paths

None of the following has been proved, but each produces a different lesson:

• Compromised vendor or software update: An attacker corrupts a dependency, administrative tool, or service used in the wallet workflow. The exchange may trust requests originating from that component.

• Backend credential theft: A service account, application programming interface credential, session, or privileged token allows the attacker to imitate an authorized internal system.

• Policy-engine bypass: The signing request reaches the signer without normal limits, address allowlists, velocity checks, or approval thresholds being enforced.

• Signing-interface manipulation: Human operators approve one transaction while the signing system receives another. This can happen when the display and the signed payload are not independently bound.

• Key-share or signer compromise: A multi-signature or multi-party computation (MPC) design can still fail if the attacker compromises enough signers, the coordinator, or the approval process surrounding them.

• Privileged insider or contractor access: An authorized person, or an attacker using that person’s access, submits or approves malicious transfers. Bitget currently considers an inside job unlikely, but has not published evidence that rules it out.

Bitget’s description of hot, warm, and cold wallets does not settle which path failed. A hot wallet is designed for frequent online transactions. A warm wallet usually adds stronger approvals or isolation while remaining available for operations. A cold wallet keeps signing authority offline or otherwise separated from routine internet-connected systems. These labels describe intended use, not the actual controls applied to every address on the night of the breach.

Third-party trackers also labeled at least one source as cold infrastructure, while Bitget says no cold wallet was compromised. Either side could be using a different classification. The conflict can be resolved only by mapping the public addresses to their internal roles and explaining how each signer was operated.

Why conversion speed matters

The attacker did not appear interested in holding a neat basket of the assets taken. Stablecoins and tokenized gold carry an obvious problem for a thief: issuers may be able to freeze identified balances. Ether is more liquid across decentralized venues and does not have a central issuer with an equivalent freeze switch.

Paying a premium to acquire Ether through aggregators therefore looks less irrational than it first appears. A sophisticated attacker may accept poor execution when every minute increases the chance that an issuer, bridge, exchange, or validator service will block the next step. The conversion pattern suggests preparation, access to preselected routes, and a willingness to lose some value to improve mobility.

It does not identify the attacker. Fast stablecoin conversion has become standard operating behavior in many large crypto thefts. The technique can support a broader attribution, but it cannot carry one by itself.

Why DPRK-linked hackers are suspected

The DPRK theory rests on three different kinds of evidence: behavior that resembles earlier state-linked thefts, private technical indicators described by Bitget’s chief executive, and a public on-chain claim connecting part of the XRP trail to the earlier AFX exploit. Those layers are not equally strong, and combining them does not automatically turn them into proof.

1. The laundering behavior is familiar but not distinctive

The first clue is the attacker’s speed. Stablecoins and Tether Gold were converted into Ether, funds were divided among fresh addresses, and activity crossed several networks. The Federal Bureau of Investigation’s Bybit notice described TraderTraitor actors rapidly converting stolen assets and dispersing them across thousands of addresses and multiple blockchains after the February 2025 theft.

That resemblance explains why DPRK entered the conversation so quickly. It is still the weakest layer. Criminal groups copy successful laundering routes, aggregators select similar paths for unrelated users, and any attacker holding freezable tokens has the same incentive to move into a more censorship-resistant asset. “They swapped into Ether quickly” is a behavioral match, not a fingerprint.

2. Bitget says IP and VPN indicators resemble a DPRK group

Chen also referred to Internet Protocol (IP) addresses and virtual private network (VPN) choices that investigators associated with a DPRK-linked group. Internal access logs could be meaningful if they show the same rare infrastructure previously controlled by a known actor, especially when paired with consistent device, malware, domain, or authentication evidence.

The public has not seen that material. An IP address may belong to a commercial VPN, a compromised server, a residential proxy, or another victim. Several actors can pass through the same endpoint, and a careful attacker can deliberately borrow infrastructure associated with a rival. An IP match becomes persuasive only when investigators explain how the address was attributed, who controlled it during the relevant minute, and what other indicators traveled with it.

Bitget’s supply-chain hypothesis is compatible with known DPRK tradecraft, but compatibility is not attribution. A joint TraderTraitor cybersecurity advisory describes social engineering and trojanized cryptocurrency applications used to reach employees and company systems. A later FBI account of the DMM Bitcoin theft explains how a fake recruiter, a malicious coding test, stolen session information, and manipulation of a legitimate transaction request were linked in one operation.

Those precedents show that DPRK operators have targeted the human and software layers around crypto wallets, not only private keys. They do not show that the same entry method was used against Bitget. The exchange still needs to identify the compromised component, initial access route, affected credentials, and signing-policy failure.

3. TraderTraitor is a specific threat label, not a synonym for every crypto hack

TraderTraitor is a U.S. government name for particular North Korean malicious cyber activity targeting the blockchain and cryptocurrency industry. The same broader ecosystem may also be discussed under labels such as Lazarus Group, APT38, Jade Sleet, UNC4899, or Slow Pisces, depending on the agency, security company, operation, and period.

These labels overlap, but they are not interchangeable shortcuts. Saying that an AFX-related cluster was attributed to TraderTraitor does not prove every connected address is operated by the same people, nor does it prove that the Bitget intrusion used the same malware or access team. Large state-linked programs can involve different operators, infrastructure, brokers, and laundering specialists.

The terminology matters because “Lazarus hacked Bitget” sounds final. The evidence available at the cutoff supports a narrower sentence: DPRK-linked actors are suspected because a third-party investigator connected the XRP trail to an AFX fund path associated with TraderTraitor, while Bitget says internal IP and VPN indicators point in the same direction.

4. What would turn suspicion into a defensible attribution

A stronger public case would combine independent evidence from several layers:

• Reproducible blockchain tracing: Exact XRP and cross-chain transaction hashes, bridge events, actor-controlled addresses, cluster rules, and an explanation of any exposure through shared services.

• Infrastructure evidence: Domains, servers, certificates, VPN accounts, proxy history, or operational mistakes tied to infrastructure previously controlled by the same actor.

• Intrusion evidence: Malware, scripts, command-and-control traffic, credential theft, session hijacking, or a compromised vendor package with code or infrastructure overlap.

• Timeline consistency: Proof that the actor controlled the linked addresses and infrastructure at the time of both the AFX and Bitget incidents.

• Independent review: A named forensic company, exchange consortium, or public authority reproducing the finding rather than repeating a social-media label.

• Public authority attribution: A government statement that identifies the actor and publishes enough addresses or technical indicators for the industry to act.

The 2025 Bybit case provides a useful benchmark. Five days after the theft, the FBI publicly attributed the incident to North Korea, named TraderTraitor, described the laundering behavior, and listed dozens of related Ethereum addresses. Bitget’s case is only hours old at this article’s cutoff. The lack of equivalent confirmation is not surprising yet, but it means the wording must remain provisional.

5. What could weaken the DPRK theory

The current hypothesis would lose force if the supposed AFX overlap turns out to be a shared exchange, bridge, or service address; if the XRP destination was not controlled by the attacker; if the timeline shows that the common wallet changed hands; or if the AFX attribution itself cannot be independently reproduced. It would also weaken if Bitget’s backend evidence points to a different intrusion set or a financially motivated insider.

There is also a false-flag risk. Once Lazarus laundering patterns are widely documented, another group can imitate them. Copying a swap route is easy. Recreating a long-lived wallet cluster, private infrastructure, malware lineage, and operational mistakes is much harder.

The fairest verdict is therefore credible lead, incomplete attribution. The DPRK theory has more substance than an anonymous rumor because it contains a proposed cross-incident fund link and a separate company-side infrastructure clue. It remains below the standard needed to state that Lazarus Group carried out the Bitget hack.

What Bitget still needs to explain

The exchange’s first notice answered the questions customers needed most urgently: an incident occurred, withdrawals were paused, and the company said balances and cold wallets remained safe. The next report must move from reassurance to evidence.

The missing items are concrete:

• Root cause: Which software, vendor, service, credential, or approval layer was compromised?

• Signing path: Did the attacker produce new signatures, manipulate transaction data before signing, or abuse already authorized transactions?

• Affected infrastructure: Which addresses were hot, warm, or cold, and which wallet controls applied to each one?

• Containment: Why did reported transfers continue after detection, and when was the malicious path actually disabled?

• Loss reconciliation: How does the exchange reach $351.6 million across assets and chains without double-counting swaps or bridges?

• Recovery: How much was frozen, returned, or recovered, and how much remains outside Bitget’s control?

• Customer access: When will withdrawals reopen, on which networks, and with what limits or queue conditions?

• Remediation: Which controls changed before the same signing or backend path could be trusted again?

• Attribution: What evidence supports the DPRK suspicion, and has a named external investigator reproduced it?

At around 02:40 UTC on September 25, withdrawals were still officially paused and the promised 24-hour incident report was not yet due. Deposits and trading remaining operational do not answer the same question as withdrawals. A balance on an internal ledger becomes practically meaningful when the customer can redeem it through a functioning, secure withdrawal path.

Can Bitget’s Protection Fund cover the loss?

Bitget says its User Protection Fund holds more than $464 million and fully covers the $351.6 million affected amount. Its public materials identify 5,500 Bitcoin as the core holding. At a Bitcoin price around $84,403, that position would be worth roughly $464.2 million.

The arithmetic works at that price, but the cushion is thinner than the headline suggests:

• Nominal coverage: Around 132% of the affected-funds estimate.

• Bitcoin required: Roughly 4,166 Bitcoin to equal $351.6 million.

• Fund consumed: Around 75.7% if the whole loss were paid from that Bitcoin position.

• Nominal remainder: Around 1,334 Bitcoin, before transaction costs, price movement, other eligible claims, or market impact.

• Break-even price: Around $63,927 per Bitcoin would reduce 5,500 Bitcoin to the size of the claimed loss.

More important, the fund is a company-controlled reserve, not government-backed deposit insurance. Public evidence has not yet shown whether the assets are segregated, unencumbered, immediately transferable, or formally committed to this incident. The useful question is no longer whether $464 million is greater than $351.6 million. It is whether the fund can be verified and deployed without creating a second liquidity problem.

The September Proof of Reserves (PoR) report adds context, not closure. Bitget published a 135% aggregate reserve ratio across 19 assets before the breach. That snapshot may show that covered assets exceeded corresponding included balances at the measurement time. It cannot show the post-incident position, prove that every liability was included, or demonstrate that wallet controls are secure.

What traders should check after any exchange breach

Exchange security cannot be reduced to a single percentage, certification, insurance-style fund, or claim about cold storage. The useful approach is to examine several layers and understand what each one can and cannot prove.

• Withdrawal behavior: Test whether withdrawals work across the assets and networks you actually use. A small successful withdrawal is more informative than an internal balance display.

• Reserve evidence: Look for recent asset and liability snapshots, wallet ownership evidence, historical reports, and a way to verify that your own balance was included.

• Operational security: Review custody design, signer separation, address controls, monitoring, incident response, and independent testing.

• Corporate disclosure: Check the operating entity, jurisdiction, legal terms, financial reporting, and whether customer assets are treated separately.

• Incident history: Read postmortems, not only announcements. The quality of a response is visible in the addresses, timelines, root causes, and remediation details it publishes.

• Account controls: Enable app-based two-factor authentication (2FA), use a unique password, activate an anti-phishing code, review active devices, and apply withdrawal allowlists where available.

• Custody limits: Keep only the amount needed for trading or near-term transfers on a centralized platform. Self-custody removes exchange-custody risk but introduces key-management and recovery risk of its own.

How major crypto exchanges compare on transparency

This is not a safety ranking. Each row describes a public verification route available on September 25, 2026 and the question it can help answer. None proves that an exchange cannot be hacked, has disclosed every liability, or will keep withdrawals open during a crisis.

What the exchange comparison actually reveals

The table does not produce one universal winner because the exchanges disclose different kinds of evidence. Coinbase provides conventional corporate reporting through quarterly financial statements and annual independent audits. Binance and OKX publish cryptographic reserve systems with wallet data and user-verification tools. Kraken combines account-level verification with reserve ratios for supported assets, while Bybit and Toobit provide Merkle-based ways for users to check whether their balances entered a particular reserve snapshot.

These disclosures answer related but different questions:

• Proof of Reserves: Did the exchange show enough covered assets to match the included customer balances at a particular time?

• User inclusion verification: Can an individual confirm that their balance was counted among the reported liabilities?

• Wallet ownership evidence: Has the exchange demonstrated control of the addresses presented as reserves?

• Financial statements: What do the company’s wider assets, liabilities, revenue, expenses, risks, and corporate obligations look like?

• Security assessments: Have outside specialists tested parts of the platform, applications, custody infrastructure, or internal controls?

• Protection funds: Has the exchange set aside a separate pool that may respond to defined security incidents?

No single item answers everything. An exchange can hold enough reserves and still suffer a wallet compromise. It can pass a security assessment and later introduce a vulnerable integration. It can maintain a protection fund without proving how quickly that fund can be deployed. It can also publish audited financial statements without offering users a cryptographic way to verify the inclusion of their individual balances.

The useful comparison is not simply which exchange displays the largest percentage. It is how many independent layers can be checked, how current those layers are, and whether the evidence matches the risk being evaluated.

Why Proof of Reserves cannot prove wallet security

PoR can show that covered assets existed against included customer balances at a defined snapshot. It is not designed to prove that the systems controlling those assets are impossible to compromise.

The Bitget incident makes that distinction unusually clear. Its September report showed a 135% aggregate reserve ratio across 19 assets before the breach. The reported surplus did not prevent an unauthorized transaction path from moving funds. The problem under investigation concerns wallet operations, transaction authorization, or the software surrounding them, not simply whether assets appeared in reserve wallets before the incident.

A reserve report may help answer:

• Were the covered customer balances included in the liability calculation?

• Did the disclosed wallets contain enough of the relevant assets?

• Could users verify their inclusion through a Merkle path or another cryptographic method?

• Is there a history of reports that can be compared over time?

It generally cannot answer:

• Can a compromised backend submit a malicious signing request?

• Are withdrawal policies enforced independently from the application creating the transaction?

• Could an employee, contractor, or vendor influence multiple approval layers?

• Are all corporate debts, contingent liabilities, loans, and legal obligations included?

• Will withdrawals continue normally during a security incident or liquidity shock?

• Can a protection fund be accessed immediately and without restrictions?

• Will the next software release preserve the controls tested in the previous assessment?

Reserve transparency and transaction security therefore need separate evaluations. PoR deals mainly with asset backing at a stated moment. Wallet security deals with how transactions are requested, approved, signed, broadcast, monitored, and stopped when something goes wrong.

Bybit offers a useful historical example. The exchange had reserve disclosures and user-verification tools before its 2025 breach, yet the incident involved a different problem around the signing workflow. The reserve evidence still had value, but it did not function as a shield against transaction manipulation.

Bitget now faces a similar burden of explanation. A new reserve snapshot could help measure the financial effect of the loss. It would not replace the need for a technical account of the compromised service and failed authorization controls.

How to read reserve ratios without being misled

A reserve ratio above 100% sounds reassuring, but the number needs context. A ratio of 106% means the disclosed reserves for that asset exceeded the corresponding included balances by around 6% at the snapshot. It does not mean the entire exchange has a 6% capital cushion against every possible loss.

Several details determine how useful the percentage is:

• Asset scope: A report covering four major assets is not equivalent to one covering 19 or 22 assets.

• Liability scope: The report should explain which account types, loans, margin positions, or other obligations entered the calculation.

• Snapshot date: A pre-incident report cannot establish the exchange’s financial position after a large loss.

• Wallet evidence: Readers should be able to see how the exchange demonstrated control of its disclosed addresses.

• User verification: A headline ratio is stronger when customers can independently verify that their balances were included.

• Historical continuity: Regular archived reports make it easier to identify abrupt changes in reserves or coverage.

• External review: Independent verification can add confidence, although the reviewer, methodology, and tested scope still matter.

A higher percentage may reflect a genuine surplus, but it may also be influenced by a narrow liability set, temporary balances, asset-price movements, or the exclusion of products outside the report. Comparing headline percentages without comparing scope creates a false hierarchy.

For the same reason, a smaller exchange reporting four assets should not be described as more transparent than a larger exchange solely because one of its percentages is higher. The breadth of the report, liability methodology, wallet evidence, frequency, and user-verification process all matter.

Where Toobit fits in the comparison

Toobit’s public disclosures cover two separate questions. The September reserve report addresses whether four major assets exceeded the corresponding user balances at a particular snapshot. Its security pages describe how the exchange says those assets and user accounts are protected during normal operations.

These disclosures are more useful when examined separately. A reserve ratio can show asset backing at one moment, while a Merkle proof can help a user check whether an account balance entered the reported liability set. Neither one proves that every wallet, internal system, or future transaction will remain secure.

Toobit’s September reserve ratios

Toobit reserve ratios for BTC, ETH, USDT, and USDC as of September 1, 2026, UTC from Toobit, accessed September 25, 2026.

All four ratios were above 100% at that snapshot. This means the disclosed reserves for each covered asset exceeded the corresponding user balances included in the report. The amount above 100% differed by asset, ranging from a 2% margin for Ether to a 6% margin for Tether.

Those percentages should not be added together or treated as one exchange-wide capital ratio. Each one compares a particular asset reserve with the corresponding included user balance. The 106% Tether ratio, for example, says nothing by itself about liabilities denominated in another asset.

The scope matters as much as the percentages. This report covers four widely used assets, while the disclosures listed for Bitget and OKX cover a larger number of assets. Toobit’s report is useful for checking the four named reserves, but it does not establish the backing of every token or product available on the platform.

How users can verify balance inclusion

A published reserve ratio remains a company-level figure until users can check whether their own balances were included in the liability calculation. Toobit’s Proof of Reserves page provides a Merkle root and a verification process for that purpose.

A Merkle tree converts individual account records into cryptographic hashes and combines them into one root value. A user can then verify that a balance formed part of the snapshot without exposing every other customer’s account information.

Toobit Merkle root and account-inclusion verification interface for its Proof of Reserves system from Toobit, accessed September 25, 2026.

The Merkle tool addresses an important weakness in a simple reserve announcement. It gives users a route to check whether their accounts were counted rather than asking them to accept only an aggregate percentage.

That verification still has boundaries. Inclusion shows that a balance entered the reported liability structure. It does not independently prove that every liability was included, that disclosed assets were unencumbered, or that the exchange will maintain the same reserve position after the snapshot.

A useful personal check should answer three questions:

1. Does the verification record match the correct audit date?

2. Does it include the assets and balances the user held at that snapshot?

3. Can the proof be checked through the supplied verification process or open-source tool?

A successful inclusion check strengthens the connection between the user’s account and the published reserve report. It does not turn the report into a full financial audit.

The controls surrounding the reserves

Reserve backing and wallet security address different risks. A reserve snapshot can show whether selected assets covered the corresponding user balances at a particular time. The next question is how an exchange protects those assets, controls transaction access, and responds when suspicious activity appears.

Toobit groups its Bee-Safe framework into six areas:

• Proof of Reserves: Asset backing that users can verify through the exchange’s reserve system.

• Resilient infrastructure: Multi-cloud infrastructure intended to support platform availability and trading activity.

• Proactive safeguards: Multi-factor authentication, cold storage, and ongoing audits.

• Data security: Zero-trust architecture, encryption, and phishing-detection controls.

• Complete privacy: Data-protection measures that include zero-knowledge security and biometric controls.

• 24/7 active defense: Continuous monitoring and support intended to detect and respond to suspicious activity.

Toobit’s Bee-Safe framework covering Proof of Reserves, infrastructure resilience, account safeguards, data security, privacy, and active monitoring from Toobit, as of September 25, 2026.

These layers cover risks that a reserve ratio cannot measure. Proof of Reserves addresses asset backing, while authentication and phishing controls operate at the account level. Cold storage concerns custody, encryption protects sensitive data, and continuous monitoring is intended to identify abnormal activity before it spreads.

The framework shows which safeguards Toobit says it has in place, but the existence of a control does not prove that it will work perfectly in every incident. Its practical value depends on how the controls are implemented, tested, independently reviewed, and updated when new vulnerabilities emerge.

The balanced reading of Toobit’s disclosure

Toobit provides three visible transparency layers:

1. Asset-level reserve ratios for four major assets in the September report.

2. Merkle-based balance inclusion that users can verify against the relevant snapshot.

3. Published security controls covering account access, custody, infrastructure, testing, and incident preparation.

That combination gives users more to inspect than a general statement that assets are safe. The reserve announcement supplies fixed historical figures, the PoR dashboard provides a verification route, and the Security page identifies the controls Toobit says surround the reserves.

The limitations should remain visible beside those strengths. The September report covers four assets rather than every token available on the platform. PoR is a snapshot rather than continuous proof of solvency. Merkle inclusion does not reveal every corporate liability. Security controls can reduce risk without eliminating software, vendor, operational, insider, or signing-system failures.

The evidence therefore supports a qualified conclusion: Toobit offers a practical and user-verifiable reserve process for Bitcoin, Ether, Tether, and USD Coin, together with several publicly described account and custody controls. Readers should evaluate that evidence on its own scope rather than treating the Bitget breach as automatic proof that another exchange is safer.

What a comparison table cannot capture

A table can organize disclosures, but it cannot reproduce the experience of using an exchange during stress. Withdrawal execution, support response, incident communication, regional restrictions, liquidity, and account reviews can change faster than a reserve report.

Legal access also differs across countries. Two users opening the same global brand may interact with different operating entities, products, payment partners, custody arrangements, or contractual terms. A service available in one jurisdiction may be limited or unavailable in another.

Before selecting an exchange, readers should verify:

1. Whether the required asset and network are supported.

2. Current deposit, trading, conversion, and withdrawal fees.

3. Withdrawal limits and account-verification requirements.

4. The date and asset scope of the latest reserve disclosure.

5. Whether individual balance inclusion can be checked.

6. The exchange’s incident history and quality of its postmortems.

7. Available account protections and withdrawal controls.

8. Whether a small test withdrawal completes successfully.

9. How much capital actually needs to remain under exchange custody.

That final question is often overlooked. Choosing an exchange does not require keeping every asset there indefinitely. Traders can separate active trading capital from longer-term holdings and decide which risks they are equipped to manage. Centralized custody introduces platform and counterparty risk. Self-custody removes the exchange from the signing process but makes the owner responsible for private keys, backups, device security, inheritance planning, and irreversible mistakes.

The comparison is therefore a due-diligence starting point. It shows which claims can be checked and where the gaps remain. It does not convert any exchange into a risk-free custodian.

The real test is what happens next

The theft itself is no longer in doubt. The open questions are whether Bitget can produce a reproducible loss ledger, restore withdrawals safely, demonstrate the Protection Fund’s availability, and explain how a trusted system sent unauthorized transactions.

The DPRK hypothesis is worth following because two independent lines point in that direction: Bitget’s private infrastructure clues and Specter’s proposed connection between the XRP path and the AFX theft. Neither line is public enough to close the case. A strong postmortem should separate what the exchange knows from what it suspects, and a credible attribution should let outside investigators reproduce the chain.

Until then, the most honest description is simple. Bitget suffered a major multi-chain wallet incident involving around $351.6 million in affected funds. A backend or supply-chain failure is under investigation. DPRK-linked actors are suspected, not confirmed. Withdrawals, the final net loss, fund deployment, and the failed control remain the facts that can still change the story.

Do your own research (DYOR). This article is based on public incident disclosures and on-chain information available at the stated cutoff. It does not confirm the attacker’s identity or Bitget’s solvency, guarantee the recovery of funds, or recommend any particular exchange. Before making a financial decision, check the latest withdrawal status, reserve reports, availability in your region, fees, and custody risks.

How to buy crypto on Toobit

To buy crypto on Toobit, create or log in to your account, complete identity verification where required, and open the Buy Crypto page. Select the cryptocurrency you want to receive, choose an available payment method, and enter the purchase amount.

Before confirming the transaction, review the quoted exchange rate, payment fees, purchase limits, and final amount you will receive. Supported currencies, payment methods, account requirements, and product availability may vary by location.

Buy crypto on Toobit now.

Risk warning

Crypto assets are highly volatile and can lose substantial value. Trading and holding crypto come with risks, including market losses, security incidents, and disruptions that may affect access to funds. Proof of Reserves and protection funds can offer additional transparency and protection, but they do not eliminate risk. Leveraged trading carries additional risk and can lead to rapid losses or liquidation. Always consider your financial situation and risk tolerance before trading.