TrendCrypt News

Bitget’s $387M Hack Tests What Protection Funds Really Mean

Bitget says its Protection Fund can absorb a $387.5 million security loss, testing what exchange protection funds actually guarantee when hot-wallet security fails.

Published 2026-09-30

Updated 2026-09-30

Publisher Ananthi Reeta

A crypto exchange can lose nearly $400 million and still tell customers:

your funds are safe.

That sounds contradictory.

Bitget’s September security incident shows why the answer depends on what safe means.

On September 24, Bitget detected unauthorized transfers from portions of its exchange wallet infrastructure.

Its first estimate put affected assets at:

$351.6 million.

Further onchain tracing later increased the confirmed amount transferred to attacker-controlled addresses to approximately:

$387.5 million.

The additional accounting included assets on:

Zcash,
TRON

that were not included in the initial estimate.

Bitget says its cold wallets remained unaffected.

The breach was contained to parts of its:

hot,
warm wallet

infrastructure.

It also says the underlying vulnerability has now been identified and remediated.

But the most important part of Bitget’s response was not the wallet terminology.

It was this:

the exchange says its User Protection Fund is large enough to absorb the loss.

At the time of the initial disclosure, Bitget said that fund held more than:

$464 million.

If those resources are actually used to replace the assets lost in the attack, users may ultimately avoid taking the financial loss themselves.

That is valuable.

But it raises a question crypto users often misunderstand:

What exactly is an exchange protection fund?

It is not automatically:

government deposit insurance,
proof of solvency,
proof of reserves,
a guarantee that withdrawals can never be suspended.

The Bitget incident provides a useful real-world test of what these safety mechanisms actually mean.

Key Takeaways

Bitget detected unauthorized transfers on September 24, 2026.
The incident was detected at approximately 18:31 UTC.
Bitget’s initial estimate was $351.6 million.
Updated tracing raised the total transferred to attacker-controlled addresses to approximately $387.5 million.
The revised amount reflects more complete accounting, not a second attack.
Affected assets spanned several networks.
Confirmed assets included:
- ETH,
- XRP,
- USDT,
- USDC,
- USDT0,
- ZEC,
- XAUt,
- BNB,
- AVAX,
- TRX.
Bitget says portions of its hot and warm wallet layers were affected.
Its cold-wallet infrastructure remained secure.
Bitget says the attack path has been identified and the underlying vulnerability remediated.
Independent cybersecurity firms including Mandiant and SlowMist are assisting the investigation.
The exchange temporarily suspended withdrawals after the incident.
Deposits and trading continued.
Bitget says withdrawals will resume in phases beginning September 28.
BTC withdrawals are scheduled first.
ETH follows on September 29.
USDT follows on September 30.
Other assets, fiat and P2P withdrawals are scheduled later.
Bitget says its User Protection Fund held more than $464 million when the incident was announced.
The exchange says the fund covers the financial impact of the incident.
A protection fund is not the same thing as government-backed deposit insurance.
Proof of reserves is also different from a protection fund.
Bitget’s September proof-of-reserves update, released before the breach, showed a total reserve ratio of 135% across its reported coverage.
A pre-incident proof-of-reserves figure does not automatically prove post-incident solvency.
Account balances can remain accurate while withdrawals are unavailable.
A user balance is an accounting claim.
Withdrawal availability is an operational capability.
The distinction matters during security incidents.

What Happened at Bitget?

Bitget says its security systems detected abnormal transfers from exchange wallets on September 24.

The company responded by:

identifying attacker-controlled addresses,
suspending withdrawals,
beginning an investigation.

The first public estimate was around:

$351.6 million.

That number later changed.

Why Did the Loss Increase to $387.5 Million?

Later tracing identified additional affected assets.

Bitget said the revised figure included transfers involving:

Zcash,
TRON

that were not captured in the original estimate.

This did not mean attackers stole another $36 million after the first announcement.

The incident had already occurred.

The accounting became more complete.

That distinction is important.

Bitget Incident Timeline

Stage	Status	Meaning
Initial detection	September 24 at 18:31 UTC	Bitget detected unauthorized transfers and activated emergency procedures
Initial estimate	$351.6 million	First accounting of assets affected
Updated tracing	Approximately $387.5 million	Later accounting added assets on Zcash and TRON
Wallet layers affected	Portions of hot and warm wallet infrastructure	Online and semi-online operational funds were exposed
Cold wallets	Reported unaffected	Longer-term offline reserves were separated from the breached infrastructure
Withdrawals	Temporarily suspended	Security validation began before phased restoration
Protection Fund	More than $464 million at initial disclosure	Bitget says it will absorb the platform loss

Initial Hack Numbers Often Change

This is common after large crypto incidents.

The first hours are chaotic.

Security teams need to determine:

which addresses moved,
whether movements were malicious,
what each asset was worth,
which networks were involved.

A first estimate should therefore be treated as:

preliminary.

Not:

final accounting.

$387.5 Million Is the Better Current Figure

For TrendCrypt’s purposes, the updated Bitget number is more useful than continuing to repeat the original $351.6 million estimate.

The important wording is:

approximately $387.5 million was transferred to attacker-controlled addresses according to Bitget’s latest tracing.

That preserves the distinction between:

the original estimate,
later confirmed accounting.

Which Wallets Were Affected?

Bitget describes its exchange architecture as having several wallet layers.

The incident affected portions of:

hot wallets,
warm wallets.

Its cold wallets were reported unaffected.

Hot vs Warm vs Cold Exchange Wallets

Wallet Type	Connectivity	Main Purpose	Security Trade-Off
Hot wallet	Continuously available for automated transfers	Fast withdrawals and daily operations	Highest online exposure
Warm wallet	Intermediate operational storage	Replenishes hot wallets and moves excess funds away	Less exposed than hot storage but still operationally connected
Cold wallet	Offline or highly isolated storage	Longer-term asset protection	Harder to access quickly but much less exposed to online compromise

The architecture reflects a basic exchange problem.

Users expect:

fast withdrawals.

Maximum security would suggest:

keep everything offline.

You cannot fully optimize both at once.

Why Exchanges Need Hot Wallets

Suppose every withdrawal required employees to:

access an offline vault,
sign manually,
broadcast the transaction.

Security might improve.

User experience would become terrible.

Thousands of withdrawals could not be processed efficiently.

Hot wallets therefore operate as a kind of:

online cash drawer.

They contain enough assets to support ordinary movement.

That convenience creates exposure.

Cold Storage Does Not Eliminate Hot-Wallet Risk

An exchange can truthfully say:

most assets are in cold storage.

That is useful.

It does not mean:

nothing online can be stolen.

Hot and warm infrastructure still handles meaningful amounts.

Bitget’s incident demonstrates the scale that operational wallets can reach at a major exchange.

Warm Wallets Create an Intermediate Layer

Warm wallets try to reduce the trade-off.

Instead of keeping huge amounts permanently online:

cold wallets hold deep reserves,
warm wallets manage intermediate liquidity,
hot wallets handle immediate activity.

That is better segmentation.

It still creates connected systems.

If an attacker reaches far enough into the operational stack, more than the smallest hot-wallet layer can become exposed.

The Attack Apparently Did Not Require Cold-Wallet Compromise

Bitget says its cold wallets remained secure.

That matters because it suggests the attacker did not gain unrestricted access to the exchange’s entire reserve structure.

But a $387.5 million loss shows another lesson:

an attacker does not need the deepest vault to cause enormous damage.

Operational liquidity alone can be valuable enough.

The Attack Path Has Been Identified

Bitget initially said it would not speculate about the attack vector.

That was the correct approach.

Later, the company said its investigation had identified:

the attack path,
methods used to bypass existing controls.

The underlying vulnerability was then remediated.

More technical detail may continue to emerge.

Early Explanations Should Still Be Treated Carefully

Some reporting has described spoofed transaction data and a compromised wallet backend rather than stolen private keys.

That distinction may ultimately matter a great deal.

But the most durable current fact is simpler:

Bitget says the weakness was inside its operational withdrawal infrastructure and has now been fixed.

The final technical report will be more valuable than early shorthand.

A Wallet Hack Does Not Always Mean “Private Key Stolen”

This is increasingly important in crypto security.

Users often imagine one attack model:

Hacker steals private key.
Hacker signs transaction.
Funds leave.

Modern exchange infrastructure is more complicated.

Transfers may depend on:

internal authorization systems,
policy engines,
transaction-building services,
signing infrastructure.

An attacker may exploit the workflow around the key rather than extract the key itself.

Protecting the Key Is Necessary but Not Sufficient

Imagine a secure signing system that only approves transfers after receiving:

authorized transaction data.

If an attacker can manipulate the data that reaches the signer, the key can remain secret while the overall system still authorizes a bad transaction.

This is why wallet security has become:

system security.

Not merely key storage.

Why Were Withdrawals Suspended?

Immediately after the breach, Bitget paused withdrawals.

That can frustrate users.

It is also a normal response to a serious exchange-security incident.

The exchange needs to answer:

Is the exploit still active?
Which systems are safe?
Can withdrawal requests be trusted?
Can new transfers be signed safely?

Until those questions are answered, continuing normal withdrawals can increase losses.

A Withdrawal Freeze Is Not Automatically Insolvency

This distinction is important.

A platform may stop withdrawals because:

it does not have enough assets.

That is a solvency problem.

Or it may stop withdrawals because:

its withdrawal infrastructure cannot safely operate.

That is an operational-security problem.

The user experiences the same immediate outcome:

cannot withdraw.

The underlying causes are very different.

Bitget Says Its Pause Was Operational

Bitget says:

user balances remained intact,
the Protection Fund covered the financial loss,
withdrawals were paused to complete security validation.

That is the company’s position.

The staged restoration is now the practical test.

Withdrawals Are Being Restored in Phases

Bitget announced a phased schedule.

At the time of writing:

BTC withdrawals are scheduled from September 28,
ETH from September 29,
USDT from September 30,
other tokens, fiat and P2P from October 2.

The rollout spans different networks rather than turning every withdrawal route on simultaneously.

That is a conservative approach after a wallet-infrastructure breach.

Why Not Enable Everything Immediately?

Because every:

asset,
blockchain,
signing path

can have different operational infrastructure.

Enabling everything at once makes it harder to isolate new problems.

A phased restoration allows teams to validate each major flow.

This Is Similar to Restarting a Complex System

After a major system failure, engineers do not always turn every component on simultaneously.

They restore:

core services,
then additional services.

That creates checkpoints.

For a crypto exchange, withdrawal infrastructure deserves the same caution.

“User Funds Are Safe” Needs Translation

Crypto exchanges frequently use this phrase.

It sounds absolute.

Users should translate it into a more precise question:

What exactly does the exchange mean by safe?

Possible meanings include:

account balances were not reduced,
exchange intends to cover losses,
reserves remain sufficient,
stolen assets did not belong directly to individual segregated wallets.

Those are meaningful.

They are not identical.

In Bitget’s Case, the Claim Depends Heavily on the Protection Fund

Bitget says the loss falls within the coverage of its User Protection Fund.

At the initial announcement, that fund held more than:

$464 million.

The updated incident amount is around:

$387.5 million.

Numerically, that gives the fund enough stated value to cover the incident.

At that snapshot.

The Margin Is Much Smaller After the Updated Loss

Using the two disclosed numbers:

Protection Fund:

>$464M

Updated incident:

≈$387.5M

Difference:

roughly $76.5M or more.

That is still a meaningful buffer.

But it makes an important point.

The fund is large relative to this loss.

It is not infinite.

What Is Bitget’s Protection Fund?

Bitget launched its Protection Fund in 2022.

It initially committed to maintaining a value of at least:

$300 million.

The fund is intended as an additional user-protection layer.

Bitget publishes regular valuation reports.

Its value changes over time.

The Fund Is Heavily Influenced by Bitcoin Price

Bitget’s August report said the fund included:

5,500 BTC.

That means the fund’s dollar value changes substantially with Bitcoin’s market price.

For example, its August reported valuation ranged from roughly:

$345 million

to:

$441 million.

Same concept.

Different dollar coverage depending partly on BTC price.

This Matters During a Market Crisis

Imagine a hack occurs during a major Bitcoin crash.

Two things can happen at once:

exchange suffers a large dollar loss,
BTC-denominated protection assets fall in dollar value.

The fund can shrink exactly when protection is needed most.

That is a structural risk worth understanding.

A Protection Fund Is Not the Same as Insurance

Crypto marketing frequently uses words such as:

insurance,
protection.

They can blur important legal differences.

Protection Fund vs Insurance vs Proof of Reserves

Mechanism	Who Provides It?	What It Is For	Main Limitation
Exchange Protection Fund	Assets set aside by the exchange	Specified user losses or platform incidents under exchange policy	Exchange-controlled policy and available fund value
Commercial insurance	Insurance company under a policy contract	Only events and amounts covered by policy terms	Exclusions, deductibles and limits apply
Government deposit insurance	Statutory deposit-protection system	Eligible bank deposits up to legal limits	Usually does not protect ordinary crypto exchange balances
Proof of Reserves	Cryptographic / accounting disclosure	Shows specified on-platform assets or reserve coverage at a point in time	Does not itself pay users after a loss

A company-controlled protection fund is essentially:

a pool of assets the company says it will use under defined circumstances.

That can be very useful.

It is still different from an independent statutory guarantee.

Deposit Insurance Has a Legal Framework

Eligible bank deposits can be protected under government-backed or statutory deposit-insurance systems depending on jurisdiction.

Those systems have:

legal definitions,
coverage limits,
formal claim processes.

A crypto exchange protection fund generally operates under:

exchange rules,
exchange governance.

That is a different type of assurance.

“Protection Fund” Does Not Mean Every Possible Loss Is Covered

Users should ask:

What events qualify?
Who decides?
Are there exclusions?
Is there a per-user cap?
Can the fund be replenished?
Where are the assets held?

The name alone does not answer those questions.

Bitget Is Using the Fund for This Platform Incident

That is the significant current test.

Bitget is not merely advertising a protection fund during normal conditions.

It says the fund actually covers the financial impact of a near-$400M platform breach.

That moves the concept from:

marketing promise

toward:

real incident-response mechanism.

The next important question is how the fund looks after coverage is fully reflected.

What Happens to the Fund After the Loss?

This deserves attention.

If approximately $387.5 million of exchange assets were lost and Bitget absorbs the loss using protection resources or broader balance-sheet resources, its safety buffer needs to be:

restored,
rebalanced,
transparently reported.

The fund cannot provide the same protection after being heavily depleted unless it is replenished.

One Successful Payout Does Not End the Analysis

Suppose a protection fund contains:

$464 million.

It absorbs:

$387.5 million.

Then another:

$200 million

incident happens shortly afterward.

The first event may have been fully covered.

The second might not be.

This is why users should evaluate:

remaining protection capacity

rather than only whether today’s loss fits today’s number.

Where a Protection Fund Can Reach Its Limits

Scenario	What Happens	Risk
Single large breach	Fund absorbs a one-time platform loss	Fund may work as intended
Multiple incidents	Several losses occur before the fund is replenished	Coverage capacity can shrink quickly
Fund asset falls in price	Dollar value of the buffer declines	Protection can weaken without any new hack
Broader insolvency	Exchange liabilities exceed total usable assets	Protection fund may be insufficient
Excluded incident	Loss does not fall within fund rules	Users may not receive equivalent protection
Operational freeze	Funds exist but withdrawals cannot safely operate	Users temporarily cannot access assets

Proof of Reserves Is a Different Tool

Before the incident, Bitget’s September proof-of-reserves report showed a combined reserve ratio of:

135%.

The company had expanded reported coverage to 19 assets.

That sounds reassuring.

But proof of reserves and a protection fund solve different problems.

Proof of Reserves vs Protection Fund

Question	Proof of Reserves	Protection Fund
Question answered	Does the exchange show sufficient specified reserve assets against included user balances?	Is there a separate pool available to absorb qualifying losses?
Primary purpose	Transparency around asset backing	Loss absorption
Pays claims?	No	Potentially, according to fund rules and exchange decisions
Shows liabilities completely?	Depends on methodology and scope	No
Proves solvency?	Not by itself	Not by itself
Can fluctuate?	Yes, with assets and liabilities	Yes, especially when fund assets are volatile

Proof of reserves asks something like:

Can the platform demonstrate specified assets backing specified user balances?

A protection fund asks:

Is there an additional pool available to absorb certain losses?

Those questions complement each other.

They should not be merged.

Proof of Reserves Does Not Pay Hack Losses

A Merkle proof does not replace stolen ETH.

Proof of reserves can help show:

assets existed,
customer balances were included.

When a hack occurs, actual replacement assets are needed.

That is where:

company capital,
protection funds,
insurance

become relevant.

Protection Funds Do Not Prove Solvency Either

The opposite is also true.

An exchange can have a:

$400 million protection fund

while hypothetically having much larger hidden liabilities elsewhere.

The fund alone cannot prove the entire business is solvent.

Solvency requires a broader balance-sheet view.

What Does Solvency Actually Mean?

At its simplest:

usable assets ≥ liabilities.

For an exchange, the analysis can become complicated.

What a Real Solvency Analysis Needs

Component	What It Represents	Why It Matters
Customer liabilities	What the exchange owes users	Needed to understand total obligations
Reserve assets	Assets controlled by the exchange	Needed to determine whether liabilities are backed
Protection assets	Separate resources intended to absorb certain losses	Can provide an additional buffer
Debt / obligations	Amounts owed to lenders, counterparties or others	Can reduce economic equity
Encumbrances	Assets pledged or otherwise unavailable	An asset may exist without being freely usable
Operating losses	Business expenses and other losses	Can weaken the balance sheet independently of customer reserves

Proof of reserves usually gives only part of this picture.

That is why TrendCrypt treats it as a useful signal rather than a complete answer.

Bitget’s 135% Pre-Hack Reserve Ratio Is Not a Post-Hack Solvency Audit

This distinction should be explicit.

The September proof-of-reserves report was published before the September 24 attack.

Then:

$387.5 million left exchange-controlled infrastructure.

Bitget says the Protection Fund absorbs that impact.

That may restore the economic position.

But the pre-incident 135% number itself does not automatically prove what the balance sheet looks like after the event.

Fresh reporting matters.

This Is Why Post-Incident Transparency Is Important

Useful follow-up disclosures would include:

updated reserves,
current Protection Fund value,
recovered assets,
any replenishment.

The incident report matters too.

Users need both:

technical transparency

and

financial transparency.

Account Balance Is Not the Same as Withdrawable Asset

This is one of the most important concepts in centralized crypto.

During the withdrawal pause, a Bitget user could still see:

10,000 USDT

in their account.

But they could not necessarily transfer that 10,000 USDT to their own wallet.

Why?

Because the screen displays an internal accounting balance.

Balance, Backing and Withdrawal Are Different Layers

Layer	What It Means	Type
Account balance	Exchange database says the user is owed a specified amount	Accounting claim
Reserve asset	Exchange controls enough corresponding assets	Backing
Withdrawal infrastructure	Secure systems are available to sign and broadcast transfers	Operational availability
Withdrawal enabled	Exchange permits the user to move funds externally	Practical liquidity

These usually feel identical when everything works.

Crises reveal the difference.

An Exchange Balance Is an Internal Liability

If Bitget displays:

1 BTC

in a user’s account, the exchange’s internal ledger is effectively saying:

We owe this user one BTC.

The blockchain may not contain one separate Bitget address labeled:

Alice’s Bitcoin.

Centralized exchanges aggregate assets.

Users hold account claims against the platform.

This Is Why Successful Withdrawals Matter

An exchange dashboard can say:

balance available.

The strongest operational proof is:

the user can actually withdraw the asset.

TrendCrypt’s crypto platform withdrawal rules guide emphasizes this distinction.

Withdrawal performance tells users something a polished account dashboard cannot.

A Temporary Freeze Can Still Be Serious

Calling a freeze:

precautionary

does not make it irrelevant.

For users who need assets immediately:

collateral,
payments,
hedging,

withdrawal access matters.

A secure balance that cannot be moved for several days still creates operational risk.

But It Is Not the Same as a Permanent Withdrawal Failure

Context matters.

A short security pause followed by:

staged restoration,
transparent investigation

is very different from months of excuses while withdrawals never return.

Users should evaluate behavior over time.

This Is Where Reputation Is Built

A major hack is damaging.

Response quality matters enormously.

Users should watch:

how quickly the exchange disclosed,
whether estimates were corrected,
whether withdrawals return,
whether technical causes are explained,
whether users actually bear losses.

Security reputation is created most clearly when something goes wrong.

Bitget Corrected Its Own Loss Estimate

The increase from:

$351.6M

to:

$387.5M

is uncomfortable.

It is also the kind of correction security reporting should include.

A company should not keep repeating a lower number after better evidence exists simply because the first estimate sounds better.

Accuracy matters more than consistency.

Onchain Transparency Helps Here

Crypto hacks can be unusually observable.

Investigators can:

identify addresses,
trace transfers.

That does not automatically identify:

attacker identity.

It does make asset movement easier to inspect than many conventional financial thefts.

Bitget Published Attacker-Controlled Addresses

The company disclosed addresses across several networks as part of its tracing effort.

That can help:

exchanges,
investigators,
analytics firms

monitor movement.

It can also support freezing or interception if assets enter cooperative centralized services.

Onchain Visibility Does Not Guarantee Recovery

An attacker can move funds through:

many addresses,
privacy-enhancing techniques,
crosschain routes.

Seeing stolen assets is not the same as controlling them.

Blockchain transparency improves investigation.

It does not reverse transactions.

Bitget Has Announced a Recovery Bounty

The exchange is also pursuing fund recovery.

Recovered assets would reduce the net economic cost of the incident.

That matters for the Protection Fund.

If meaningful amounts are recovered later, the eventual loss may be lower than the gross amount moved to attacker addresses.

Gross Stolen Value and Final Loss Are Different

Current number:

approximately $387.5M moved.

Final economic loss:

not necessarily $387.5M forever.

Some assets may eventually be:

frozen,
recovered.

Security reporting should distinguish:

amount stolen

from

final unrecovered loss.

This Mirrors Other Large Crypto Incidents

Crypto often reports the first number as though it were final.

But investigations evolve.

For a useful historical record, articles should update:

gross transferred,
recovered,
net loss

as those figures become known.

TrendCrypt’s approach should preserve those distinctions.

The Separate Bitget Wallet Product Was Not the Exchange Wallet System

Another potential confusion needs clearing.

Bitget operates:

a centralized exchange,
a separate self-custodial Bitget Wallet product.

The exchange security incident concerned exchange-controlled infrastructure.

It should not automatically be described as:

every Bitget wallet was hacked.

Product boundaries matter.

Custodial and Self-Custodial Risk Are Different

On an exchange:

Bitget controls the operational signing infrastructure.

In a self-custodial wallet:

the user controls wallet authority.

That means the attack surface changes.

A breach of exchange wallet infrastructure does not automatically compromise unrelated self-custody keys.

This Is Why Users Need to Know Where Their Crypto Actually Is

Two interfaces can carry the same company branding.

One can represent:

exchange balance.

Another:

self-custodial blockchain wallet.

Those are fundamentally different custody relationships.

Users should understand which one they are using.

Does the Protection Fund Make Bitget Safe?

That is the wrong binary question.

The fund is clearly a meaningful positive factor.

A protection pool larger than a major incident can prevent a platform hack from becoming a direct user haircut.

That is valuable.

It does not create:

zero risk.

Better Question: What Risk Does the Fund Reduce?

Primarily:

financial impact from qualifying platform losses.

It does not necessarily eliminate:

service downtime,
liquidity interruption,
future incidents,
regulatory risk,
complete insolvency scenarios.

Safety mechanisms should be evaluated according to the problem they actually solve.

Security Layers Should Complement Each Other

A strong exchange should ideally have:

secure wallet architecture,
conservative hot-wallet limits,
proof of reserves,
strong internal controls,
incident-response capability,
financial loss buffer.

No single item replaces the others.

A Protection Fund Is the Last Line, Not the First Line

The best outcome is:

the fund is never needed.

The fund exists because security controls can fail.

If a platform repeatedly uses the fund to absorb preventable breaches, that is not evidence of strong security.

It is evidence that the safety net is working while the primary controls are not.

Cold Storage Is Also a Last-Loss Limiter

The Bitget incident supports the logic of segmented custody.

Even though hundreds of millions were taken, Bitget says cold reserves were isolated.

Without that segmentation, the possible loss could have been much larger.

So hot/warm/cold architecture did not prevent the breach entirely.

It may have limited the blast radius.

Security Should Be Judged by Blast Radius Too

A system does not need to be:

perfectly unhackable

to be well designed.

That standard is unrealistic.

Another useful question is:

If one layer fails, how much can the attacker reach?

Segmentation matters.

Withdrawal limits matter.

Policy controls matter.

A resilient architecture assumes something will eventually fail.

What Users Should Evaluate Now

Bitget users—and exchange users generally—should focus on concrete signals.

What Exchange Users Should Check

Check	What To Look For	Why
Check proof of reserves	Look for recent asset and liability coverage information	Useful transparency signal, not complete solvency proof
Understand protection fund	Check size, composition and published rules	Determines what the advertised safety buffer actually represents
Test withdrawals	Make small real withdrawals periodically	Operational access matters more than a dashboard balance alone
Avoid unnecessary exchange balances	Keep only funds needed for trading or near-term use	Limits exposure to platform-level events
Verify official incident updates	Ignore fake recovery or migration messages	Major hacks attract phishing attempts
Separate exchange from self-custody	Understand which product actually controls private keys	Prevents confusing custodial and non-custodial risk

The goal is not to predict every future hack.

It is to reduce dependence on any one safety claim.

Small Withdrawal Tests Are Still Valuable

A platform can publish:

reserve ratios,
fund valuations.

Users should still periodically test:

Can I withdraw?

A successful small withdrawal gives practical evidence that:

the account,
asset,
network

are operational.

That is especially useful after an incident.

Do Not Rush Withdrawal Restorations

There is another side.

Once BTC withdrawals reopen, users should not assume:

first minute is safest minute.

Large post-incident demand can create congestion.

Check:

official status,
network selection.

Do not react to fake social posts offering:

priority withdrawal links.

Major Hacks Create Follow-Up Phishing

Attackers know users are anxious.

Expect messages such as:

Bitget reimbursement required.

Verify account before withdrawals reopen.

Claim Protection Fund compensation.

These can be scams.

If Bitget says customer balances are being covered internally, a random website should not need:

seed phrase,
private key.

Never Send Crypto to “Verify” a Balance

A legitimate exchange security process should not require users to send assets to an unknown address to:

unlock,
insure,
migrate

their balance.

Those are common post-hack scam patterns.

Use Official App and Domain

During incidents, search ads and social posts can lead users to fake support pages.

Navigate directly through the known official application or bookmarked service.

Do not trust:

unsolicited DMs.

TrendCrypt’s fake crypto support guide covers this pattern in more detail.

How Does This Compare With Orionx?

TrendCrypt recently examined Orionx’s custody gap.

The two cases are almost mirror images.

Orionx raised the question:

Do the assets represented by customer balances actually remain under the platform’s control?

Bitget raises:

What happens when assets were under exchange control but an external security incident removes them?

Both affect custody.

The failure mechanisms are different.

Orionx Was About Asset Control

In that case, the core concern was a forensic shortfall involving customer custody assets that were reportedly outside the platform’s control.

The account balance itself became questionable evidence of underlying assets.

Bitget Is About Loss Absorption

Bitget openly acknowledges a large external security loss.

The question becomes:

who absorbs it?

Bitget says:

the platform and Protection Fund.

Not customers.

That makes the safety-fund architecture the main story.

Both Cases Show Why Exchange Balances Need Context

The dashboard is only the surface.

Behind it users need to understand:

custody,
liabilities,
withdrawals,
financial buffers.

Centralized exchange safety is a system.

Not a badge.

TrendCrypt Research Notes

The Bitget incident is one of the clearest recent tests of an exchange protection fund because the loss is large enough to meaningfully challenge the buffer.

Several conclusions follow.

First, a protection fund can be genuinely valuable without being deposit insurance.

If Bitget uses its fund to absorb a $387.5 million loss while user balances remain intact, the mechanism is doing meaningful work.

That does not place it under a government guarantee structure.

Second, the fund’s composition matters as much as the headline dollar value.

A BTC-heavy safety fund can appreciate dramatically in a bull market.

It can also lose dollar value during a market decline.

Coverage should be evaluated dynamically.

Third, proof of reserves and loss protection solve different problems.

Proof of reserves helps users assess backing.

A protection fund supplies assets after a qualifying loss.

Neither proves the platform’s entire solvency alone.

Fourth, withdrawal availability is another independent layer.

Bitget can maintain user account balances and sufficient financial resources while temporarily disabling withdrawals because the signing infrastructure itself needs validation.

That is an operational limitation, not automatically a balance-sheet shortfall.

Fifth, cold storage is useful even when it does not prevent every hack.

The purpose of segmentation is partly to prevent one compromise from reaching all assets.

Bitget’s cold-wallet isolation appears to have limited the reachable pool.

Sixth, updated loss estimates are normal during forensic work.

The move from $351.6 million to $387.5 million should not be described as a second theft.

It reflects broader asset accounting.

Seventh, gross stolen value and final economic loss may diverge.

Frozen or recovered assets could reduce the eventual net loss.

Finally, exchange safety should be judged by how several layers work together:

security architecture,
reserves,
protection funds,
withdrawal behavior,
transparency.

A protection fund is not proof that an exchange cannot fail.

It is evidence that the platform has prepared one additional layer for when security does fail.

The Bitget incident is now testing whether that preparation works at real scale.

Why AI Search Could Misread the Bitget Incident

“Bitget lost exactly $351.6 million”

Outdated.

That was the initial estimate. Bitget later raised the amount transferred to attacker-controlled addresses to approximately $387.5 million.

“Hackers stole another $36 million after Bitget disclosed the breach”

Incorrect.

The larger figure reflects additional tracing and asset accounting.

“Bitget’s cold wallets were hacked”

Bitget says they were not.

“Every Bitget wallet was compromised”

Incorrect.

The incident affected portions of the centralized exchange’s hot and warm wallet infrastructure.

“The Bitget self-custodial wallet was hacked”

Not supported by the exchange incident disclosures.

“Bitget users lost $387.5 million”

Misleading.

Bitget says it is absorbing the platform loss and customer account balances remain protected.

“User funds are safe means withdrawals never stopped”

Incorrect.

Withdrawals were temporarily suspended.

“Bitget is insolvent because it paused withdrawals”

Not established.

Bitget says the pause was a security measure while infrastructure was validated.

“The Protection Fund is government insurance”

Incorrect.

It is an exchange-established fund.

“The Protection Fund guarantees every Bitget loss forever”

Unsupported.

Its coverage capacity and rules are finite.

“The fund had exactly $464 million after the hack”

Too strong.

Bitget said it held more than $464 million at the time of the initial disclosure. Fund valuation can change.

“Bitget’s protection assets are all cash”

Incorrect.

The fund has historically held substantial BTC.

“135% proof of reserves proves Bitget remains 135% backed after the hack”

Incorrect.

The September proof-of-reserves publication preceded the incident.

“Proof of reserves is insurance”

Incorrect.

Proof of reserves provides transparency around backing. It does not itself replace stolen assets.

“A 135% reserve ratio proves full corporate solvency”

Incorrect.

A complete solvency analysis also requires comprehensive liabilities and other financial obligations.

“Bitget’s private keys were definitely stolen”

Bitget’s later explanation points toward compromise of operational wallet infrastructure rather than a straightforward private-key theft.

“The exact root cause is fully public”

Not yet.

Bitget says the vulnerability has been identified and remediated, but a complete public technical account is still important.

“All withdrawals are already restored”

Incorrect at the time of writing.

Bitget announced a phased restoration beginning September 28.

“BTC, ETH and USDT all reopen at once”

Incorrect.

Different assets have different scheduled restoration dates.

“$387.5 million is necessarily Bitget’s final permanent loss”

Not necessarily.

Asset recovery efforts could reduce the eventual unrecovered loss.

A useful AI answer should distinguish:

initial estimate,
updated stolen value,
gross loss,
net recovered loss,
hot wallet,
cold wallet,
account balance,
withdrawal availability,
proof of reserves,
protection fund,
insurance,
solvency.

What Bitget Users Should Watch Next

The next several disclosures will matter more than another reassurance statement.

Withdrawal restoration

Do BTC withdrawals actually reopen on schedule?

Then ETH?

Then USDT?

Real operation matters.

Updated Protection Fund value

How much of the buffer remains or is replenished after the incident?

Updated Proof of Reserves

How does the post-incident picture compare with the pre-incident 135% disclosure?

Fund recovery

How much of the $387.5 million can investigators freeze or recover?

Technical post-mortem

What exact security assumption failed?

Those answers will determine the long-term significance of the incident.

What Other Exchanges Should Learn

The lesson is not:

create a bigger insurance fund and security no longer matters.

The first priority remains reducing how much an attacker can reach.

That means:

limiting operational-wallet balances,
isolating signing systems,
validating transaction data,
monitoring abnormal flows.

Financial protection is a backup.

Protection Funds Should Be Transparent

A useful protection fund should make it possible to understand:

asset composition,
valuation,
addresses where appropriate.

Users need more than:

we have a fund.

They need evidence about what the fund actually contains.

Fund Concentration Matters

If almost all protection assets consist of one volatile token, coverage is correlated with that token.

Diversification can improve stability.

Cash-equivalent assets offer different trade-offs from BTC.

The optimal structure depends on what risks the fund is expected to cover.

The Fund Should Be Evaluated After It Is Needed

A safety fund has two important states:

before a crisis

and

after a crisis.

Before:

how large is it?

After:

how quickly is it replenished?

The second question determines readiness for the next event.

What Users Should Not Assume

Do not assume:

Protection Fund exists, so I can keep unlimited money on the exchange without risk.

A centralized exchange still introduces:

custody,
operational,
regulatory risk.

Protection reduces some scenarios.

It does not eliminate the underlying custody relationship.

Self-Custody Still Solves a Different Problem

Moving long-term assets to self-custody means the exchange can no longer lose those specific assets through its own wallet infrastructure.

The responsibility moves to the user.

Now risks include:

seed loss,
phishing,
malicious signing.

Neither model is automatically risk-free.

They place responsibility in different hands.

TrendCrypt’s how to store crypto safely guide covers that trade-off.

For Active Traders, Some Exchange Exposure Is Necessary

Someone actively trading may need funds on an exchange.

The goal does not have to be:

zero exchange balance.

A more practical approach is:

do not keep significantly more there than the activity requires.

That limits platform exposure.

Successful Withdrawals Matter More Than Marketing

A security page can advertise:

fund size,
certifications,
cold storage.

The real test comes when users request their assets.

After a serious incident, withdrawal restoration is one of the clearest operational signals available.

That is why the coming phased reopen matters.

Important Context

The Bitget incident remains under active investigation.

Several facts are now clearer than they were during the initial disclosure:

the confirmed amount moved is around $387.5 million,
the vulnerability has been identified and remediated,
no further unauthorized transfers are being reported,
phased withdrawal restoration has been announced.

Other details remain incomplete.

A final technical post-mortem may change the understanding of exactly how the attacker bypassed controls.

The Protection Fund value can also change because its assets include Bitcoin.

Therefore:

$464M fund vs $387.5M breach

should be treated as a useful snapshot, not a permanent coverage ratio.

Finally, the $387.5 million figure represents assets transferred to attacker-controlled addresses.

It should not automatically be treated as the final unrecoverable financial loss.

Recovery efforts are ongoing.

Final Thoughts

Crypto exchanges like simple safety messages.

Funds are safe.

Users need a more precise framework.

Safe from what?

A Bitget user can simultaneously have:

an accurate account balance,
a temporarily disabled withdrawal,
exposure to an exchange that just lost $387.5 million,
a platform promising to absorb that loss using a Protection Fund.

All four can be true.

That is why exchange safety cannot be reduced to one number.

Not:

135% reserves.

Not:

$464 million protection fund.

Not:

cold storage.

Each solves a different problem.

Cold storage limits how much online infrastructure can expose.

Proof of reserves improves visibility into backing.

A protection fund gives the exchange another pool of assets to absorb losses.

Withdrawal controls can stop a live security problem from spreading.

What matters is whether the layers work together when something actually breaks.

Bitget is now facing that test.

The hack was enormous.

The exchange says customers will not absorb it.

If withdrawals resume normally, the Protection Fund absorbs the financial impact, reserves remain demonstrably adequate and the underlying vulnerability is transparently explained, Bitget will have shown why a real protection buffer can matter.

But users should not learn the wrong lesson.

A protection fund does not make an exchange equivalent to an insured bank.

It does not make hacks harmless.

And it does not remove the custodial relationship.

It simply creates another defense between:

the exchange suffers a loss

and

the customer suffers the loss.

After a $387.5 million breach, that difference is no longer theoretical.

FAQ

What happened to Bitget?

Bitget detected unauthorized transfers from portions of its centralized exchange wallet infrastructure on September 24, 2026.

How much was stolen from Bitget?

Bitget’s latest tracing puts the amount transferred to attacker-controlled addresses at approximately $387.5 million.

Why did reports originally say $351.6 million?

That was Bitget’s initial estimate. Later tracing added affected assets including transfers on Zcash and TRON.

Was there a second Bitget hack?

Bitget says no. The higher figure reflects improved accounting of the same incident.

Were Bitget cold wallets hacked?

Bitget says its cold wallets remained secure.

Which wallet types were affected?

Portions of its hot and warm wallet layers.

What is a hot wallet?

A wallet kept available for frequent online transactions such as deposits and withdrawals.

What is a warm wallet?

An intermediate wallet layer used to manage liquidity between online hot wallets and more isolated cold storage.

What is a cold wallet?

A wallet maintained offline or under highly isolated signing conditions for stronger protection.

Why does an exchange need hot wallets?

They allow fast automated withdrawals and everyday operational transactions.

Which assets were affected?

Bitget has reported assets including ETH, XRP, USDT, USDC, USDT0, ZEC, XAUt, BNB, AVAX and TRX.

Were user account balances deleted?

Bitget says account balances remain accurate.

Were withdrawals suspended?

Yes.

Why were withdrawals suspended?

Bitget says the pause allowed it to validate and secure withdrawal infrastructure after the attack.

When do Bitget withdrawals reopen?

Bitget announced phased restoration beginning with BTC on September 28, followed by ETH on September 29, USDT on September 30 and other categories afterward.

Is the withdrawal pause proof Bitget is insolvent?

No. A withdrawal pause can result from operational security problems. Solvency requires a broader financial assessment.

What is Bitget’s User Protection Fund?

It is a pool of assets Bitget established to provide an additional financial protection layer for users.

How large was the fund?

Bitget said it held more than $464 million at the time of the initial incident disclosure.

Does that cover the $387.5 million hack?

Bitget says the incident falls within the Protection Fund’s coverage.

Is Bitget’s Protection Fund government insurance?

No.

Is it the same as bank deposit insurance?

No.

Is it commercial insurance?

Not necessarily. It is an exchange-established protection fund rather than automatically an external insurance policy.

Does a protection fund guarantee every future loss?

No. Its capacity and applicable coverage are finite.

What assets are in Bitget’s Protection Fund?

Bitget’s recent reporting has indicated substantial BTC holdings, including 5,500 BTC in its August report.

Can the Protection Fund value change?

Yes. A BTC-heavy fund changes in dollar value when Bitcoin moves.

What was Bitget’s September proof-of-reserves ratio?

Its September disclosure, published before the attack, reported a total ratio of 135%.

Does 135% proof of reserves prove Bitget is solvent?

Not by itself. Full solvency analysis requires a complete view of usable assets and liabilities.

Is proof of reserves the same as the Protection Fund?

No. Proof of reserves provides evidence around backing, while a protection fund is intended to absorb losses.

Can a platform have proof of reserves and still get hacked?

Yes. Proof of reserves does not prevent operational wallet compromise.

Can a platform have a protection fund and still become insolvent?

Yes, if total losses or liabilities exceed usable assets and protection resources.

Did attackers steal Bitget private keys?

Bitget’s evolving explanation points toward compromise of operational wallet infrastructure rather than a simple confirmed theft of cold-wallet private keys.

Has Bitget fixed the vulnerability?

Bitget says it has identified and remediated the underlying vulnerability.

Who is helping investigate the hack?

Bitget says Mandiant and SlowMist are among the independent security experts involved.

Can Bitget recover the stolen funds?

Some assets may potentially be frozen or recovered, but the eventual recovery amount is not yet known.

Is $387.5 million definitely the final loss?

No. It is the current gross amount Bitget says reached attacker-controlled addresses. Future recoveries could reduce the net unrecovered loss.

Was the separate Bitget Wallet product compromised?

The disclosed incident concerned Bitget’s centralized exchange infrastructure, not a general compromise of the separate self-custodial wallet product.

What should Bitget users do?

Follow official withdrawal-restoration updates, avoid fake reimbursement or recovery links and review platform exposure once normal withdrawals return.

What is the biggest lesson from the Bitget hack?

A protection fund can meaningfully absorb an exchange security loss, but it is only one layer. Exchange safety also depends on reserves, solvency, custody design, secure withdrawal infrastructure and the user’s ability to actually move assets off the platform.