📖 PoR without illusions: what it really confirms and where its usefulness ends
Keep this benchmark in mind: PoR only makes sense when reserves ≥ liabilities + a clear methodology + regular updates are present together.
Proof of Reserves (PoR) is cryptographic confirmation that an exchange (or another custodian) controls enough on-chain assets to cover customer balances at the snapshot date. In practical terms, PoR answers the question “are there assets?”, but by itself it does not answer “what is the full amount of debt?”.
Goal: to explain how PoR is built, how it differs from a financial audit, how to verify reserves and liabilities yourself, and which signs most often point to a showcase-style report.
Rule: if a report has no verifiable liabilities or you cannot confirm that your own balance is included, that PoR falls in value to the level of “wallet demonstration”.
Exchanges usually break not because of “news”, but because of a liquidity deficit that remains invisible to users for a long time. That is why PoR is useful only when read critically: liabilities, asset coverage and methodology matter more than “pretty” numbers.
🧩 What Proof of Reserves is and why users need it
You will understand what PoR technically confirms, where it is powerless and how to extract practical value from a report.
Proof of Reserves (PoR) is cryptographic confirmation that an exchange (or another custodian) controls enough on-chain assets to cover customer balances at the snapshot date.
PoR emerged as a response to trust crises: the market needed verifiable evidence instead of declarations. Most implementations use Merkle trees (a hash structure), allowing a user to confirm that their balance is included in the overall liability snapshot without exposing other users’ data.
| What PoR provides | What PoR does not prove |
|---|---|
| On-chain visibility of reserves: addresses and amounts can be checked on the blockchain | Full solvency: off-chain debts and obligations to counterparties may remain hidden |
| The ability to verify balance inclusion (Merkle proof) when implemented correctly | The state after the snapshot: tomorrow reserves and risks may change |
| Operational speed: reports can be published regularly, not once a year | Methodology quality: without clear rules and coverage, PoR easily becomes a showcase |
Benchmark: the minimum honest check always comes down to comparing
reserves ≥ liabilities. If liabilities are not verifiable, trust is built on statements rather than facts.
What this gives in practice
- Transparency: you see reserves on the blockchain and can check addresses and amounts.
- Verifiability: when Merkle proof is available, you can confirm that your balance was included in the snapshot.
- Platform discipline: regular reports raise the cost of manipulation and make a hidden deficit harder to maintain.
- Early signal: PoR helps compare platforms by transparency level without waiting for a full audit.
Bottom line: PoR is a useful control tool, but its value is determined by liabilities, methodology and update regularity, not by a single “reserves” number.
🛠️ How Proof of Reserves works: report steps and verification points
Let’s break PoR down into verifiable elements: what the exchange publishes, what the Merkle root fixes and where your balance is checked.
PoR links on-chain reserves with a liability snapshot so the user can confirm that their balance was included.
The basic criterion is reserves ≥ liabilities at the snapshot date.
Three elements without which PoR does not work
Reserves are assets on published on-chain addresses controlled by the platform.
Liabilities are total customer balances (liabilities) at the snapshot moment.
Merkle tree is a hash structure that fixes the liability set and provides inclusion verification without exposing other users’ data.
-
Publication of reserve addresses. The platform shows storage wallets (BTC/ETH/USDT and so on).
What to check: coverage is explained, addresses are not selective and amounts are easy to verify on-chain. -
Proof of control over addresses. A message is signed with the private keys of the wallets.
What to check: signatures exist and the verification instructions are clear, not just “trust this list of addresses”. -
Liability snapshot and Merkle root. Balances are turned into hashes and rolled up into a Merkle root (the root hash of the snapshot).
What to check: the Merkle root is published, the snapshot date/time is stated explicitly and the liabilities calculation method is described. -
Merkle proof for the user. The client receives a path proof to the root and confirms that their balance is included.
What to check: the tool/script works, the result matches the Merkle root and the balance is reflected correctly. -
Coverage comparison. Reserves on addresses are compared with liabilities from the snapshot.
What to check: liabilities are shown as a number, coverage is calculated transparently and exclusions or assumptions are not hidden.
Mini PoR checklist: (1) addresses + control signatures, (2) Merkle root + snapshot date, (3) working Merkle proof, (4) disclosed liabilities and calculation rules.
AUP: why is this not a “full audit”?
zk/PoL: why are they added to PoR?
Bottom line: PoR is useful only as a bundle of verifiable artefacts: address control,
Merkle root, Merkle proof and transparent liabilities reduced to the criterion reserves ≥ liabilities.
⚖️ PoR vs audit: how it differs from a full solvency review
PoR shows coverage with on-chain assets at the snapshot date, while an audit checks whether the company can withstand all debts and risks.
Proof of Reserves is a point-in-time check: the platform demonstrates control over on-chain assets and compares them with customer liabilities at the snapshot date. This is useful as a transparency signal, but by definition it is not the same as an assessment of financial health.
A solvency audit (solvency audit means the ability to cover all debts) looks more broadly: crypto and fiat, external liabilities, loans and collateral, contingent and off-balance-sheet risks. It is usually performed under IFRS/GAAP (financial reporting standards), requires access to internal data and implies auditor responsibility for conclusions.
The key boundary: PoR answers “are there enough on-chain assets for customer balances right now?”, while an audit answers “has that coverage been eaten by debt, collateral and off-chain obligations?”.
| Parameter | Traditional audit | Proof of Reserves |
|---|---|---|
| Coverage | All assets and liabilities (on-chain + off-chain) | On-chain reserves + customer liabilities |
| Frequency | Usually annually | More often than an audit (depends on platform policy) |
| Verifiability | Trust in the report and auditor conclusions | Verification of artefacts (addresses, signatures, Merkle) |
| Cost/speed | Expensive and slow | Cheaper and faster |
| Off-chain risks | Included (debts, collateral, contingent liabilities) | Usually outside the report |
Important: even an “ideal” PoR does not prove solvency if the company has external debts, collateral or obligations that are not visible on the blockchain and are not disclosed in the report.
Bottom line: PoR is a transparency control tool (assets vs customer balances), while an audit checks solvency as a whole. Reliability starts where PoR is complemented by clear methodology and independent risk assessment.
Liabilities: without the second number, PoR does not work
Read PoR only as an equation: reserves ≥ liabilities at the snapshot date — otherwise it is a showcase.
Proof of Reserves answers the question “are there assets?” — but the more important question for a user is: “are they enough to pay everyone?”. That second question is liabilities — the total amount of customer balances that the platform must cover.
If liabilities are not disclosed or cannot be verified, you do not know whether reserves cover the real debt — even if the on-chain wallets look “large”.
Publishing the full list of accounts is impossible because it would violate privacy. Therefore an “honest” format looks like this: the platform shows the aggregated amount of liabilities and provides a way to make sure that your balance is included in the snapshot (usually through Merkle proof).
- Total liabilities: one clear number per asset (or an explicit asset list without vague “etc.”).
- Snapshot date and time: so the comparison is tied to a specific moment.
- Calculation methodology: what is included/excluded (spot, subaccounts, internal accounts).
- Verification: a working Merkle proof (or equivalent), not “we counted it this way”.
Nuance about margin and loans: with leveraged trading, some users can have negative balances. The methodology must explain how this is handled; otherwise liabilities can easily be made to look “better” on paper.
Bottom line: without provable liabilities, PoR turns into a wallet demonstration and does not support conclusions about coverage.
Red flags: when PoR is a showcase, not a check
Six quick checks to distinguish “proof of coverage” from a pretty reserve showcase in one minute.
Quick filter (15 seconds): a report can be considered “working” only if it contains:
- liabilities as a number (by asset / explicit asset list, without vague “etc.”);
- snapshot date/time + a list of reserve addresses with proof of control;
- verification of inclusion (Merkle proof or equivalent) for your balance;
- methodology: what is included/excluded and how margin, loans and negative balances are handled.
Not every PoR is equally useful. Below are typical ways reports bypass the core meaning, after which the report should be read as marketing, not as proof of coverage.
“Reserves only” without liabilities
- What is wrong: addresses and amounts are present, but the amount owed to customers is not disclosed/proven.
- Normal standard: liabilities as a number + coverage rules (spot/subaccounts/internal accounts) and accounting rules.
Partial asset coverage
- What is wrong: one or two coins are checked while everything else stays “off camera”, creating a transparency effect.
- Normal standard: explicit asset/network list + coverage share, so it is clear what exactly was checked.
No user verification
- What is wrong: you cannot confirm that your balance was included in the snapshot.
- Normal standard: Merkle proof (or equivalent) + clear verification instructions + reproducible result.
Foggy methodology
- What is wrong: it is unclear which wallets were included and how margin, loans or negative balances were counted.
- Normal standard: assumptions and exclusions are written explicitly; liabilities calculation rules are verifiable.
One-off campaign instead of practice
- What is wrong: the report appears “during panic” and then is not updated for months.
- Normal standard: regular publication + comparable methodology from report to report (change history is visible).
Weak or opaque auditor
- What is wrong: a “procedures were checked” format without clear boundaries and responsibility for conclusions.
- Normal standard: who checked, what exactly was checked and which limitations are stated directly in the document.
Bottom line: strong PoR is
How to check PoR yourself: 7 steps without “magic”
In 2–3 minutes, distinguish verifiable coverage at the snapshot date from a “showcase” with wallets and numbers.
Minimum required for conclusions: there are liabilities and there is verification (Merkle proof or equivalent). Without either point, PoR remains a declaration.
- Open the PoR/Transparency page. Look for the official section on the exchange website, not retellings.
- Check the snapshot date and time. Without them, the report cannot be correctly compared with on-chain data.
- Clarify coverage. There must be an explicit list of assets/networks, without vague “etc.”.
- Open reserve addresses. Addresses must be public so they can be checked in a block explorer.
- Compare balances by address. For key assets, compare on-chain amounts with report numbers at the snapshot date.
- Find liabilities and coverage. The report must contain numbers and a comparison rule:
reserves ≥ liabilities. -
Verify inclusion of your balance. Use Merkle proof (or an analogue) and make sure your account is included.
Additionally: look at publication regularity and methodology clarity (what is included/excluded, how margin and loans are handled).
If there are no liabilities or no balance-inclusion check, this is not proof of coverage.
Bottom line: a working PoR check = date + addresses + liabilities + your Merkle proof. Everything else is a bonus, not the basis for trust.
PoR examples: range of approaches and typical differences
Many platforms “have” PoR. The substance is in the format: asset coverage, provable liabilities and real verification for the user.
🏛️ Major CEXs and “partial PoR”
They usually start with one or two assets: it looks “transparent”, but the full picture may remain off camera.
- They publish: reserve addresses + snapshot date + report for selected assets.
- Where it becomes a showcase: no liabilities number or incomplete asset/network coverage.
- What to check: the asset list and coverage share + whether liabilities exist and how they are confirmed.
Main point: “large wallets” without provable liabilities are a demonstration, not a check.
🗓️ Exchanges with regular updates
The value is not in a one-time number, but in repeatability: the same methodology and scheduled updates.
- They publish: reports on key assets + a verification tool (Merkle proof/equivalent).
- Where it becomes a showcase: the liabilities methodology is vague (margin/loans/negative balances are not explained).
- What to check: whether Merkle verification is reproducible + whether address ownership signatures and clear exclusions exist.
Main point: regularity works only together with a clear methodology; otherwise it is a “serial showcase”.
🧷 The “liabilities-first” approach
Emphasis on liabilities is a strong signal, but it does not help if the reserve set is disclosed only partially.
- They publish: liabilities calculation rules + confirmation that edge cases are fully included.
- Where it becomes a showcase: liabilities look convincing, while reserves by asset/network are not fully covered.
- What to check: the liabilities ↔ reserves link for each asset and protection from snapshot-date manoeuvres.
Main point: strong liabilities without a complete reserve set do not answer “will there be enough to pay out?”.
🧾 Stablecoins and reserve attestations
This is often an accounting attestation that “reserves ≥ issued supply”, not user-level on-chain verification.
- They publish: a reserve backing report + reserve composition + date/period.
- Where it becomes a showcase: weak user verifiability on-chain and many methodology assumptions.
- What to check: report frequency + liquidity/quality of reserve composition + verification limitations stated directly in the document.
Main point: attestation is useful, but it is not Merkle PoR: trust depends on report quality and limitations.
🧭 Criteria for quality PoR: how to distinguish transparency from a showcase
Check six points: if a report fails at least two, it is better to treat PoR as a showcase rather than proof of coverage.
Quick filter: if there are no liabilities as a number and no way to confirm inclusion of your balance (Merkle proof/equivalent), this is a “wallet demonstration”, not verifiable PoR.
Report quality checklist:
- Coverage: for each key asset, the report shows reserves ≥ liabilities + coefficient at the snapshot date/time.
- Liabilities: liabilities are disclosed as a number and can be confirmed (Merkle proof/zk/external control), not “we counted it this way”.
- Reserves: a reserve set (addresses) is published and control is proven by signature; there are no “selective wallets” without coverage.
- Methodology: what is included/excluded (spot, margin, loans, subaccounts, negative balances) and the rules for calculating the total.
- Regularity: there is publication history and report comparability, not a one-off “trust snapshot”.
- Privacy: verification of your own balance without exposing other users’ data (Merkle/zk) + reproducible result.
Bottom line: strong PoR is liabilities + verifiability + methodology + regularity, not a “pretty reserves number”.
PoR limitations: which risks remain even with a good report
PoR is a check at the snapshot date. It helps filter out weak transparency, but it does not replace solvency “as a whole”.
- Snapshot in time: the report fixes “the state now” and does not guarantee that coverage will remain tomorrow. Value comes from regular updates and comparable methodology from report to report.
- Off-chain risks: loans, collateral, legal claims and obligations to counterparties can sit outside the report — PoR does not show them by definition.
- Manoeuvres around the snapshot date: under weak controls, temporary “top-ups” of reserves for the check are possible. Only transparent methodology and observation of movements before/after the date reduce this risk.
- Implementation quality: if it is unclear what is included/excluded (margin, loans, negative balances, subaccounts), numbers can be “improved” without direct fraud — simply through assumptions.
- False sense of safety: PoR is a control layer, not insurance. It does not protect from hacks, management mistakes or operational failures.
How to read this practically: treat PoR as a filter for transparency quality, not as “permission to keep everything on an exchange”.
- Watch the trend: regularity, publication history, the same calculation rules.
- Look for boundaries: what exactly is not covered by the report (assets, networks, account types).
- Check the context: reputation, incidents, speed of risk communication.
While assets are held on an exchange, you depend on its processes and controls.
PoR reduces the risk of a hidden funding gap, but it does not cancel the principle
Bottom line: strong PoR helps verify coverage at the snapshot date, but it does not cover off-chain debts, “manoeuvres” or execution risk — use it as a control tool, not as a guarantee.
Frequently asked questions about PoR: how to read reports
Quick answers to help you distinguish verifiable PoR from a showcase: what counts as normal and what to check by hand.
What are Agreed-Upon Procedures (AUP) and why are they not a “full audit”?
Why are zk-SNARK and Proof of Liabilities (PoL) added to Proof of Reserves?
How do I check that my funds are included in PoR?
Why are liabilities needed if reserve addresses are visible?
Can PoR be trusted without an auditor?
What should I do if an exchange does not publish PoR?
Final conclusion: how to use PoR in risk management
PoR is not a guarantee, but a verifiable quality signal. Use it as an exchange filter and a rule for custody limits.
Proof of Reserves is a check at the snapshot date: it shows on-chain reserves and stated coverage of customer liabilities. Practical value appears only when liabilities can be confirmed (not just wallets seen) and the calculation methodology is clear: what was included, what was excluded and how edge cases were handled.
At the same time, PoR does not cover off-chain risks: debts, collateral, legal claims and management mistakes can exist in parallel with an “ideal” report. So the working model is simple: keep only operating amounts on an exchange, choose platforms with regular updates and reproducible verification (Merkle/equivalent), and treat any vague wording in the report as a minus to the trust limit.
Main point: PoR becomes protection only when it is verifiable: liabilities, methodology and regularity matter more than any “checkbox” in a press release.