Crypto Exchange Proof of Reserves: What It Proves—and What It Leaves Out

A crypto exchange proof of reserves (PoR) can help answer a narrow question: did the exchange show control of certain on-chain assets at a stated snapshot, and were the customer balances included in its calculation? By itself, PoR does not establish that every obligation is disclosed, that the company is solvent, or that customer funds will remain available later. The liability side deserves as much attention as the wallet balances.

To assess a report, identify its date and scope, read how it defines customer liabilities, verify that your own balance is included, and compare the reported liabilities with assets that are both in scope and independently verifiable. Then note what the report excludes. This guide reflects public documentation available September 30, 2026; exchange methods and report coverage can change between attestations.

What does proof of reserves actually prove?

“Proof of reserves” is not one standardized report format. Many exchange PoR programs combine a snapshot of crypto assets in specified wallets with a snapshot of customer account balances. A cryptographic structure such as a Merkle tree can let a customer check whether a particular balance was included in an aggregate liability calculation without publishing every customer’s personal account details. Public blockchain data can also help users inspect wallet balances; a signed message may help establish that an exchange controls an address.

Those pieces answer different questions. An on-chain balance shows that assets existed at a particular block or time. A signature can support a claim that the exchange controls an address. A Merkle inclusion proof can show that a particular account’s included balance is part of a reported dataset. None of those checks, on its own, proves that the dataset contains every customer, covers every product or legal entity, or captures all of the business’s obligations.

For example, Binance’s PoR page describes verifying an individual account’s inclusion in its liabilities report and uses a Merkle-tree and zk-SNARK process. OKX documents separate checks for account inclusion, aggregate-balance and non-negative constraints, and the exchange’s wallet-address balances. These are examples of how a provider may let users inspect components of its own report; the presence of cryptography does not independently validate the scope chosen by management. See the current Binance PoR page and OKX PoR methodology for their stated procedures.

What does a reserve ratio leave out?

A ratio such as “assets exceed covered customer balances” only means what the report’s definitions allow it to mean. If the report compares assets in selected wallets against a subset of customer balances, it cannot tell you whether obligations outside that subset exist. It may also be a snapshot rather than a continuous view: assets can move, be pledged, borrowed, lent, or become unavailable after the capture time.

The PCAOB Office of the Investor Advocate warns that PoR engagements may not address the entity’s liabilities, the rights and obligations of digital-asset holders, or whether assets were borrowed to make reserves appear larger. It also notes that a snapshot does not assure assets remain available after the report date, and that PoR reports do not provide assurance about internal controls, governance, reserve adequacy, or financial stability. The advisory expressly says it reflects the views of that office’s staff and is not a rule or policy statement of the PCAOB. Read the PCAOB staff investor advisory for its full qualifications.

The SEC’s Investor.gov bulletin makes a related distinction: a PoR report is not a substitute for an audit performed by a registered public accounting firm under PCAOB standards. A report’s use of the words “audit,” “attestation,” “independent,” or “zero knowledge” is not enough to determine its assurance level. Read who performed the work, which standards or agreed-upon procedures applied, what management selected, and exactly what conclusion the provider states. The Investor.gov bulletin on crypto-asset reports explains this warning.

How can you check the liability side?

Start with the report itself, not a headline or a reserve-ratio graphic. Look for the underlying liability report, the cryptographic proof files, the methodology, and the independent provider’s statement. Then work through the following checks.

1. Pin down the snapshot and scope. Record the snapshot date or block height, the report publication date, the included assets, and the products or account types covered. Check whether the report applies to the same exchange entity where you hold funds, and whether it is global or limited to a region. A report may exclude certain tokens, products, custody arrangements, or entities. A newer publication date does not necessarily mean the balances were captured that day.
2. Find the reported customer liabilities by asset. Look for a total customer net balance or liability amount for each covered token, along with the rule used to calculate it. Ask whether the total includes spot accounts, margin borrowing, staking balances, earn products, collateral, pending withdrawals, and subaccounts. Do not assume that “all account assets” means all obligations of every affiliate or business line. If the report does not say what is included, treat the boundary as unknown.
3. Check your own inclusion proof. Use the exchange’s authenticated account page or instructions to retrieve the record, Merkle leaf, or proof for the correct snapshot. Run the provider’s published verification method or open-source tool, downloaded from the provider’s official page or repository. Confirm that the verification succeeds and that the account balance and asset match the snapshot. Never share a private key, seed phrase, or one-time login code to perform this check. A successful inclusion test supports the claim that your reported balance was included; it does not prove the reported customer set is complete.
4. Test aggregate and non-negative constraints where offered. Some systems publish a proof that the sum of account balances matches the declared liability total and that no included account has a negative balance. Read the exact constraint names and source code or verifier instructions. “No negative account” is useful for detecting one form of netting, but it does not establish that every outside liability, loan, claim, or entity is included in the dataset.
5. Compare like with like. Check reserve assets and liabilities for the same asset and snapshot, not just a single dollar-denominated headline ratio. A surplus of one volatile token may not be equivalent to a shortfall in another asset customers are owed. If the exchange reports totals in dollars, inspect token-by-token amounts and the valuation method. Also check whether the assets are in wallets the exchange says it controls, at the block height used for the snapshot.
6. Read exclusions and the provider’s conclusion. Look for limits on procedures, assets held with third-party custodians, pledged or staked assets, borrowed funds, timing differences, and the report’s intended users. A provider that confirms only factual procedures may not be expressing an opinion on solvency or the adequacy of reserves. If the report does not discuss a liability category, do not silently treat it as covered.

What does a Merkle proof tell an individual customer?

A Merkle tree compresses many records into a single root hash. A proof supplies the path needed to check whether one record contributes to that root. If the exchange also publishes a verifiable aggregate proof, customers may be able to test whether all included leaf balances add up to the announced total under stated rules. The benefit is privacy-preserving verification: the exchange need not publish a named list of every user and balance.

The limitation is the boundary of the dataset. Cryptography can show that a record was included and that a stated computation was performed over a defined set. It cannot independently show that management included every account, every liability, or every legal entity unless the system’s design and supporting evidence establish that boundary. A customer should therefore read the liability methodology alongside the proof result. Do not convert “my balance is included” into “the entire exchange is solvent.”

Exchange documentation shows that these systems and files are provider-specific. Binance’s verification guidance describes locating a user’s Merkle record and choosing a verification date. OKX publishes liability-proof files and verification steps for inclusion, total-balance, and non-negative constraints. Follow the currently posted instructions for the specific report you are checking: older snapshots may use different file formats or tools. Refer to Binance’s account-balance verification steps and the current OKX self-verification documentation.

Which omissions should make you pause?

Missing information is not proof of misconduct, but it limits what you can infer. If the exchange publishes only asset addresses and a reserve ratio without a liability total, customer inclusion method, exclusions, or a clearly scoped third-party report, you do not have enough evidence to independently assess liabilities. You can ask the provider for the missing scope and procedure details; if they are not available, describe the uncertainty rather than assuming the strongest interpretation.

What should you conclude after checking a report?

A careful conclusion is specific: for the stated snapshot, the exchange reports specified on-chain assets; the report covers certain account balances; your account’s stated balance did or did not verify as included; and the listed procedures did or did not test aggregate and non-negative constraints. Separately state what the report does not establish, such as total company liabilities, freedom from liens, control quality, future availability, or legal treatment of customer property.

PoR can add useful transparency, especially when customers can verify account inclusion and compare disclosed liabilities with identifiable reserve assets. It is one input, not a complete risk assessment. Review the exchange’s financial statements where available, custody terms, withdrawal conditions, legal entity and jurisdiction, independent audit reports, and current disclosures about borrowing or asset use. If those documents are unavailable or inconsistent, the reserve ratio alone cannot fill the gap.

For a final check, ask: What date was measured? Which assets were counted? Which customers and obligations were included? Can I verify my balance and the aggregate math? Who performed the work, under what procedures, and what did they explicitly decline to conclude? The answers help distinguish a verifiable snapshot from a broader claim about solvency that the snapshot may not support.