What does proof of reserves actually prove?
A proof-of-reserves report is evidence about a defined set of assets, and in some implementations customer balances, at a specified time. What it establishes depends on the method and report scope. A wallet balance, customer-inclusion proof and financial statement audit answer different questions.
Use a simple distinction: a reserve ratio compares the report's defined numerator and denominator; it is not a live promise that every withdrawal will work. The PCAOB's Office of the Investor Advocate warned in March 2023 against treating proof-of-reserve reports as sufficient evidence that customer liabilities can be met. That advisory is staff guidance, not a new rule.
This guide concerns exchange disclosures. For an issuer-backed stablecoin's circulation, reserve assets and direct-redemption terms, use the separate stablecoin report-reading guide. Do not assume an exchange's holdings of a stablecoin establish the issuer's reserves, or vice versa.
Record five things before trusting the percentage
Start with the original report linked by the exchange, not a cropped dashboard or social post. Identify the legal entity, included assets and products, snapshot timestamp and timezone, publication date, and method or independent practitioner's conclusion. Record exclusions and defined adjustments beside the ratio.
A report released on Friday can describe balances measured on Monday. It cannot, by its date alone, establish what happened on Thursday. For an incident or market event, draw the event time and snapshot time on the same timeline before making a comparison.
Binance's methodology page describes account inclusion in an aggregate net balance using Merkle trees and a zk-SNARK mechanism. Kraken describes a customer verification process and the limitations of its reserve reviews. These are each platform's descriptions of its method, not independent endorsements of the platform or evidence about today's solvency.
- Which legal entity, token, network and product does this report cover?
- What exact time was measured, and when was the report released?
- What is counted in customer balances, and what is excluded or netted?
- Who performed the work, under which criteria, and what conclusion did they actually give?
- Which unanswered questions remain about obligations, restrictions and withdrawals?
A Merkle proof checks inclusion, not every obligation
A Merkle tree combines records into a root hash. An inclusion proof lets you check that a particular record belongs to the committed dataset without downloading every customer's record. Binance describes this mechanism for individual account balances; additional proof rules depend on its published circuit and methodology.
A successful check of your record is useful, but it does not independently establish that every other customer or creditor was included. It also does not prove the exchange has no bank loans, pledged assets or obligations outside the report's scope. Cryptography can check a stated relationship without proving that the inputs describe the entire business.
For example, if your fictional record says 0.25 BTC at the stated snapshot, checking inclusion supports that record's membership in that snapshot. It does not show your later deposit or prove that a withdrawal requested today has settled. Keep the claim limited to what was checked.
Worked example: the same numbers can answer different questions
Consider fictional Exchange Cedar. At 12:00 UTC on a stated date, its report lists 105 BTC in covered wallets and 100 BTC in defined covered customer balances. Reported coverage is 105 ÷ 100 × 100 = 105%, with a 5 BTC arithmetic excess within that scope.
Do not combine its 105 BTC snapshot with a later customer-balance figure of 110 BTC and label 95.45% a verified reserve ratio. The division is mathematically possible, but the dates do not match. You need assets and the relevant obligations measured on a comparable basis.
For a separate sensitivity exercise, suppose evidence established another 10 BTC obligation due at that same original time and omitted from the stated denominator. If the same 105 BTC were fully available against both sets of obligations, coverage would be 105 ÷ 110 × 100 ≈ 95.45%. The extra obligation is an invented assumption, not an allegation about any real exchange.
Even the revised calculation would not by itself decide legal solvency: other assets, liabilities, valuation rules and restrictions may matter. The purpose is to expose how scope changes an answer, not to turn a simplified ratio into a verdict.
Why proof of reserves is not a financial statement audit
The SEC's July 2023 investor bulletin distinguishes proof-of-reserve, valuation and calculation reports from financial statement audits under SEC rules and PCAOB standards. Read the actual engagement and conclusion rather than assuming a page labeled 'audit' provides that type of assurance.
In that context, a financial statement audit assesses whether financial statements are presented fairly, in all material respects, under the applicable reporting framework. That is broader than checking selected wallet balances. Audit work provides reasonable rather than absolute assurance and does not guarantee future withdrawals or the absence of every fraud.
A smart-contract code audit is another separate exercise. A review of software does not establish an exchange's complete finances. Likewise, a cryptographic proof does not replace the legal terms governing who owes you assets. This comparison does not claim that every jurisdiction uses the same accounting or audit standards.
How to verify your own inclusion safely
Enter the exchange through its official site or your existing app, then locate its reserve-verification instructions for the relevant review date. Kraken's process provides account-specific information for checking a record and its path to the published root. Follow the exact current format for that report rather than a generic online calculator.
Compare the included balances with your records at the snapshot, accounting for the report's stated scope. Keep personal record identifiers private. Do not give a stranger your seed phrase, sign a transfer or send money to 'activate' a reserve check. If verification fails, first check date, asset coverage and record formatting; a failed attempt alone does not establish missing funds.
Ask official support for a specific explanation of any unresolved discrepancy. Save the report URL, timestamp and the question without posting private account details publicly. Mark the result as verified, mismatch or not enough information, rather than forcing every case into safe or unsafe.
What remains unknown after a successful check?
Kraken's own limitations section explains that a review cannot establish exclusive possession of private keys, identify every hidden encumbrance or prove assets were not borrowed for the review. It also notes that theft or key loss can happen after the snapshot. Regular reports are useful evidence, but each still needs a scope and date.
Separate backing from liquidity and operations. A platform may report covered assets while a particular withdrawal route is paused, restricted or unavailable. Check the current service notice and your account's applicable terms separately. Conversely, one completed withdrawal is an observation about that transaction, not proof that all obligations can be met.
Absence of a proof-of-reserves report is not, by itself, proof of insolvency. A high ratio is not proof of safety. Keep a record of the evidence you have and the questions it does not resolve.
Five-minute practice: rewrite an overconfident claim
A fictional post says: 'Cedar published 105% reserves today, so yesterday's incident is fully covered and every withdrawal is guaranteed.' The attached report actually describes the noon snapshot two days before the incident. List the claims the document cannot support before checking the arithmetic.
A defensible rewrite is: 'Cedar's report lists 105 BTC against 100 BTC of covered customer balances at its stated pre-incident snapshot. That is 105% within the report's scope. The report alone does not establish post-incident balances, all obligations or current withdrawal availability.'
Your worksheet should retain the source, entity, covered assets, snapshot and publication times, definitions, calculation, inclusion-check result and unresolved questions. To assess a later event, seek later evidence with matching scope; do not silently move the old snapshot forward.
Sources & further reading
- PCAOB Investor Advocate: limitations of proof-of-reserve reports
- SEC Investor.gov: alternatives to financial statement audits
- Kraken: verification process and acknowledged limitations
- Binance: Merkle trees and account-balance inclusion
- PCAOB AS 1000: audit objectives and reasonable assurance
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.