What proof of reserves is meant to show
When people hear “proof of reserves,” they often imagine a simple test: an exchange publishes wallet addresses, the balances add up, and customers can conclude that their money is safe. The reality is more specific. A proof-of-reserves process tries to provide evidence about assets held by a custodian at a particular time. A stronger report also describes the customer balances the custodian owes and gives users a way to check that their own account was included in the liability calculation.
That distinction matters because an exchange can control a large amount of cryptocurrency and still owe more than it owns. It may also have obligations to lenders, trading partners, employees or other creditors that are not represented in a customer-balance tree. A reserve report is therefore a window into a defined part of a balance sheet, not a complete picture of the organization’s financial condition. The phrase “proof of solvency” should be used carefully because solvency involves a broader set of assets, liabilities, legal claims and operating risks.
The three parts to look for
A useful report usually has three elements. First, there is evidence of assets: addresses, signed messages, custody records or another method that demonstrates control over the reported assets. Second, there is a liability total: customer balances or obligations that the custodian says it owes. Third, there is an independent or cryptographic verification process that allows the reported assets and liabilities to be compared. If one side is missing, the conclusion is limited.
Readers should ask who prepared the report, what exactly was measured, when the snapshot was taken, which legal entities and products were included, and whether the methodology is public. A third-party accountant may check some assertions, but the scope and assurance standard matter. A report can be described as an attestation, agreed-upon procedures or an audit; those terms do not mean the same thing. Read the actual document instead of relying on a logo or a short social-media post.
How a Merkle tree helps customers check a balance
Many exchanges use a Merkle tree to organize customer balances. In simplified terms, each customer balance is represented by a leaf in a data structure. Pairs of leaves are hashed together, then those hashes are combined repeatedly until a single value—the Merkle root—represents the whole set. A customer receives a proof containing the relevant neighboring hashes and can recompute the root. If the result matches the published root, the customer can verify that the supplied balance was included in that dataset without seeing every other customer’s account.
The proof has a clear purpose, but it does not independently establish that the dataset contains every customer or every liability. The exchange or report preparer still has to define the population, include all relevant balances and prevent accounts from being omitted or misclassified. Users should check whether the proof shows a non-negative balance and whether the system’s rules make it possible to identify excluded accounts. A cryptographic commitment can reveal tampering with the committed data; it cannot prove that the original data was complete or truthful by itself.
What a user-verification process should look like
If an exchange offers a customer verification page, open it from the exchange’s official website or app—not from a link in an unsolicited email or message. Confirm the domain carefully. The page should identify the reporting date and explain what information you are being asked to verify. Some systems let users download a proof or enter a verification code. Others provide a local tool or open-source software that checks the proof against a published root.
The verification should not require a seed phrase, private key, remote access to your device or a signature that grants permission to move funds. A balance-inclusion proof is a data-checking process; it does not need custody of your wallet. If a “proof” page asks you to connect a wallet and approve a token transfer, stop and investigate. Even a legitimate exchange should not need your recovery phrase to prove that an account balance was included in an audit snapshot.
After checking the proof, save the report date and result for your own records. A successful check means the reported balance appears in the specified liability data under the stated methodology. It does not mean the exchange will remain solvent tomorrow, that every asset is freely withdrawable, or that the company has no other liabilities. The precise conclusion is narrower than many promotional summaries imply.
Assets need to be controlled, not merely displayed
An exchange may publish addresses that hold cryptocurrency, but readers need to know why those addresses are relevant. Does the exchange control the keys? Are the funds held by a custodian? Are assets pledged as collateral, lent out, locked in a contract or otherwise encumbered? A public blockchain can show that assets sit at an address at a given time, but it cannot by itself show every contractual claim on those assets.
Signed-message proofs can show that an entity controls a private key without revealing the key. They still do not prove that the funds belong to the exchange free of claims. A snapshot can also be timed strategically: assets may be borrowed or temporarily moved into view and transferred away afterward. Stronger reporting describes timing, liabilities, custody arrangements and subsequent events, and it uses a process that is difficult to manipulate. Even then, users should understand the limits of a point-in-time report.
The difference between reserves and liabilities
Customer balances are liabilities because the exchange owes customers access to those assets under its terms. A good assessment compares assets with the obligations they are meant to cover, on an asset-by-asset basis where possible. One Bitcoin held does not necessarily cover one Bitcoin owed if the exchange has borrowed, lent or otherwise committed the asset. Likewise, a total dollar figure can hide mismatches between currencies, tokens and withdrawal obligations.
Other claims may matter too. The business could owe money to lenders, have pending legal obligations, face tax claims or rely on derivatives that create contingent liabilities. A narrow customer-reserve proof may intentionally exclude those items. That does not make the report useless; it means the report answers a narrower question. Users should avoid translating “customer assets were covered in this snapshot” into “the company is fully solvent under every scenario.”
Red flags and stronger signals
Be cautious when a report has no clear date, lacks liability information, uses vague language about “all funds,” or does not explain how customers can verify their own inclusion. A single chart of wallet balances is not the same as an audit. A report that excludes certain products, jurisdictions or customer groups should say so. A lack of transparency about borrowed funds, collateral or off-chain balances also limits what can be concluded.
Stronger signals include a named and independent report preparer, a clear scope, asset-control evidence, a disclosed liability methodology, a user-verifiable proof, public documentation and a process for correcting errors. Regular reporting can improve transparency, but even frequent snapshots are not continuous solvency monitoring. Users should also look at the exchange’s legal entity, withdrawal terms, security practices, history of outages and the jurisdiction in which disputes would be handled.
Why proof of reserves is not deposit insurance
Crypto exchange balances do not automatically receive the same protections as bank deposits or securities accounts. The protection depends on the product, legal entity, jurisdiction and custody agreement. A proof-of-reserves report does not create an insurance policy, guarantee uninterrupted withdrawals or give a customer priority in insolvency proceedings. It is evidence about a defined set of assets and liabilities, not a promise to reimburse losses.
This is why operational controls matter alongside cryptography. Exchanges need secure key management, withdrawal controls, incident response, segregation policies and tested business-continuity plans. Customers should understand whether they retain legal ownership of assets, whether assets can be lent or rehypothecated, and what the terms say about insolvency. A technically sound Merkle proof cannot answer legal questions that the contract leaves unclear.
A practical due-diligence checklist
Before relying on a report, confirm the reporting date and whether it covers the legal entity and products you use. Check if it shows both assets and customer liabilities, and whether those amounts are compared in the same units. Review how wallet control was demonstrated and whether assets may be pledged, borrowed or held by third parties. Find out whether your own balance can be checked without exposing credentials. Read the assurance scope, exclusions and subsequent-event disclosures.
Then consider what the report does not answer: other debts, liquidity under mass withdrawals, security of private keys, governance and legal protections. Compare the report with the exchange’s terms and public disclosures. Avoid keeping more on a custodial platform than you can afford to have temporarily inaccessible, and consider self-custody only if you can manage the associated key and recovery risks. This is a general risk-management principle, not a recommendation for a particular exchange or wallet.
The right conclusion
Proof of reserves can make custodians more accountable by allowing customers to inspect an asset snapshot and, in some systems, verify that their own balance was included in a liability tree. That is a real improvement over asking users to trust an unexplained claim. The method is most valuable when the scope is clear, the proof is independently checkable and the limitations are disclosed.
It is not a complete balance-sheet audit, an insurance policy or a guarantee that an exchange will always honor withdrawals. Customers should treat it as one useful data point among several. Understanding what was proven—and what was not—is more protective than treating the phrase “proof of reserves” as a universal safety badge.
Sources and further reading
Vitalik Buterin: proof of solvency and its limits · Merkle Science: reserve and liability proofs
Comments
Loading comments…