Bitget's 131% reserve ratio after a $387.5M hack shows the limits of proof of reserves

A theft and a healthy ratio, five days apart

On September 24, 2026, attackers drained roughly $387.5 million from the crypto exchange Bitget. Five days later, at 09:00 UTC on September 29, the snapshot for Bitget's 47th proof-of-reserves report put its overall reserve ratio at 131% across 19 assets, down from 135% in the previous report. Per-asset figures came in at 142% for BTC, 110% for ETH, 107% for USDT and 154% for USDC.

A dev.to analysis published on October 9 treats that pairing as the clearest demonstration of what the format does and does not establish. The exchange absorbed a nine-figure theft and still held more than it owed customers — at that moment. What the ratio could not say was how the intruders got in, or what the balance sheet looked like the day before.

Bitget covered the losses with its protection fund, which held 5,500 BTC before the incident and was reported back at $309 million on September 30, according to figures the dev.to post attributes to The Crypto Times. Withdrawals resumed asset by asset: BTC on September 28, ETH on September 29, USDT on September 30, then other tokens, fiat and peer-to-peer transfers on October 2. Net outflows in the 24 hours before the snapshot reached about $463 million.

Two halves of one number

A reserve ratio is assets divided by liabilities, calculated per asset, and both sides have to be proven separately. Proof of assets is the simpler half: the exchange publishes the addresses it controls and signs a message with each key, letting anyone match balances against a chosen block height. Proof of liabilities — what the exchange owes its users — is harder, because listing every customer balance would expose everyone's holdings.

The standard approach is a Merkle sum tree, which Vitalik Buterin described in a 2022 post on exchange solvency. Each user becomes a leaf holding a hash of a salted identifier plus their balance. Every parent node commits to a hash of its children and the sum of their balances, so the root commits to total liabilities. The exchange publishes only the root; each user receives the sibling nodes along the path from their leaf. If recomputing that path lands on the published root, the user's balance was counted.

The classic cheat and the zero-knowledge fix

The best-known weakness is the fake negative balance. An exchange holding 890 ETH while owing customers 1,390 ETH can insert an account at -500 ETH, and the root will report liabilities of 890 ETH, exactly matched by reserves. A plain Merkle sum tree defends by rejecting negative sums during verification, but that only helps if users in the affected branch actually run the check — and Buterin notes that a dishonest exchange could simply leave awkward users out of the tree altogether.

Zero-knowledge proofs remove that reliance on users. A zk proof can establish that every balance in the tree is non-negative and that they add up to the claimed total, without exposing any individual balance. OKX has moved its liabilities proof to zk-STARKs: since September 2024, users download an inclusion-proof file and run it through an open-source validator, with a separate file covering the total and the non-negativity constraint. OKX's own 47th report listed 109% for BTC, 101% for ETH, 105% for USDT and 100% for USDC.

What a snapshot cannot cover

Proof of reserves became the industry's default reassurance after FTX collapsed in November 2022. A month later the accounting firm Mazars stopped offering this work to crypto clients, citing — per CNBC — discomfort with how the public interpreted the reports, which followed agreed-upon procedures, were not audits, and described a single past point in time. The dev.to post lists the gaps that persist:

• Any day other than the snapshot: assets can be borrowed for the day and returned afterwards. Buterin's suggested remedy is frequent or coordinated proofs, so two exchanges cannot count the same funds.
• Fiat: bank balances cannot be proven cryptographically and rest on confirmations and attestations.
• Liabilities outside the tree: loans and obligations to affiliates or market makers never appear in a customer liability tree.
• Key security: a wallet can be fully reserved and badly protected. Bybit lost about $1.5 billion in ETH in February 2025 in an attack the FBI attributed to North Korea.
• Your own inclusion: a proof does nothing for a user who never checks that their balance is in the tree.

Why it matters

Bitget's 131% is a real signal: the exchange stayed solvent through a $387.5 million theft and a day of roughly $463 million in net outflows, and the report shows it. But it is a solvency signal, not a security one. The report cannot explain how the attackers got in, cannot show how quickly the protection fund rebuilds, and says nothing about September 23. For developers building on exchange APIs and users holding coins on exchanges, reserves are one column in the risk table — incident history, fiat backing and off-chain obligations are others, and no ratio covers them.