Crypto Proof of Reserves Explained: Merkle Trees, Liabilities, and Limits

Proof of reserves, often shortened to PoR, is a label for procedures that try to show some combination of two things: that an organization controls certain digital-asset addresses, and that customer balances were included in a balance dataset. A report may compare those assets with the customer claims it covers. The phrase does not identify one universal method, accounting standard, asset scope, liability definition, or review schedule.

That makes the reader’s first question more useful than a headline ratio: what exactly was counted, for which legal entity, at what time, and under which procedure? An exchange may publish wallet balances, a third party may examine a snapshot, and a user may verify an account leaf in a Merkle tree. Those are related pieces of evidence, but they answer different questions.

The PCAOB Office of the Investor Advocate’s advisory warns that proof-of-reserve reports have significant limits. It reflects the views of that office’s staff, not necessarily those of the Board or other PCAOB staff, and is not a Board rule, policy, or statement. It says these procedures are not audits under PCAOB standards and may not address liabilities, customer rights, borrowed assets, controls, or what happens after the snapshot. Read that warning as a boundary on the evidence, not as a claim that every PoR process is identical.

A coverage ratio usually divides a stated asset amount by a stated customer-liability amount. If a report lists 1,020 BTC of in-scope assets against 1,000 BTC of included customer balances, its simple ratio is 102%. That arithmetic is meaningful only after the numerator and denominator are defined. Are both in BTC? Were they measured at the same time? Does the asset figure include only addresses the entity can control? Does the balance figure include every account, product, and claim that the entity owes?

A ratio above 100% is not automatically a complete balance sheet. A report can focus on customer crypto balances while excluding the company’s other debts, taxes, operating costs, legal claims, or obligations to lenders. Those items can matter to overall solvency even if they are outside the narrow question of whether a selected set of customer balances appears covered by selected on-chain assets.

Valuation also changes what a ratio says. If a report converts several tokens into dollars, the result depends on its price sources, timestamps, and treatment of assets that trade thinly or at a discount. A token amount can stay constant while its dollar value changes. Compare same-asset quantities where possible, then read any fiat conversion rules and the time used. Do not compare a live wallet balance with a liability snapshot from a different block or day as if they described one simultaneous state.

A Merkle tree groups records through repeated hashing. In a typical account-balance scheme, a record is converted into a leaf that represents an account identifier and one or more balances. Neighboring hashes are combined into parent hashes, and the process continues until a single root summarizes the committed dataset. A user can receive their leaf and the sibling hashes along the path to the root, then recompute the path independently.

The IETF’s RFC 9162 defines inclusion proofs for Certificate Transparency logs: if the reconstructed tree hash matches the published root, the proof establishes that the supplied leaf is present in that committed tree. Exchanges use their own data formats and proof systems, so the RFC is a general explanation of the cryptographic idea rather than a specification for every exchange’s PoR.

For example, Binance describes its Merkle tree and zk-SNARK process as ways for users to check that account records contribute to a reported total while limiting disclosure of other account data. Kraken describes account-balance inclusion and address-control evidence in its own PoR process. These are provider-specific descriptions. The key general limit is the same: verifying your leaf proves inclusion in the dataset that was committed. It does not prove that the operator started with a complete and accurate list of every customer obligation.

A blockchain explorer can show that an address held a certain amount at a particular block. That observation does not identify who can sign for the address. A separate signature or other control procedure can provide evidence that an organization can authorize a message from a key. Binance’s process description, for example, says it verifies that the reserve wallets belong to Binance; Kraken says its accountant checks digital signatures for addresses with publicly visible balances.

Even a valid signature is not a complete legal or economic conclusion. It shows control of a key for the tested address or message. It does not, on its own, establish that the assets are legally owned by the exchange rather than held for another party, free of liens or pledges, immediately transferable, or available to satisfy a particular customer claim. A wallet could also hold borrowed assets at the snapshot. The PCAOB staff advisory specifically notes that a snapshot may not reveal borrowing used to make reserves appear larger.

The address list matters too. An exchange can use hot wallets, cold wallets, custodians, omnibus wallets, or addresses shared across products. The report should explain how it identifies in-scope addresses and handles assets held through another custodian. If an address is omitted, controlled by a related entity, or included twice, the published numerator can tell a different story from the assets available to the entity being assessed.

The denominator may include different things across providers and report dates. Spot balances are only one possible category. A methodology may also adjust balances for margin positions, futures collateral, staking, pending transfers, internal loans, or unrealized profit and loss. A displayed customer balance is not always the same quantity used in the report’s liability tree.

Kraken’s current methodology page describes separate treatment for spot, staking, margin, and futures balances, including some product-specific adjustments. Its page also says account inclusion reflects in-scope assets at the snapshot and does not include later transactions or out-of-scope assets. That is an example of why scope labels matter; it is not a universal formula that applies to other platforms.

Check which operating companies are covered. A group may have multiple legal entities, brands, regions, subsidiaries, or custodians. A report about one company or one set of wallets does not automatically cover every product shown in the same app. Also ask whether pending withdrawals, negative account balances, loans, derivatives claims, and customer assets held at affiliates are included or netted. The answer changes what the denominator means.

A useful record therefore has more than a date in the corner. It identifies the review period, snapshot time and block heights, covered entities and products, included assets and account balances, exclusions, valuation source, netting rules, and the method used to test wallet control. Without those details, “100% backed” can describe a much narrower set than a reader assumes.

Suppose a hypothetical report lists 1,020 BTC of assets and 1,000 BTC of customer liabilities. The displayed ratio is 1,020 ÷ 1,000 = 102%. Now assume the dataset omitted 50 BTC of customer claims. The complete customer-liability amount would be 1,050 BTC, so coverage would be 1,020 ÷ 1,050 = 97.14%. The uncovered difference would be 30 BTC, before considering other debts or valuation changes.

The asset figure did not move in this example. The conclusion changed because the liability population changed. A Merkle proof from one customer could still verify correctly if that customer’s leaf was included; it cannot reveal whether another customer’s omitted claim is missing from the tree. This is why an inclusion proof and a completeness review are separate checks.

A second hypothetical shows why borrowed assets need a matching liability. Imagine an entity has $980,000 of its own unencumbered assets and borrows another $200,000 that is still in its wallets at the snapshot. The visible wallets contain $1.18 million. If customer claims total $1 million and the report omits the $200,000 borrowing obligation, the displayed comparison is 118%. Include the lender’s $200,000 claim and total obligations become $1.2 million; $1.18 million divided by $1.2 million is 98.33%, a $20,000 shortfall. The example assumes like-for-like values at the same time and ignores other assets, fees, and legal details. It illustrates why an asset snapshot alone cannot settle the liabilities question.

In January 2026, Binance announced a change to its PoR presentation after saying its previous net account-balance scope omitted platform assets and produced an inflated reserve ratio. That is a statement about Binance’s own methodology and update, not evidence that every exchange had the same calculation. It is a practical reminder to read what a published ratio includes and to check whether the method has changed between reports.

The word “audit” can appear in a platform’s marketing or in the name of a report, but the engagement’s scope and standards still matter. The PCAOB staff advisory says PoR engagements are not performed under PCAOB auditing standards or subject to PCAOB inspection. It also notes that providers use different procedures and standards, and that management may choose the agreed-upon procedures in some engagements.

An agreed-upon-procedures report generally reports findings from specified steps; it does not necessarily express an opinion that the procedure set was sufficient, that liabilities are complete, or that the company is financially stable. Limited-assurance engagements also differ. Read the report itself: who engaged the provider, what the provider was asked to test, which evidence was examined, which assets and liabilities were included, what exceptions were found, and what conclusion the provider actually states.

A separate financial-statement audit may cover a broader legal entity and wider liabilities, but it has its own reporting date, accounting framework, materiality, and scope. Do not infer that an exchange has such an audit simply because a PoR report names an accounting firm. Conversely, the limits of PoR do not mean every particular reserve statement is false; they mean the evidence supports only the conclusions its procedures actually test.

Start with the report date and exact entity. Confirm the snapshot time, relevant block heights, covered token contracts, wallet addresses, account products, and whether assets held through custodians are included. If a platform publishes a reserve ratio, look for the formula and denominator rather than treating the percentage as a self-explanatory rating.

Next, separate the evidence into two columns. For assets, ask what proves the address balance, address control, valuation, and freedom from borrowing, liens, pledges, or duplicate counting. For customer claims, ask how the account snapshot was produced, which balances are netted, how negative balances and unsettled transactions are treated, and whether every relevant account and entity is included. Then examine the third party’s scope, standards, independence, exceptions, and the report’s exact conclusion.

If a personal inclusion proof is available, verify that your own in-scope balance reconstructs the published root using the provider’s stated method and correct report date. Keep the proof private because account identifiers or balance records can be sensitive. A successful check tells you that the record you received is in the committed dataset. It does not tell you that every other record is present, that the asset side has no competing claim, or that withdrawals will be processed in a future stress event.

Finally, look for what falls between snapshots. A point-in-time check cannot continuously monitor borrowing, wallet movements, account changes, governance decisions, or operational failures after the cutoff. Read withdrawal terms, custody arrangements, legal entity disclosures, and any broader financial statements alongside PoR. For a related overview of how custody and trading venue differ, see the CEX-versus-DEX perpetuals guide. For key ownership and hosted-wallet distinctions, see the crypto wallet recovery guide.

PoR can make selected evidence more transparent and give users a way to check whether a record appears in a committed dataset. That is useful. It is not a guarantee of solvency, legal segregation, insurance, redemption at par, uninterrupted withdrawals, or safety from fraud, hacks, governance failures, and insolvency proceedings. Those questions depend on liabilities, legal rights, operations, custody, and the rules that apply in the user’s jurisdiction.

Do not confuse an exchange’s customer-asset report with a stablecoin issuer’s backing report. One generally concerns assets a platform holds or controls against customer-account claims; the other concerns a token arrangement’s reserves and redemption terms. The mechanisms can overlap, but the legal claims, included entities, and exit routes differ. The stablecoin depeg and redemption guide explains why a token’s market price, issuer reserves, and holder redemption value are separate measures.

A sound conclusion is narrow and dated: “This report shows these assets and these included balances under this stated method at this snapshot, and my account record was included.” If the report cannot support even that sentence clearly, the headline ratio is not enough to fill the gaps. This guide explains evidence and custody mechanics; it does not recommend an exchange or say where anyone should hold assets.