Connect With Us

You are at:

Proof of Reserves Explained: What It Proves and How to Verify It

Balance sheet examined with a magnifying glass on a desk

A Proof of Reserves page can show “101.6% BTC reserves” and still leave the most important questions unanswered.

The percentage is the last line of an evidence packet. I would read the packet backward.

Start with the customer balance, trace it into the liability commitment, trace the reserves to controlled assets, attach both sides to the correct legal entity and snapshot, then ask what remains outside the proof.

Evidence boundary: Proof of Reserves methods, covered assets and report dates change. This article explains how to audit a PoR package, not how to treat one current ratio as permanent evidence of solvency.

Evidence packet item one: prove your own balance entered the liability set

The strongest customer-facing PoR systems let the user verify that an account balance was included in the committed liability dataset.

This can use a Merkle proof, zero-knowledge proof material or another cryptographic commitment.

The first question is deliberately narrow:

Was my in-scope balance represented in the customer-liability set used for this report?

Kraken’s current March 31, 2026 Proof of Reserves page, for example, lets eligible clients verify inclusion of covered balances. That is more informative than a reserve wallet screenshot because it connects the customer to the liability side of the exercise.

It still does not prove every other customer or corporate liability was included.

Evidence packet item two: inspect the liability population

A Merkle root or zero-knowledge commitment is only as complete as the records fed into it.

So after verifying personal inclusion, ask:

  • Which customer products are covered?
  • Which legal entities are covered?
  • Are spot, margin, derivatives, earn or institutional balances included?
  • How are negative balances and customer loans treated?
  • How are pending deposits and withdrawals handled?
  • Are intercompany or affiliate balances present?
  • Can the committed total be reconciled to an internal ledger or assurance procedure?

Cryptography can prove that a calculation over the supplied dataset was performed correctly. It cannot prove that management supplied every economically relevant liability unless the scope and controls address completeness.

Evidence packet item three: identify the reserve assets

Now move to the asset side.

For on-chain reserves, public addresses can demonstrate that assets existed at a snapshot. The provider still has to show that the relevant entity controlled those addresses or had a valid custodial claim on them.

Record:

Reserve fieldQuestion
AssetWhat token, coin, cash or other claim is counted?
QuantityHow much existed at the snapshot?
Address/custodianWhere was it held?
Control evidenceHow did the platform prove control?
ValuationWhat price and timestamp were used?
EncumbranceCould another party have a claim on the asset?
LiquidityCould the asset realistically meet withdrawals under stress?

A wallet balance can be real while the economic claim is encumbered, borrowed or otherwise unavailable to meet customer withdrawals.

Evidence packet item four: attach reserves and liabilities to the same legal entity

This is one of the easiest places for a branded group to create accidental confusion.

An exchange brand can operate through several regulated entities. A reserve wallet owned by one affiliate does not automatically prove that another affiliate’s customer liabilities are covered by the same assets.

The report should therefore identify:

  • the responsible legal entity or entities;
  • which customer accounts belong to that population;
  • which reserve assets are legally attributable to that population;
  • whether affiliates, custodians or omnibus arrangements are involved.

Do not cite a global PoR page as evidence for a local exchange entity unless the report itself places that entity inside the scope.

Evidence packet item five: freeze the timestamp

PoR is normally a snapshot.

Kraken’s current public report identifies March 31, 2026 as its review date and shows reserve ratios above 100% for the covered BTC, ETH, SOL, USDC, USDT, XRP and ADA populations.

That evidence answers a dated question.

It does not say that the same assets and liabilities exist today, tomorrow or during a withdrawal shock.

For every PoR claim, save:

  • snapshot date and time;
  • publication date;
  • covered assets;
  • covered entity;
  • reserve ratio;
  • methodology version;
  • assurance report;
  • your user-verification result where available.

A series of preserved snapshots is more informative than one current badge because it exposes changes in scope and methodology over time.

Evidence packet item six: read the assurance report rather than the marketing label

“Audited Proof of Reserves” is not a complete description.

The underlying engagement can be:

  • a financial-statement audit;
  • an attestation engagement;
  • agreed-upon procedures;
  • another assurance or verification process.

Those engagements answer different questions.

Read:

  1. who performed the work;
  2. which professional standard applied;
  3. which entity and accounts were in scope;
  4. which procedures were performed;
  5. whether liability completeness was tested;
  6. how wallet control was established;
  7. what conclusion, if any, the practitioner expressed;
  8. which limitations were explicit.

The word “audit” on a landing page should never replace the report itself.

Evidence packet item seven: reconcile the ratio yourself

The basic ratio is simple:

Covered reserve ratio = covered reserve assets ÷ covered customer liabilities.

But every word matters.

Covered means the result can exclude something.

Reserve assets raises questions about valuation, liquidity and encumbrance.

Customer liabilities raises questions about product scope, negative balances and completeness.

A 105% result is only stronger than 101% if the two calculations use comparable scopes and asset quality. More percentage points do not repair an incomplete liability set.

Now try to break the proof

A useful PoR review should contain a counter-analysis.

Failure case: borrowed reserves arrive before the snapshot

The assets can be visible on-chain and temporarily present. Subsequent transfers, ownership procedures and recurring reports help test whether the snapshot was window-dressed.

Failure case: liabilities are incomplete

The Merkle root can be cryptographically valid while a product population was omitted upstream.

Failure case: reserves are encumbered

The platform can control an address while another lender or affiliate holds an economic claim against the same assets.

Failure case: asset quality is weak

A thin platform token or related-party receivable can produce a high ratio without providing the same withdrawal liquidity as cash or a highly liquid major asset.

Failure case: legal entity mismatch

Assets and customer claims can sit in different companies under one brand.

If the report does not make these failure cases inspectable, the ratio deserves less weight.

What a Merkle proof actually earns

A Merkle tree compresses many account records into one root hash. A customer can use a Merkle path to verify that their leaf is included in the committed dataset without seeing every other customer’s balance.

That establishes:

  • your supplied record is part of that commitment;
  • changing the record would change the root;
  • the check can preserve privacy across users.

It does not independently establish:

  • that no customer was omitted;
  • that liabilities outside the customer ledger do not exist;
  • that reserve assets are unencumbered;
  • that the business is liquid tomorrow.

The proof is strong evidence about one data-integrity problem. Do not ask it to solve a corporate-finance problem it was not designed to solve.

What zero-knowledge proofs add

Platforms including Binance and OKX use zero-knowledge techniques in their PoR systems to prove properties about committed customer balances without revealing the underlying private account data.

That can improve privacy and enforce mathematical constraints over the liability set.

The same boundary remains: a perfectly valid zero-knowledge proof can prove a statement about an incomplete or wrongly scoped input population.

Read the circuit or methodology description alongside the business scope.

Proof of Reserves and a financial audit answer different questions

EvidenceBest question
User inclusion proofWas my covered balance included?
PoR reserve evidenceDid specified reserve assets exist and appear to be controlled at the snapshot?
PoR liability commitmentWhat defined customer population was committed?
Financial-statement auditAre the entity’s financial statements fairly presented under the applicable accounting framework?
Regulatory/safeguarding disclosureWhat legal, capital or custody rules apply?
Withdrawal testCan this account move assets now?

These evidence types can complement one another. They should not be forced into one “trust score.”

A customer can run a smaller audit

For an exchange that provides user verification, I would do this:

  1. Open the official PoR page directly.
  2. Identify the snapshot date and legal entity.
  3. Confirm the asset/product is in scope.
  4. Verify personal account inclusion using the exchange’s official verification data.
  5. Compare the included balance with the account statement at the snapshot.
  6. Read the reserve ratio and asset composition.
  7. Read the assurance report and methodology.
  8. Check whether prior reports remain available.
  9. Record any products or liabilities explicitly excluded.
  10. Save the result and repeat after the next snapshot.

Never provide a seed phrase or private key to verify an exchange liability. User inclusion verification should not require spending authority over your self-custody wallet.

The question PoR cannot answer

The most important question is:

Can the exchange meet every relevant obligation when it becomes due?

PoR contributes evidence to that question. It does not settle it.

Solvency can depend on corporate debt, legal claims, operating losses, affiliates and obligations outside the customer population. Liquidity can fail even when assets exceed liabilities if the assets cannot be mobilised quickly enough.

That is why the final diligence stack should include legal-entity terms, audited financial information where available, reserve evidence, customer-liability evidence, regulatory disclosures and actual withdrawal functionality.

My conclusion

A strong Proof of Reserves system should make the evidence packet easier to reconstruct, not merely make the ratio larger.

I want to be able to trace:

my balance → liability commitment → reserve assets → control evidence → legal entity → snapshot → assurance scope → exclusions.

If one link is missing, label the gap. Do not let a cryptographic proof lend certainty to a business claim outside its scope.

For exchange-level application, compare the Kraken review and the wider exchange framework.

Primary sources

This article is educational and not investment, legal or accounting advice.

Leave a Comment

Your email address will not be published. Required fields are marked *