Proof of Reserves Explained: Merkle Trees, Audit Limitations, and Verifying Exchange Solvency
Learn how Proof of Reserves (PoR) uses Merkle trees and ZK-proofs to verify exchange solvency, understand audit limitations, and self-verify your account balance.

On this page
Quick read
Proof of Reserves (PoR) is a cryptographic audit method used by centralized exchanges to demonstrate that they hold 100% of user asset deposits. By combining on-chain wallet signatures with Merkle tree data structures, PoR allows users to independently verify that their account balances are backed 1:1.
What to remember
- 1:1 Collateral Verification: Proof of Reserves provides mathematical evidence that a centralized exchange holds sufficient digital assets to match all user account liabilities.
- Merkle Tree Self-Verification: Cryptographic Merkle trees allow individual users to check that their specific account balance was included in the exchange's audited balance snapshot.
- ZK-SNARK Privacy Upgrades: Modern PoR frameworks use Zero-Knowledge proofs to prove solvency and non-negative balances without exposing sensitive user financial data.
- The Liabilities Blind Spot: PoR proves on-chain asset possession, but cannot easily detect off-chain unrecorded corporate debts, encumbered loans, or hidden liabilities.
- Self-Custody Remains Superior: While PoR increases exchange transparency, keeping assets in a self-custody hardware wallet eliminates third-party credit risk entirely.
What is Proof of Reserves (PoR)?
Following the high-profile collapse of centralized crypto exchange FTX in late 2022—where billions of dollars in user funds were secretly rehypothecated and lost—the digital asset industry demanded radical financial transparency.
Traditional financial institutions rely on quarterly paper audits from accounting firms. In cryptocurrency, exchanges introduced Proof of Reserves (PoR)—an open, cryptographic auditing framework that enables users to verify exchange solvency directly on the blockchain.
At its core, a complete Proof of Reserves assessment requires verifying two fundamental components:
On-Chain Reserve Assets ≥ Total Customer Liabilities
- On-Chain Reserve Assets: Publicly verifiable cryptocurrency balances held in cold and hot wallet addresses owned by the exchange.
- Total Customer Liabilities: The sum total of all user account balances deposited on the exchange platform.
| Dimension / Feature | Traditional Financial Audit | Cryptographic Proof of Reserves |
|---|---|---|
| Verification Frequency | Annual or quarterly paper reporting | Monthly or real-time cryptographic snapshots |
| User Verification | Users must trust external auditing firm text | Individual users self-verify using cryptographic Merkle hashes |
| Transparency Medium | Private accounting ledgers & PDF reports | Public blockchain transactions & cryptographic proofs |
| Off-Chain Debt Coverage | High (Reviews corporate contracts & bank loans) | Low (Primarily tracks on-chain crypto wallet balances) |
How Merkle Tree cryptographic proofs work
To prove customer liabilities without publishing every user's private financial data, exchanges utilize a (a binary hash tree).
The 4-step Merkle Tree verification process
- Hashing User Balances: The exchange hashes each user's unique account ID and current balance into an individual leaf node (e.g.,
Hash(User_ID + Account_Balance)). - Building the Tree: Neighboring leaf nodes are paired and hashed together iteratively, climbing upward layer-by-layer until generating a single overarching cryptographic fingerprint: the Merkle Root.
- Signing On-Chain Wallet Balances: The exchange signs a public message using its cold wallet private keys to prove control over the on-chain addresses containing user assets.
- User Self-Verification: The exchange provides each user with a cryptographic Merkle Path (or record hash). By entering this hash into a verification tool, the user can mathematically confirm that their balance was included in the overall Merkle Root calculation.
The evolution: Zero-Knowledge (ZK-SNARK) Proof of Reserves
Early implementations of Merkle tree PoR carried privacy limitations: malicious actors could analyze tree branches to infer an exchange's total user base or estimate competitor balances.
To solve this, modern exchanges (such as Binance, OKX, and Bybit) upgraded their frameworks using Zero-Knowledge proofs (ZK-SNARKs):
- Non-Negative Balance Proof: ZK-SNARKs allow the exchange to mathematically prove that no user account balances were altered to negative values (which could artificially shrink total liabilities) without revealing individual account figures.
- Complete Privacy Protection: Users verify their exact inclusion, while third parties only see a zero-knowledge proof confirming that Total Assets ≥ Total Liabilities.
Critical limitations of Proof of Reserves
While Proof of Reserves is a massive step forward for exchange transparency, it is not a perfect guarantee of financial health. Investors must understand its inherent limitations:
1. The off-chain liabilities blind spot
PoR proves that an exchange controls 100,000 BTC in on-chain wallet addresses. However, it cannot easily detect off-chain liabilities—such as unrecorded bank loans, private credit lines, or corporate guarantees pledged to third parties. If an exchange pledged its Bitcoin as collateral for an off-chain fiat loan, PoR will still display the Bitcoin in the wallet address.
2. The temporary borrowed funds trap
Without continuous, real-time auditing, an exchange could theoretically borrow $500 million from a market maker right before a scheduled monthly PoR snapshot, take the balance snapshot, and return the borrowed funds minutes later.
3. Fiat reserves are excluded
PoR frameworks only track digital assets (like BTC, ETH, and USDT) on public blockchains. Fiat currency reserves held in traditional commercial bank accounts (like USD, EUR, or GBP) cannot be verified via Merkle trees and still require traditional auditing.
Frequently Asked Questions
1:1 reserve backing means that for every 1 BTC deposited by users on an exchange, the exchange holds at least 1 BTC in its cold and hot wallet addresses, with zero fractional reserve lending.
A Merkle tree converts your user ID and account balance into an encrypted cryptographic hash. Other users can verify the overall tree root without viewing your name, email, or specific asset balances.
Faking a PoR audit is extremely difficult because users can independently verify their own inclusion in the Merkle root. However, exchanges can manipulate audits by omitting off-chain liabilities or temporarily borrowing funds for the snapshot.
Proof of Reserves provides automated, on-chain cryptographic proof of digital asset holdings. Traditional audits inspect paper ledgers, legal liabilities, bank accounts, and corporate debt structures.
ZK-SNARKs enable exchanges to mathematically prove that total reserves cover all liabilities without revealing sensitive user balance data or allowing competitors to scrape account metrics.
No. Proof of Reserves increases exchange transparency, but keeping your crypto in a self-custody hardware cold wallet eliminates exchange counterparty risk entirely.
Sources and further reading
Primary cryptographic solvency and proof of reserves research:
This article is educational. It is not financial or accounting advice. Exchange solvency parameters and audit methodologies change over time. Verify live proof of reserves data on your exchange portal before depositing funds.