How to verify if an exchange has Proof of Reserves?

Understanding Proof of Reserves

1. Proof of Reserves (PoR) is a cryptographic audit mechanism that demonstrates an exchange holds sufficient on-chain assets to cover all user balances.

2. It relies on public blockchain data, Merkle tree structures, and signed attestations from independent auditors or the exchange’s own multi-signature wallets.

3. A valid PoR report must include a snapshot time, a complete list of wallet addresses controlled by the exchange, and a matching liabilities calculation derived from internal user balance records.

4. The exchange’s private keys are never exposed; instead, they sign a message committing to the total asset value at the time of the snapshot.

5. Users can independently verify the inclusion of their account in the Merkle tree using open-source tools or third-party verifiers like Arkham or Chainalysis Explorer.

Key Components of a Genuine PoR Report

1. A timestamped cryptographic signature issued by the exchange’s cold wallet, linking the reserve balance to a specific block height.

2. A full list of custodial addresses with corresponding balances, published as a JSON or CSV file and hosted on IPFS or a tamper-evident CDN.

3. A liabilities dataset—often anonymized and hashed—allowing users to confirm their balances are included without revealing identity or exact amounts.

4. An independent attestation statement from a reputable auditor, detailing methodology, scope limitations, and verification steps taken.

5. A reconciliation table showing net asset value (NAV), segregated by asset type, alongside the total user liability figure, with any shortfall clearly disclosed.

Red Flags in PoR Documentation

1. Absence of a verifiable cryptographic signature tied to a specific block hash and timestamp.

2. Wallet addresses listed without transaction history links or balance proofs—only static screenshots or unverifiable PDFs.

3. Liabilities data presented as aggregated totals without supporting structure, hashing, or inclusion proofs for individual accounts.

4. Claims of “100% reserves” without specifying whether it includes uncollateralized loans, staking derivatives, or synthetic assets.

5. Delayed publication—more than 72 hours after the claimed snapshot time—or inconsistent frequency across reporting periods.

On-Chain Verification Steps

1. Locate the exchange’s official PoR announcement and extract the signed message, public key, and block height reference.

2. Use Etherscan, Blockchair, or Mempool.space to query each wallet address and confirm its balance matches the reported value at the stated block height.

3. Download the Merkle tree root and leaf set, then run open-source verification scripts (e.g., those maintained by the PoR Working Group on GitHub) to validate inclusion proofs.

4. Cross-check liabilities figures against known on-chain stablecoin minting data, especially for USDT or USDC, to detect mismatched supply versus reported reserves.

5. Search blockchain explorers for inter-wallet transfers occurring immediately before or after the snapshot—these may indicate balance manipulation or wash movements.

Frequently Asked Questions

Q: Can an exchange fake a Merkle root?Yes—if they control both the liabilities dataset and the wallet balances, they can generate a consistent but misleading root. Independent hashing of user balances by third parties prevents this.

Q: Does Proof of Reserves guarantee solvency?No. It confirms asset custody at a moment in time but does not reflect liquidity, loan exposure, or off-chain obligations such as futures liabilities or margin debt.

Q: Why do some exchanges publish PoR only for BTC and ETH but omit stablecoins?Stablecoin reserves often involve off-chain banking relationships or tokenized treasury bills. Publishing those details may breach confidentiality agreements or expose regulatory risk.

Q: Is a real-time PoR possible?Not practically. Real-time updates would require constant re-signing and re-publishing of Merkle roots, introducing latency and coordination overhead. Most credible implementations use hourly or daily snapshots.