Proof of reserves explained: what it can show—and what it cannot prove

Direct answer: proof of reserves can provide evidence about specified assets, account balances or wallet control at a stated time. It does not, by itself, prove that an exchange is solvent, liquid, safe, compliant, well governed or able to return every customer's assets on demand.

To read a proof-of-reserves disclosure, identify:

1. the exact entity;
2. the snapshot date and time;
3. the assets and customer balances in scope;
4. how wallet ownership or control was tested;
5. how liabilities were assembled;
6. whether your balance was included;
7. who performed which procedures;
8. what the report expressly excludes;
9. what could change after the snapshot.

This article is educational, not financial, legal, accounting or investment advice. Nerd Mango does not endorse an exchange, token or custodian and does not provide a solvency or safety verdict.

The mental model: seven separate questions

The mistake is collapsing all seven questions into “reserves verified”.

What “proof of reserves” usually contains

A common design has three components.

1. Asset evidence

For on-chain assets, a disclosure may publish wallet addresses and balances. A third party may ask the entity to sign a message with the private key or move a small amount to demonstrate control.

This can support a narrow statement: the entity controlled a key associated with the tested address at the test time, and the blockchain showed a balance. It does not automatically show who legally owns the assets, whether they are pledged, whether another party can seize them or whether they were borrowed for the snapshot.

2. Liability or customer-balance evidence

An exchange may aggregate customer balances into a Merkle tree. A Merkle root is a compact cryptographic commitment to the underlying entries. A customer receives a path or leaf that can show their entry contributed to that root without revealing every other balance.

An inclusion proof answers “is this entry part of this committed data set?” It does not, by itself, prove that the data set contains every customer, every product, every negative balance or every off-chain obligation.

Some systems add a zero-knowledge proof to support statements about aggregate balances without exposing individual accounts. The usefulness still depends on the statement proved, the inputs and the code or process that created them.

3. A comparison

The disclosure compares in-scope assets with in-scope customer balances and may report a ratio.

in-scope reserve ratio = measured in-scope assets ÷ measured in-scope customer balances

That ratio is a derived calculation with a defined scope. It is not the company's balance sheet and should not be renamed “solvency ratio”.

What a user-level inclusion check actually proves

Kraken's current proof-of-reserves page says its accountant takes an anonymised snapshot of in-scope balances, builds a Merkle tree, tests digital signatures for on-chain addresses and compares those balances with the client balances represented in the tree. It lets a client check whether their balance was included for the snapshot.

The same page says the verification reflects only the account's balances in the in-scope assets at the review time; it does not reflect later trades, transactions or out-of-scope assets.

That is the right reading:

• Supported: my stated in-scope balance was included in the committed snapshot.
• Not supported: every liability was included; assets remained available later; the exchange is solvent; I will be repaid in an insolvency.

Binance's current educational disclosure describes Merkle trees and zero-knowledge proofs and acknowledges point-in-time and off-chain-liability limitations. It is an exchange's description of its own method, not independent proof that every implementation assumption is correct.

OKX publishes wallet addresses and describes monthly proofs using cryptographic structures. Again, the disclosure is evidence about what OKX says it publishes and how its method is described; it is not Nerd Mango verification of the balances.

Audit, assurance, attestation and agreed-upon procedures

These terms are not synonyms.

• A financial-statement audit expresses an opinion on financial statements prepared against an accounting framework.
• An assurance engagement evaluates defined subject matter against defined criteria and may provide limited or reasonable assurance, depending on the standard and engagement.
• An attestation engagement is a broad category in which a practitioner reports on subject matter or an assertion.
• Agreed-upon procedures (AUP) report factual findings from procedures agreed with specified parties. The practitioner does not express an assurance conclusion on whether the procedures are sufficient.
• A PoR report is a market label. Its evidential value depends on the exact scope, criteria, procedure and report—not the label.

The IAASB's ISAE 3000 (Revised) covers assurance engagements other than audits or reviews of historical financial information. Merely citing a recognised standard is not enough; the reader must identify whether the report actually says it was performed under that standard, the assurance level, criteria, intended users and conclusion.

The PCAOB's investor advisory warns that PoR engagements are not PCAOB audits and may provide no meaningful assurance to investors. It says such reports may not address liabilities, customer rights, borrowed assets, post-snapshot use, internal controls or governance.

The PCAOB also explains that in an AUP engagement, management determines the procedures and the provider reports findings without representing that those procedures are sufficient.

The annotated report checklist

Use this on any PoR report.

A. Entity and legal scope

• What exact legal entity is named?
• Does the website brand operate through several entities?
• Which customers, countries and products belong to the named entity?
• Is the custodian itself, an affiliate or another party holding the assets?

Stop if: the report names a brand but not the legal entity or covered customer population.

B. Date and period

• Is this a point-in-time snapshot or a period?
• What is the timestamp and timezone?
• When was the report issued?
• How old is it now?
• Were later events considered?

Label: a March balance is not evidence of an August balance.

C. Assets in scope

• Which tokens, fiat currencies and other assets are included?
• How are prices or conversion rates determined?
• Are staking, lending, margin, derivatives and wrapped assets included?
• Are assets held with third-party custodians covered?
• Is wallet control, legal ownership or both tested?
• Are encumbrances, liens, pledges or borrowed assets addressed?

D. Liabilities in scope

• Are all customer balances included or only named products?
• How are negative balances and margin positions treated?
• Are institutional, affiliate and omnibus accounts included?
• Are fiat liabilities included?
• Are operating debt, taxes, loans, legal claims and other corporate liabilities excluded?

If the disclosure covers customer balances but not corporate liabilities, call them in-scope customer balances, not total liabilities.

E. Inclusion and privacy method

• Can a user verify their own leaf or record?
• Does the tool show the exact snapshot and asset?
• What happens to zero or negative balances?
• Is the verification code published?
• Does the user need to expose sensitive account data?

Normal account authentication may occur only in the exchange's known official app or domain. Never give a third-party accountant or inclusion-verification tool your password, MFA code, seed phrase, private key or remote access.

F. Practitioner and standard

• Who performed the work?
• Are they independent of the exchange?
• What professional licence or oversight applies to this engagement?
• Is it audit, reasonable assurance, limited assurance, AUP or another procedure?
• What criteria were used?
• What exact conclusion or findings are reported?
• What restrictions apply to distribution or use?

Do not upgrade “accounting firm involved” into “audited exchange”.

G. Exceptions and exclusions

Read the notes before the ratio:

• excluded assets;
• excluded entities or products;
• incomplete customer participation;
• management-provided data;
• no control testing;
• no legal-ownership conclusion;
• no subsequent-events work;
• no solvency conclusion.

An exclusion is not a footnote to hide; it defines what the result means.

Evidence-strength ladder

This is a Nerd Mango editorial framework, not an accounting standard.

Do not total these levels into a numerical safety score. Evidence can be strong in one dimension and missing in another.

Why asset existence is not solvency

Solvency depends on the complete financial position and legal definitions, not only selected customer assets and balances. The PCAOB's attestation interpretation says practitioners generally should not provide assurance on defined matters relating to solvency, including ability to pay debts as they mature, because of legal interpretation and criteria problems.

A simplified example:

• Exchange shows 102 units of in-scope crypto assets.
• It shows 100 units of in-scope customer balances.
• The PoR ratio is 102%.

That result says nothing by itself about:

• loans or tax liabilities;
• legal judgments;
• inaccessible or pledged assets;
• withdrawal liquidity;
• operational losses;
• assets or customers outside the test;
• custody rights in insolvency.

Therefore “102% PoR” must not become “2% solvent buffer”.

Liquidity, control and legal protection are separate

An asset can exist and still be hard to realise quickly. It can be controlled by a wallet key and still be legally disputed. A customer balance can be included in a Merkle tree and still lack statutory compensation protection.

MiCA's EU custody rules illustrate the difference. Article 70 requires crypto-asset service providers holding client assets to make arrangements to safeguard client ownership rights, especially in insolvency, and to prevent use for the provider's own account. Those are legal and operational duties, not outputs of a generic Merkle proof.

MiCA Article 36 separately imposes reserve, segregation, liquidity-risk and audit requirements on issuers of asset-referenced tokens. That regime concerns a specific regulated token category and must not be applied automatically to an exchange's general PoR.

A safe reader workflow

1. Confirm the report URL through the exchange's official site.
2. Record the legal entity, report date and issue date.
3. Download or preserve the report and methodology.
4. List included and excluded assets, products and customer groups.
5. Identify whether liabilities mean customer balances or all liabilities.
6. Use the exchange's known official site or app to begin the inclusion flow. Authenticate only there; give any separate accountant or inclusion tool only the published identifier or proof material the official method specifies—not your password, MFA code, seed phrase or private key.
7. Read the practitioner's report—not only the exchange summary.
8. Record assurance level, criteria, procedures and exclusions.
9. Check licensing and custody terms with the relevant regulator.
10. Treat UNKNOWN as unknown.
11. Diversify operational risk according to your own needs; do not use PoR as a sole safety decision.
12. Refresh after every new report, methodology change, enforcement event, withdrawal restriction or material incident.

Security stop: stop if a third-party accountant or inclusion tool asks for a password, MFA code, seed phrase, private key, remote access or payment. Normal login belongs only on the exchange's known official app or domain; the separate inclusion check should not require control of your wallet or account credentials.

Publication and commercial controls

This article must remain:

• informational only;
• NO ADS in urgent-risk or exchange-failure contexts;
• free of exchange affiliate links, token promotions and yield advertising;
• free of solvency, safety, compliance and suitability verdicts.

If a future version evaluates a named report and a material accounting, assurance, legal or financial-risk interpretation remains unresolved after primary-source review, escalate that specific issue to a qualified reviewer. Do not impose or claim a blanket specialist approval that did not occur.

Recommendation

Use PoR as one evidence layer.

A strong disclosure makes it possible to identify the entity, verify your account's inclusion, inspect the asset evidence, understand the customer-balance methodology, read the independent report and see every exclusion. Even then, combine it with custody terms, regulatory status, liquidity, governance, financial statements and operational history.

The correct conclusion is often:

“This evidence supports a defined asset-and-balance statement at a defined time. It does not establish solvency or customer safety.”

Sources

• W3-S01 — PCAOB investor advisory on proof-of-reserves reports
• W3-S02 — Kraken proof-of-reserves methodology and current snapshot
• W3-S03 — Binance proof-of-reserves explainer
• W3-S04 — OKX proof of reserves
• W3-S05 — IAASB ISAE 3000 (Revised)
• W3-S06 — PCAOB interpretation on matters relating to solvency
• W3-S07 — MiCA Article 70: safeguarding client crypto-assets
• W3-S08 — MiCA Article 36: reserve of assets for asset-referenced tokens