Bitget Proof of Reserves Explained: How to Verify Your Assets With a Merkle Tree

Bitget Proof of Reserves gives users a way to check whether eligible account balances were included in a published reserve snapshot. The system combines disclosed platform wallet balances with a Merkle Tree built from covered user balances. A successful personal verification is useful evidence, but it is not a guarantee against every custody, liquidity, operational or solvency risk.

Last reviewed: October 28, 2026. Bitget updates its Proof of Reserves data periodically, and covered assets, wallet addresses, reserve ratios, verification files and interface labels can change. Use the latest authenticated Bitget dashboard and official open-source repository. This independent guide is educational and is not financial, legal, investment or security advice.

What is Bitget Proof of Reserves?

Proof of Reserves, commonly shortened to PoR, is a transparency process used by custodial crypto platforms. It is intended to show that disclosed assets held by the platform cover the user balances included in a particular report.

Bitget publishes reserve information and lets eligible users verify their own inclusion through a Merkle Tree. The platform has published monthly reports since December 2022. In September 2026, Bitget announced that its PoR coverage had expanded from four core assets to 19 assets. Coverage can expand again, so the current dashboard—not an old article—is the correct source for the live list.

PoR matters because a centralized exchange controls the private keys to exchange wallets and records customer claims on an internal ledger. Users can see their account balance, but that number alone does not reveal how much of the corresponding asset the custodian holds. Reserve reporting provides additional evidence that can be checked rather than accepted only as a marketing statement.

Assets and liabilities: two sides of the calculation

A reserve assessment compares two broad quantities:

• Platform assets: covered coins or tokens held in wallets attributed to Bitget.
• User liabilities: covered balances that Bitget owes to users according to the snapshot of its internal ledger.

In this context, “liability” does not mean that a user has done something wrong. If a customer deposits 1 BTC, Bitget has custody of an asset and simultaneously owes the customer 1 BTC under the account relationship. A meaningful PoR process needs evidence on both sides.

The Merkle Tree helps users verify inclusion on the liability side. Public reserve addresses and ownership-verification procedures help demonstrate the asset side. Neither side should be evaluated alone.

What does a reserve ratio mean?

A simplified formula is:

Reserve ratio = disclosed platform assets ÷ covered user balances × 100%

These examples explain the arithmetic, not Bitget’s current ratios. A ratio can change as users deposit, withdraw and trade, and as Bitget changes its operational wallet balances. Always attach a ratio to its asset, snapshot time and report methodology.

A high ratio is not the same as a guaranteed payout. Users must still ask which assets and balances were included, who controls the wallets, whether assets are encumbered and what other obligations may exist.

Which assets does Bitget PoR cover?

Bitget’s September 2026 expansion brought the published coverage to 19 assets. That was a significant increase from the earlier four-asset framework. It does not mean that every asset listed for trading on Bitget is covered.

Before relying on PoR for a particular balance:

1. Open the latest Proof of Reserves dashboard.
2. Confirm that the asset appears in the current covered list.
3. Check the snapshot date and time.
4. Read the asset-specific reserve and user-balance figures.
5. Verify that your personal proof includes the expected asset.

A token being available for spot trading, futures collateral or Earn does not automatically mean it is part of the current PoR disclosure. Different products may also represent balances differently. If the treatment is unclear, consult current Bitget documentation rather than extrapolating from BTC or USDT.

A snapshot is a point in time

Proof of Reserves normally uses a snapshot: a record of covered platform and user balances at a specified moment. The Merkle root belongs to that dataset. Deposits, withdrawals, trades, fees and rewards occurring later can make a user’s current account different from the snapshot.

This explains why a successful old proof may show an amount that no longer matches the dashboard. It does not automatically indicate an error. First compare the audit identifier and timestamp.

Snapshot reporting also has a limitation. It demonstrates information about the selected moment, not uninterrupted reserve coverage between reports. A long sequence of consistent monthly reports is more informative than one isolated report, but it is still not continuous real-time proof of every liability.

How a Merkle Tree works

A Merkle Tree is a cryptographic data structure that summarizes many records in one root hash. At the bottom are leaf nodes derived from individual records. Pairs of nodes are hashed into parent nodes. The process repeats until one Merkle root represents the dataset.

The simplified flow is:

User record → leaf hash → parent hashes → Merkle root

A hash is a deterministic digital fingerprint. The same input produces the same output, while even a small change to a balance or identifier should change the resulting hashes. If someone alters a leaf after the tree is generated, the calculation should no longer lead to the published root.

The tree therefore permits efficient inclusion proofs. A user does not need every other user’s private account information. The user needs their own leaf data plus the neighboring hashes required to calculate the path to the root.

Leaf nodes, paths and the Merkle root

Bitget’s current open-source specification determines the exact ordering, balance fields and hashing logic. A generic Merkle calculator may use different rules and produce a different result. Use the version and instructions associated with the relevant Bitget report.

How privacy is preserved

A public spreadsheet of usernames and balances would create a serious privacy and security problem. Merkle proofs allow a user to check inclusion without exposing ordinary identifying details for every account.

This does not make the downloaded proof meaningless or safe to publish. It can contain audit identifiers, anonymized account references, balances and cryptographic material tied to the verification. Keep it private and avoid posting screenshots that reveal holdings or account data.

A Merkle proof never requires a password, email password, authenticator code, withdrawal code, API secret, seed phrase or private key. Anyone requesting those values to “complete PoR verification” is attempting fraud.

How to verify your assets on Bitget

1. Start from a trusted address. Open a saved Bitget bookmark or type the official domain directly. Avoid sponsored links and messages.
2. Sign in securely. Confirm the domain before entering credentials or approving a passkey.
3. Open Proof of Reserves. Use the official site navigation rather than a link sent by an unknown person.
4. Select the latest snapshot. Record its audit ID, date and time.
5. Review the platform figures. Check covered assets, user balances, reserves and reserve ratios.
6. Open My Proof of Assets. Locate the personal verification information for the same snapshot.
7. Review the included balances. Compare them with account records from the snapshot time, not necessarily today’s balance.
8. Run the interface verification. Confirm that the personal path resolves to the published root.
9. Download the verification data if needed. Save it in a private local folder.
10. Check with the official tool. Use the applicable Bitget MerkleValidator release or inspect the open-source logic.
11. Save the result. Record the snapshot ID and outcome without exposing sensitive data publicly.

Interface wording may change. The invariant is that the user must compare one personal proof with the same report’s published Merkle root. Mixing a data file from one month with another month’s root should fail.

How to use MerkleValidator safely

Bitget publishes verification code through the BitgetLimited organization on GitHub. Open-source availability lets technically capable users inspect the implementation and permits independent reproduction of the calculation.

Before running a verifier:

• reach the repository through Bitget’s official PoR documentation;
• verify the GitHub organization and repository name;
• read the release notes and instructions for the snapshot;
• do not download a repackaged executable from a file-sharing service;
• scan downloaded files and verify published checksums where available;
• use a standard user account rather than unnecessary administrator privileges;
• never enter login credentials or wallet recovery phrases;
• keep personal proof data private after verification.

A verifier only needs the proof data required to recalculate the tree. It does not need authority to trade, withdraw or connect to a self-custody wallet. If a program asks for those permissions, stop.

What a successful Merkle verification proves

A successful result provides evidence that:

• the supplied personal record is consistent with the verification path;
• the path calculates to the published root for that snapshot;
• the covered balances in that record were included in the tree;
• changing those inputs would normally break the same calculation.

In plain language, the exchange did not omit the verified record from that published user-balance dataset. This is important because reserve assets are meaningful only when compared with a liability set that includes users.

What a successful verification does not prove

Merkle inclusion alone does not prove:

• that every Bitget user and product was included;
• that all corporate liabilities are disclosed;
• that reserve assets are free of loans, liens or other claims;
• that the same assets were not used in another representation;
• that reserves remained unchanged after the snapshot;
• that withdrawals will always process immediately;
• that the exchange cannot suffer an operational, legal or security incident;
• that the user’s own account cannot be compromised.

This distinction is central. Proof of inclusion answers a precise cryptographic question. It should not be expanded into a promise that the tool was never designed to make.

How to inspect disclosed reserve wallets

Reserve pages can publish addresses attributed to the platform. A user can open a supported address in the relevant blockchain explorer and inspect its balance and transactions without signing a wallet message or connecting a personal wallet.

Check the blockchain network carefully. An address format or token contract may differ across networks. Confirm that the explorer link comes from official Bitget documentation and that token balances use the intended contract.

On-chain visibility shows what an address holds at a given block. Additional evidence is needed to attribute ownership or control to Bitget. Platforms may use signed messages, transactions or other verification procedures. Merely finding a large address labelled “Bitget” by a third-party explorer is weaker evidence than following the official ownership-verification process.

Wallet balances can move after publication

Exchange wallets are operational infrastructure. Deposits arrive, withdrawals leave and treasury systems move funds between hot, warm and cold storage. A later explorer balance may therefore differ from the snapshot without automatically invalidating the report.

When investigating a difference, compare the address set and blockchain height used by the report. Follow outgoing transactions to the extent possible instead of treating every transfer as a loss. At the same time, do not assume that any unexplained movement is harmless; recurring reports and clear address disclosure improve accountability.

Proof of Reserves versus Proof of Liabilities

A platform can show a genuine wallet balance while using an incomplete liability figure. Conversely, a complete liability tree without credible ownership of the matching reserves is insufficient. Stronger transparency connects the two and clearly defines the scope.

Proof of Reserves versus a financial audit

A financial audit can examine much more than blockchain balances: internal controls, legal entities, bank accounts, contracts, debts, valuation policies and off-balance-sheet commitments. Its scope and assurance standard should be stated in the auditor’s report.

A cryptographic PoR system has a narrower strength. Users can independently verify specific calculations rather than relying entirely on a professional opinion. That makes PoR valuable, but it does not automatically make it equivalent to an audit.

Look for precise wording such as “audit,” “attestation,” “agreed-upon procedures” or “self-published report.” These terms can describe different levels of work. The existence of a Merkle root does not determine which accounting review occurred.

How to compare monthly Bitget reports

A time series can reveal more than one headline ratio. Maintain a small record with:

• snapshot date and audit ID;
• number and names of covered assets;
• reserve and user-balance amount for each important asset;
• asset-specific and overall ratios;
• changes to published wallet addresses;
• whether personal inclusion verification succeeded;
• material methodology or tool-version changes.

A falling ratio is not automatically a crisis if it remains above full coverage; users may simply have deposited more of that asset. A rising ratio is not automatically improved profitability. Analyze the numerator and denominator rather than only the percentage.

Proof of Reserves and derivatives balances

Exchange accounts can contain spot assets, futures margin, unrealized profit or loss, borrowed funds and Earn positions. These categories complicate liability accounting. Bitget’s methodology and report scope determine how each covered product enters the snapshot.

Do not take a single visible futures equity number and expect it to appear identically in the personal proof. Settlement currency, realized balances and product accounting may matter. When the figures cannot be reconciled, export account records and consult official support without sending credentials.

Proof of Reserves versus the Bitget Protection Fund

Proof of Reserves and the Bitget Protection Fund are separate mechanisms. PoR compares disclosed reserve assets with covered user balances. The Protection Fund is described by Bitget as an additional pool intended for certain protection scenarios under its rules.

A Protection Fund balance should not be silently added to every asset’s PoR ratio. Its assets, eligibility conditions and purpose can differ. Likewise, a reserve ratio above 100% does not tell a user that a claim qualifies for compensation from the fund.

Evaluate each mechanism using its own official page, wallet disclosures and terms. Neither replaces strong account security or a decision about how much custodial exposure is appropriate.

Proof of Reserves does not replace account security

A fully backed account can still be stolen through phishing, mailbox compromise, reused passwords, malicious API keys or a fraudulent withdrawal confirmation. PoR addresses platform-level asset transparency, not user authentication.

Use a unique password, protect the associated email account, enable a passkey or strong authenticator-based MFA, create an Anti-Phishing Code and review withdrawal addresses and API keys. Ignore private messages offering reserve “verification assistance.”

Never connect a self-custody wallet merely to check exchange reserves. Public addresses can be inspected without signing anything. A website asking for an unlimited token approval is unrelated to legitimate PoR verification.

Common Proof of Reserves mistakes

• Reading 120% as a guarantee that every possible obligation is covered.
• Using a ratio without its asset and snapshot date.
• Assuming every listed coin is included in PoR.
• Checking the reserve addresses but not personal liability inclusion.
• Verifying an old snapshot and comparing it with today’s balance.
• Downloading a fake MerkleValidator from a message or advertisement.
• Publishing personal proof files or balance screenshots.
• Confusing PoR with a complete independent financial audit.
• Adding the Protection Fund to reserve figures without methodological support.
• Keeping more on an exchange solely because a recent ratio was high.

A practical Bitget transparency checklist

1. Confirm the report comes from the official Bitget domain.
2. Record the latest snapshot timestamp and audit ID.
3. Check whether each important asset is covered.
4. Read both reserve amounts and covered user balances.
5. Verify your personal Merkle inclusion for the same snapshot.
6. Use only the official BitgetLimited verification repository.
7. Inspect disclosed reserve addresses on correct blockchain explorers.
8. Compare several monthly reports instead of one headline.
9. Read methodology changes and coverage limitations.
10. Separate PoR conclusions from Protection Fund claims.
11. Maintain strong login, email, API and withdrawal security.
12. Keep only the custodial balance appropriate for your actual use.

Frequently asked questions

Does Bitget publish Proof of Reserves?

Yes. Bitget publishes PoR information, reserve ratios, covered asset data and a personal Merkle Tree verification workflow. Use the current official dashboard for the latest report.

How often does Bitget update Proof of Reserves?

Bitget states that it publishes monthly updates. Check the dashboard timestamp because publication timing and methodology can change.

What does a 100% reserve ratio mean?

In the simplified PoR calculation, disclosed reserves equal the covered user balances for that asset at the snapshot. It does not by itself address every other corporate obligation.

What is a Merkle leaf?

It is the cryptographic leaf record associated with a user’s covered balance data. Together with neighboring path nodes, it can be recalculated toward the published root.

Does Merkle verification reveal my identity publicly?

The design uses hashed or anonymized records rather than a public list of ordinary account identities. Personal proof data can still reveal sensitive balance information, so do not publish it.

Why does the snapshot differ from my current balance?

The snapshot records a past moment. Later deposits, trades, withdrawals, fees and rewards change the live account. Compare records at the same timestamp.

Does PoR prove Bitget is completely solvent?

It supplies evidence about disclosed reserves and covered user balances. Complete solvency analysis would also require confidence that all relevant liabilities and claims are included and assets are available.

Are all Bitget assets covered?

No assumption should be made. Bitget expanded coverage to 19 assets in September 2026, but the live dashboard determines the current list.

Is MerkleValidator safe?

The official open-source code can be inspected, but users must still verify the repository and release. A fake program with the same name can be malware. The verifier never needs a password, 2FA code or seed phrase.

Is the Bitget Protection Fund part of PoR?

It is a separate protection mechanism with its own assets and terms. Do not combine its value with PoR calculations unless the official methodology explicitly does so.

Does Proof of Reserves replace self-custody?

No. PoR can improve transparency around custodial holdings, while self-custody changes who controls the private keys. Each model has different risks and responsibilities.

Final takeaway

Bitget Proof of Reserves is most useful when users actually verify it. Read the snapshot scope, confirm that the relevant assets are covered, verify personal inclusion through the Merkle path and inspect the disclosed reserves. Repeat the process over time instead of relying on one percentage.

Interpret the result precisely. A valid Merkle proof shows that a covered balance was included in a particular dataset. It does not eliminate counterparty risk, replace a full financial audit or protect a poorly secured account. PoR should be one part of a broader custody decision.

Official Bitget sources

• Bitget Proof of Reserves dashboard: current snapshots, reserve ratios, covered assets and personal verification entry point.
• Bitget Academy — How to Verify Your Assets: Bitget’s official account-level verification instructions.
• Bitget Academy — Merkle Tree and Proof of Reserves: explanation of leaf records, Merkle roots and reserve verification.
• Bitget Academy — Proof of Reserves expansion: official information about the 2026 expansion from four to 19 covered assets.
• BitgetLimited Proof of Reserves repository: open-source Merkle verification code, data format and technical instructions.