Proof of Reserves Explained: What It Proves, What It Misses & How to Verify It

By the CoinQuickly Editorial Team

Proof of reserves is evidence that a crypto custodian held specified assets under specified procedures at a stated time. A stronger implementation may also let customers verify that their balances were included in a cryptographic commitment to covered liabilities. That is useful transparency—but it is not automatically a complete balance sheet, a liquidity test, or proof that the business is solvent.

The essential discipline is to ask what each proof actually proves. A blockchain balance can establish that assets existed at a block height. A signed message can support control of a wallet. A Merkle branch can establish that one account was included in a committed dataset. None of those facts alone establishes that every liability was counted, the assets were unencumbered, or customers could withdraw tomorrow.

🧭 Key Takeaways - Proof of reserves is a category of methods, not one universal reporting standard. - A wallet balance shows assets at an address; a signature supports control, not necessarily legal ownership or unrestricted availability. - A Merkle proof can verify that your account was included, but not that every other customer or obligation was included. - A reserve ratio is meaningful only when the asset and liability definitions, valuation rules, entity, and timestamp match. - Treat PoR as one due-diligence input alongside financial, legal, operational, custody, and withdrawal evidence.

🧩 What is proof of reserves?

Proof of reserves, or PoR, is a process used by a custodian to support a claim about assets held against customer balances. In crypto, it often combines on-chain evidence with an off-chain customer-liability dataset.

The term is used loosely. A platform may call any of the following “proof of reserves”:

• A public list of wallet addresses
• A dashboard showing reserve balances and ratios
• A cryptographic proof that a user balance is included in a Merkle tree
• A zero-knowledge proof over a committed liability dataset
• A third-party agreed-upon procedures report
• A limited-assurance attestation
• A recurring review combining several of these elements

These are not interchangeable. Before relying on a result, identify the exact claim, entity, assets, liabilities, date, method, and report type.

The cleanest conceptual model separates three ideas:

Proof of assets + proof of liabilities = evidence toward proof of solvency

Proof of assets asks whether the custodian controls or holds the assets it reports. Proof of liabilities asks whether covered customer claims were measured completely and correctly. Solvency asks whether available assets can meet relevant obligations. A PoR arrangement may address one, two, or all three with different levels of confidence.

When reviewing a platform on CoinQuickly’s crypto exchanges directory, treat availability of PoR as a research prompt—not a safety badge. The underlying report matters more than the presence of a checkmark or marketing label.

✅ What can proof of reserves prove?

A well-designed PoR process can provide verifiable evidence about a narrowly defined snapshot. Its strongest conclusions usually concern existence, control, inclusion, and arithmetic within the stated scope.

Asset existence at a snapshot

Public blockchains let anyone inspect balances at a specific block. If a report identifies addresses, assets, networks, and block heights, a reader can independently reproduce the observed balances.

That transparency is a genuine advantage over an unsupported statement. It also has boundaries: a balance does not say whether the asset was borrowed, pledged, jointly controlled, owed to someone else, or transferred after the snapshot.

Control of wallet keys

A platform can sign a fresh message or make an agreed transaction to demonstrate signing authority. This helps link the reporting entity to an address instead of merely pointing to a wealthy wallet.

The wording should remain precise. A valid signature proves access to the required signing authority under the tested arrangement. It does not, by itself, establish beneficial ownership, legal title, lack of liens, or unilateral ability to move assets if a multisignature or custodian is involved.

Inclusion of a customer balance

If the report supplies a user with a record ID, leaf value, or Merkle path, that user can verify that the reported balance was included in the committed liability dataset. This makes silent exclusion harder when many customers verify and can challenge discrepancies.

Inclusion is personal, however. Your successful proof says your leaf is in this tree. It does not say that every other valid account, product, affiliate, or off-platform obligation appears in the tree.

For a wider framework on separating a displayed metric from the definition behind it, see CoinQuickly’s guide to reading crypto market data.

🌳 How Merkle trees and zero-knowledge proofs work

Merkle trees compress many records into one cryptographic commitment called a Merkle root. Each customer record is transformed into a leaf hash. Pairs of hashes are combined repeatedly until one root remains.

To verify inclusion, the customer does not need the entire database. The platform provides the neighboring hashes along the path from that customer’s leaf to the root. The customer—or an open-source verifier—recomputes the path. If the result matches the published root, the record belongs to the committed dataset.

This provides three useful properties:

1. Tamper evidence: Changing a committed record changes the root.
2. Efficient inclusion checks: A user can verify a path without downloading every account.
3. Some privacy: The full customer list need not be published.

But a plain Merkle tree proves membership, not the sum of balances. A Merkle sum tree adds balance totals to nodes, allowing a proof to commit to both the data and aggregate amounts. It must handle negative balances carefully; otherwise, a fabricated negative account could reduce reported liabilities.

A zk-SNARK can prove that a private dataset satisfies encoded rules without revealing all underlying balances. Depending on the design, the proof can establish that leaves contribute to a total, balances or net positions meet defined constraints, and the root was updated consistently.

Zero knowledge improves privacy and can enforce more sophisticated rules, but it does not make the initial dataset magically complete. A mathematically valid proof of an incomplete input remains incomplete. The circuit may also omit risks that matter economically, such as asset liquidity, legal encumbrance, related-party claims, or withdrawal restrictions.

The right question is not “Does it use ZK?” It is “Which statement does the circuit prove, over which inputs, under which assumptions?”

⚠️ What proof of reserves does not prove

PoR can be technically correct while leaving material risks unresolved. The most common mistake is expanding a narrow result into a broad safety conclusion.

It may not prove complete liabilities

A platform controls the source systems used to construct its customer-liability dataset. Users can check their own inclusion, but outsiders may not be able to confirm that all accounts, affiliates, lending products, pending withdrawals, rewards, derivatives, or other customer claims were included.

The report should define whether liabilities are gross or net, which products are covered, how borrowed assets and negative balances are treated, and whether the same legal entity owes the customers whose assets are counted.

It may not prove assets are unencumbered

On-chain balances do not disclose every off-chain agreement. Assets may be pledged, financed, borrowed for the snapshot, subject to a lien, held for another entity, or operationally unavailable. Some encumbrances can be visible on-chain; many legal claims are not.

The PCAOB’s investor advisory specifically warns that PoR procedures may not reveal whether a crypto entity borrowed assets to appear sufficiently reserved. It also notes that a point-in-time report does not show whether assets were later used, lent, or made unavailable.

It does not prove liquidity

An exchange may hold assets whose market value exceeds covered customer balances yet still be unable to satisfy a rapid wave of withdrawals. Assets can be illiquid, concentrated, staked, locked, bridged, awaiting settlement, or expensive to sell without market impact.

Solvency and liquidity are related but different:

• Solvency: Do available asset values exceed relevant obligations?
• Liquidity: Can the platform deliver the required assets or cash when due?

For the market side of that distinction, CoinQuickly’s crypto market indicators guide explains why one headline signal should not substitute for a multi-factor reading.

It does not prove legal ownership or customer priority

Control of private keys is not the same as legal ownership. Customer recovery can depend on account terms, asset segregation, trust arrangements, custody agreements, bankruptcy law, and the legal entity named in the report.

Even perfect cryptography cannot decide an off-chain legal dispute. Users should check who owes them, which entity holds the assets, and whether customer property is segregated from corporate assets.

It does not prove effective internal controls

A snapshot does not evaluate the full control environment around accounting, treasury, cybersecurity, governance, related parties, valuation, or financial reporting. The PCAOB states that PoR engagements are not financial-statement audits and may provide no assurance beyond factual findings from specified procedures.

It does not prove future safety

PoR is usually dated. Transfers, loans, losses, hacks, liquidations, or withdrawals can change the position immediately afterward. Frequent publication reduces the stale-data window but does not make evidence continuous unless the entire system updates and remains independently verifiable in real time.

Proof of reserves is not automatically an audit

The label on the engagement determines what the practitioner is responsible for concluding. Do not infer “audited exchange” from the presence of an accounting firm’s name.

In an agreed-upon procedures engagement, the practitioner performs listed procedures and reports the results. The reader must decide whether those procedures are adequate for the question at hand. If the procedures verified three wallets but did not test liability completeness or encumbrances, the practitioner’s involvement does not fill those gaps.

Read the report title, professional standard, responsible party, criteria, scope, exceptions, date, and conclusion. Marketing summaries often compress these distinctions.

🔎 How to verify proof of reserves step by step

Verification begins with scope, not with the reserve ratio. Work through the following sequence and stop broadening the conclusion when the evidence stops.

1. Identify the reporting entity and report type

Record the legal entity, platform brand, practitioner, engagement type, reporting date, snapshot time, and publication date. An exchange group may contain several entities, while the report may cover only one.

Check whether the practitioner’s report is hosted or cryptographically signed by the practitioner, not only reproduced by the platform. Confirm whether it is current and whether later reports replaced it.

2. Define the asset scope

List every covered asset and network. Check whether assets are counted in kind or converted into a common currency. If prices are used, identify the valuation timestamp, source, and haircut policy.

Watch for reserves that mix liquid customer assets with platform tokens, thinly traded collateral, staked positions, or assets held through affiliates. A dollar total can conceal asset-by-asset shortfalls that matter when users expect in-kind withdrawals.

3. Define the liability scope

List the products and balances included: spot, margin, loans, futures, staking, rewards, pending deposits, pending withdrawals, and institutional accounts. Determine whether balances are gross, net, or collateral-adjusted.

Ask how negative balances are handled. Netting one customer’s debt against another customer’s withdrawable asset can overstate coverage unless the methodology accounts for collateral quality, enforceability, liquidation costs, and timing.

4. Verify your own inclusion

Download or copy the record ID, leaf data, salt, Merkle path, root, and snapshot balance from the official account interface. Compare the displayed balance with your own records for the exact snapshot time.

Use the platform’s documented verifier or independently recompute the branch. Open-source code is useful because the logic can be inspected, but use the version mapped to the report and obtain it from the authentic repository. A passing result means your record is included in that root; preserve the output and report date.

Kraken’s current documentation, for example, distinguishes in-scope snapshot balances from later trades and out-of-scope assets. Binance’s current methodology combines Merkle inclusion with zk-SNARK constraints and publishes a verifier. These first-party descriptions illustrate verification designs; they are not independent endorsements of either platform.

5. Reproduce on-chain reserve balances

For each disclosed address, inspect the correct blockchain at the stated block height. Verify token contract addresses, native balances, staking or vault positions, and any movements immediately before or after the snapshot.

Do not double-count the same economic asset across a native token, wrapper, bridge receipt, staking derivative, or collateral position. If the report gives only a fiat total without wallet detail, note that independent reproduction is limited.

The live CoinQuickly markets dashboard can provide current market context, but the PoR calculation must use the report’s stated timestamp and pricing method rather than today’s price.

6. Check proof of control

Look for a fresh signed message, witnessed transaction, or practitioner procedure connecting the legal entity to the addresses. A reused address attribution or blockchain analytics label is weaker than a challenge-response test.

For multisignature, MPC, or third-party custody, determine what was actually demonstrated: sole control, joint signing authority, a custodian confirmation, or only address attribution.

7. Investigate availability and encumbrance

Read for liens, pledges, lending, staking lockups, rehypothecation, related-party use, collateral arrangements, and withdrawal restrictions. Ask whether the practitioner tested these conditions or relied on management representations.

No on-chain scan can establish the absence of every off-chain claim. This step may require legal disclosures, audited financial statements, custodian confirmations, regulatory filings, or other evidence outside PoR.

8. Recalculate the ratio consistently

Use like-for-like definitions:

Reserve coverage ratio = eligible, available reserve assets ÷ covered customer liabilities

Match asset and liability timestamps. Apply the report’s valuation rules, then test alternative haircuts for volatile or illiquid assets. Calculate coverage by asset when customers can withdraw in kind; an aggregate dollar surplus can coexist with a shortage in one token.

9. Read exceptions and subsequent events

Search the practitioner’s findings for differences, inaccessible wallets, late confirmations, excluded systems, sampling, reliance on management, or unresolved exceptions. Check subsequent withdrawals, address changes, security incidents, and updated reports.

10. Write a bounded conclusion

State exactly what is verified and what remains unknown. A defensible conclusion sounds like this:

“My covered balance was included in the published Merkle root, the listed wallets held the reported on-chain assets at the snapshot block, and the report describes a reserve surplus under its stated scope. I have not independently verified liability completeness, legal ownership, encumbrances, off-chain assets, or post-snapshot liquidity.”

That is more useful than a binary “safe” or “unsafe” label. CoinQuickly’s framework for comparing cryptocurrencies uses the same discipline: compare defined dimensions and preserve unresolved uncertainty.

🧮 CoinQuickly analysis: when 110% becomes 83.3%

CoinQuickly analysis uses a hypothetical scope test to show why the numerator and denominator matter more than the headline percentage. This is not a claim about any real exchange, report, or customer shortfall.

Assume a platform publishes the following snapshot:

The arithmetic is correct within those stated figures:

$110 million ÷ $100 million = 110%

Now assume a due-diligence review identifies two scope adjustments:

1. $20 million of reported assets is borrowed, pledged, or otherwise unavailable for covered customer withdrawals.
2. $8 million of relevant customer obligations sits outside the report’s liability scope.

The adjusted amounts become:

Adjusted available reserves = $110 million − $20 million = $90 million

Adjusted relevant customer liabilities = $100 million + $8 million = $108 million

Adjusted coverage = $90 million ÷ $108 million = 83.3%

The example does not show that published PoR ratios are wrong. It shows that a ratio answers only the question encoded in its definitions. If the $20 million were demonstrably unencumbered and available, or the $8 million were not obligations of the reporting entity, those adjustments would be inappropriate.

The analytical lesson is repeatable: verify the claim, then challenge the scope. Test asset eligibility, availability, ownership, liability completeness, entity matching, and timing before treating coverage as evidence of solvency.

🚩 Proof-of-reserves red flags

One red flag is not proof of misconduct, but several interacting gaps should reduce confidence. Investigate when you see:

• A reserve percentage without a practitioner’s report, methodology, timestamp, or liability definition
• Wallet balances with no fresh proof linking the addresses to the reporting entity
• Customer inclusion proofs without an aggregate liability total
• A Merkle root with no user verification path or reproducible verifier
• Large platform-token, thin-market, related-party, or illiquid positions counted at full value
• Assets and liabilities valued at different times or under unclear price sources
• Net customer liabilities with little explanation of negative balances and collateral haircuts
• Exclusion of major products, legal entities, networks, or customer groups
• No discussion of liens, borrowing, pledges, custody, or asset availability
• A snapshot taken immediately after large inflows or followed by large outflows without explanation
• “Audited” language when the underlying document is an agreed-upon procedures report
• An old report presented as if it described the current balance sheet
• Repeated publication delays, withdrawn reports, inaccessible verification tools, or unresolved exceptions

Also watch for a mismatch between technical sophistication and disclosure quality. Advanced cryptography can strengthen a narrow assertion; it cannot compensate for an unclear legal entity, undefined liabilities, or inaccessible assets.

A compact proof-of-reserves checklist

Use this checklist before leaving meaningful assets with a custodian.

1. Which legal entity issued the report?
2. What is the snapshot date, time, and block height?
3. Is the document a dashboard, AUP report, attestation, or audit?
4. Which assets, networks, products, and customer groups are covered?
5. Are liabilities gross, net, or collateral-adjusted?
6. Can you verify your own balance in the Merkle root?
7. Can the public reproduce wallet balances at the snapshot?
8. Was control of the wallets independently demonstrated?
9. Are assets unencumbered, liquid, and available for withdrawal?
10. Are off-chain assets independently confirmed?
11. Do asset and liability entities, timestamps, and valuation rules match?
12. Does coverage hold by asset as well as in aggregate?
13. What exceptions or limitations did the practitioner report?
14. How frequently is the process repeated?
15. What evidence exists after the snapshot—especially withdrawal performance?

No checklist can remove custodial risk. It can make the remaining trust assumptions visible.

How CoinQuickly analyzed this topic

Research date: October 10, 2026.

CoinQuickly reviewed primary and first-party materials describing the limits of PoR engagements, Merkle and zero-knowledge methods, customer verification, wallet control, and open-source verification tooling. The PCAOB investor advisory provides the central caution about point-in-time scope, borrowed assets, liabilities, internal controls, and the distinction between PoR and an audit. Vitalik Buterin’s proof-of-solvency analysis supplies the technical separation between proof of assets and proof of liabilities, including Merkle sum trees, negative-balance risks, and ZK approaches. Kraken and Binance materials were used only to describe their stated verification methods and scope disclosures.

For the original scope test, reported reserves are fixed at $110 million and reported covered liabilities at $100 million. The analysis subtracts a hypothetical $20 million of unavailable or encumbered assets and adds $8 million of hypothetical relevant customer obligations outside the published scope. Coverage equals eligible assets divided by relevant customer liabilities. The example excludes taxes, transaction costs, price moves, recovery values, litigation outcomes, and any distinction among customer priority classes.

The scenario is educational. It does not allege that any exchange borrows reserves, omits liabilities, or has the stated coverage. Its purpose is to demonstrate how definitions determine a reserve ratio.

Frequently asked questions

Does proof of reserves prove an exchange is solvent?

Not by itself. Solvency requires sufficiently complete liabilities and assets that are owned, available, properly valued, and legally usable to meet those obligations. Many PoR reports address only part of that chain at one moment.

Does a Merkle proof show that my funds are in a wallet?

It generally shows that your reported account record was included in a committed dataset. The reserve-wallet evidence is a separate part of the process. Both must be connected by a clear methodology and matched scope.

Can an exchange exclude customers from a Merkle tree?

A platform could construct an incomplete dataset. A customer who receives no proof or finds a mismatch can challenge exclusion, which is why broad user participation matters. Individual verification does not independently prove global completeness.

What is the difference between a Merkle tree and a Merkle sum tree?

A standard Merkle tree commits to records and supports inclusion proofs. A Merkle sum tree also commits to balances aggregated through the tree, supporting verification of totals. Its design must prevent negative or malformed balances from understating liabilities.

Do zk-SNARKs make proof of reserves complete?

No. A zk-SNARK can prove that defined computations over committed inputs satisfy a circuit while preserving privacy. It cannot prove facts that were not included in the inputs or constraints, such as undisclosed off-chain liabilities or legal encumbrances.

Does signing a message prove an exchange owns the wallet?

It proves access to the required signing authority at that time. Ownership, customer entitlement, liens, shared control, and asset availability require additional evidence.

Is a proof-of-reserves report the same as an audit?

No. The engagement may be self-published, agreed-upon procedures, or an attestation with a narrow assertion. A financial-statement audit is broader, but even an audit does not guarantee future liquidity or prevent loss.

How often should proof of reserves be updated?

More frequent evidence is generally less stale, but quality matters alongside frequency. A monthly, daily, or real-time dashboard remains limited if liabilities are incomplete, wallets are not controlled by the stated entity, or assets are encumbered.

Should I trust an exchange that publishes proof of reserves?

Publication is a positive transparency input when the method is reproducible and the scope is clear. It should not replace review of withdrawals, legal terms, custody, governance, security, financial condition, and your own concentration risk.

The bottom line

Proof of reserves is valuable when it narrows what users must take on trust. On-chain balances, wallet-control tests, Merkle inclusion, sum commitments, zero-knowledge proofs, and independent procedures can each strengthen a defined claim.

The same evidence becomes misleading when a narrow fact is presented as a universal safety conclusion. Assets can exist without being available. A wallet can be controlled without being unencumbered. Your balance can be included while other obligations are missing. A ratio can be arithmetically correct while the scope is economically incomplete.

Read PoR in layers: claim → scope → assets → liabilities → availability → timing. Verify your own inclusion, reproduce what is public, inspect the practitioner’s exact work, and write down what remains unknown. The best proof of reserves report does not eliminate trust; it tells you precisely where trust still begins.

Disclaimer: The content on this website is for informational and educational purposes only and does not constitute financial or investment advice. The cryptocurrency market involves a high level of risk. Always do your own research (DYOR) before making any decision.