Proof of Reserves vs Proof of Liabilities: Best Epic Guide.
Article Structure

Exchange solvency is simple in theory: assets must meet or exceed liabilities. In crypto, two ideas dominate the audit conversation—Proof of Reserves (PoR) and Proof of Liabilities (PoL). They answer different questions. Put together, they approximate a real solvency check. Pulled apart, they can mislead.
What Proof of Reserves actually proves
Proof of Reserves is a snapshot of assets the exchange controls on-chain or in custody. Typically, an auditor signs messages from wallets, checks balances at a block height, and confirms the exchange can move those coins. Some exchanges publish wallet lists; others use attestations only.
Micro-example: an exchange claims 20,000 BTC in reserve. The auditor verifies digital signatures from cold and hot wallets and reconciles them to blockchain balances at block X. This demonstrates control—not ownership quality, not encumbrances, not whether customer claims exceed that pile.
What Proof of Liabilities captures
Proof of Liabilities is a snapshot of what the exchange owes all customers, net of loans and margin. Because publishing user identities and balances is sensitive, exchanges hash balances into a data structure (often a Merkle tree). Each customer gets a private “leaf” hash to check inclusion without exposing others.
Two details matter: inclusion (your balance is represented) and completeness (no one is excluded to make the liability smaller). Without a strong process for both, PoL can be quietly undercounted.
The solvency gap: Proof of Solvency = PoR − PoL
PoR shows the numerator. PoL anchors the denominator. Put them together and you can compute a coverage ratio: assets divided by liabilities. Above 1.0 suggests solvency at the snapshot; below 1.0 signals a shortfall. Timing, borrowings, and hidden obligations can still distort the picture, so context matters.
How Merkle-based attestations work
Merkle trees let an auditor publish a single root hash representing all user balances while enabling each user to verify their own inclusion. You receive a proof path—sibling hashes from your leaf to the root—and recompute the root. If it matches the published value, your balance is in the set.
That confirms inclusion but not completeness. An exchange could omit some users. Auditors counter this with independent sampling, customer emails to confirm balances, and controls that detect negative-balance masking.
The critical limitations most people miss
Even honest attestations have blind spots. A few are technical; others are behavioral. Knowing them helps you read reports with a clear eye.
Here is a short list of pitfalls that commonly trip up readers and even some platforms.
- Encumbrances: reserves can be pledged as collateral, double-counted across affiliates, or rehypothecated.
- Timing games: borrowing assets briefly to pass a snapshot, then returning them minutes later.
- Liability scope: excluding institutional accounts, negative balances, or off-exchange OTC obligations.
- Valuation: stablecoins off-peg or tokens with thin liquidity overstating asset value.
- Custodian risk: third-party wallets with withdrawal freezes can make “controlled” assets illiquid.
A reliable report addresses each risk head-on: encumbrance confirmations, lookback windows around the snapshot, explicit scope for all account types, conservative pricing, and custodian attestations that funds are unpledged and unrestricted.
A quick comparison
Before weighing trade-offs, it helps to see the core differences at a glance. The table below compares scope, strengths, and failure modes.
| Aspect | Proof of Reserves (PoR) | Proof of Liabilities (PoL) |
|---|---|---|
| Primary question | What assets does the exchange control? | What does the exchange owe customers? |
| Typical method | On-chain wallet verification and signatures | Merkle tree of hashed user balances |
| User verification | Public wallets or signed proofs, no user action needed | Users verify inclusion via proof path |
| Main blind spot | Encumbrances and off-chain assets | Exclusions or manipulated netting |
| Gets you | Asset existence and control | Liability completeness and sizing |
| Needed for solvency | Insufficient alone | Insufficient alone |
True comfort comes from pairing both—and then reviewing the bridging logic that ties them together into a single solvency statement with a clear timestamp and methodology.
What a high-quality audit or attestation includes
The strongest work products are ISAE 3000 or SSAE 18 attestations by a reputable firm, applied to crypto-specific procedures. Labels aside, look for concrete elements, not slogans.
Use the following checklist to gauge quality before trusting an exchange’s claims.
- Scope clarity: assets and liabilities covered, treatment of margin, futures, loans, and affiliate entities.
- Lookback tests: movement analysis before and after the snapshot to catch temporary “window dressing.”
- Encumbrance checks: confirmations from custodians and lenders that assets are unpledged and unreserved.
- Valuation policy: pricing sources, haircuts for thin tokens, and FX conversion assumptions.
- User inclusion controls: procedures that detect omitted or negative-balance accounts.
- Reconciliation: mapping wallets to books and records; handling of deposit addresses and sweep logic.
- Cryptographic proofs: Merkle tree details, hash functions, and instructions for user self-checks.
- Frequency and timing: how often attestations occur and whether they are surprise or scheduled.
If even two of these are missing, treat the result as marketing. A one-page badge without method notes doesn’t merit trust.
Tiny scenarios that reveal the difference
Alice deposits 3 BTC to buy ETH. The exchange shows her balance. PoR alone can look fine if the platform temporarily borrows BTC for the photo. If PoL excludes margin borrowers with negative balances, liabilities shrink on paper and solvency appears better than it is.
Another case: a small exchange lists its top 10 wallets with signatures. Impressive on Twitter. Yet 40% of customer liabilities are USD balances at a weak bank, and a market-making affiliate owes users after a failed strategy. PoR doesn’t catch those off-chain holes; PoL does—if scoped correctly.
What users can do today
Even without deep audit knowledge, a few practical steps reduce risk when you read an exchange’s proof package.
Follow this short process to validate the minimums and avoid common traps.
- Locate the latest attestation date and block height; ignore anything older than 90 days for active trading.
- Verify your Merkle inclusion using the exchange’s tool, then re-check with an independent verifier if available.
- Cross-check published wallets on a blockchain explorer; look for large in/out flows around the snapshot window.
- Read encumbrance language; you want “unencumbered, unrestricted, and beneficially controlled” explicitly stated.
- Compute the coverage ratio if disclosed: assets divided by liabilities. Prefer >100% with sensible haircuts.
These five steps won’t catch every scheme, but they catch the lazy ones. When answers are vague, withdraw or size exposure down.
Emerging improvements worth watching
Zero-knowledge proofs can show an exchange’s liabilities total without revealing any individual balance and can prove no account has been excluded or altered. Multi-party computation can demonstrate control of reserves without exposing keys. Continuous attestations using oracles reduce timing games by publishing moving snapshots.
Expect hybrid systems: on-chain proofs for assets, zk-backed liability attestations, and auditor oversight that tests off-chain obligations and fiat custody. The direction of travel is better math, tighter controls, and fewer excuses.
Practical stance for traders and treasurers
PoR is necessary but not sufficient. PoL is necessary but not sufficient. Together, they form a credible starting point, provided the scope is complete, encumbrances are ruled out, and timing tricks are neutralized. Trust increases with frequency, third-party scrutiny, and user-verifiable cryptography.
Keep balances on-exchange only as long as needed, favor platforms with repeatable, independently tested solvency proofs, and verify your own inclusion every time. In markets that move fast, prudence beats hope.


