Proof-of-Reserves Explained: What Exchanges Publish and Why
A neutral look at Proof-of-Reserves attestations, Merkle-tree audits and what these reports do and don't prove about an exchange's solvency.
What Proof-of-Reserves actually means
Proof-of-Reserves (PoR) is an attestation process where an exchange demonstrates it controls on-chain assets that meet or exceed the balances it owes customers. The goal is transparency: users want assurance that their deposits are not being lent, rehypothecated or otherwise removed from the exchange's custody.
The typical PoR report combines two components. First, a snapshot of wallet balances the exchange claims to control, often supported by signed messages or on-chain transfers proving custody. Second, a cryptographic summary of customer liabilities, usually structured as a Merkle tree so individual users can verify their balance is included without exposing everyone else's data.
What a Merkle-tree audit really shows
A Merkle tree hashes customer balances into a single root value. Each customer receives a proof that lets them confirm their account was part of the sum. If a large enough share of users verifies their proofs, and the sum equals the reported liability, the community gains confidence that the exchange did not omit accounts to make the reserve ratio look healthier.
The mechanism is elegant but partial. It confirms the balance side of the equation; it does not, on its own, prove that the reserve wallets are unencumbered. An exchange could theoretically borrow assets to pass the snapshot, or hold liabilities off-chain that never enter the tree.
Limitations users should understand
PoR reports typically cover a single moment in time. Between attestations, balances can shift dramatically. Some exchanges publish continuous or near-real-time dashboards, which reduces this gap, but the underlying model is still a snapshot rather than an audit of internal accounting.
PoR also focuses on crypto assets. Fiat liabilities, custody arrangements for stablecoin reserves and off-chain lending are not addressed by the on-chain component. Users evaluating an exchange should read the attestation report alongside disclosures about corporate structure, banking partners and regulatory status.
How to read a PoR page critically
Check the date of the latest snapshot and how frequently the exchange refreshes it. Look for the identity of the attesting firm, if any, and whether the report is a full audit or a limited-scope engagement. Confirm the tree covers all customer balances, not just a subset of assets.
Finally, use the individual verification tool if the exchange provides one. A PoR system is only meaningful when users actually verify their own inclusion; the tooling exists to be exercised, not just linked to.