Proof of Reserves Guide: What Exchange Reserve Attestations Prove and Miss

Proof of reserves is a report or cryptographic proof that a crypto exchange or custodian holds assets at least equal to what it owes its customers, and on its own it proves much less than most people assume. A complete proof needs two halves: proof of assets (the platform controls the coins it claims) and proof of liabilities (the customer balances it owes add up to a stated total, with every customer included). Many published "proof of reserves" reports cover only the first half, at a single moment, under procedures the platform chose. This guide explains how Merkle tree and zero-knowledge proofs work, what an accountant's reserve report does and does not cover, and the questions to ask before relying on one. It is written for security, risk and due diligence teams assessing exchanges and custodians, and for anyone evaluating where to hold digital assets.

Key takeaways

• Reserves without liabilities prove nothing about solvency. Showing that an exchange controls a large wallet says nothing about whether it owes more than that; the liability side needs a verifiable customer balance total.
• A Merkle sum tree lets each customer check their own inclusion. The exchange commits to all balances in one root hash and total, and each user verifies that their balance is in it, but the proof is only as strong as the share of users who actually check.
• Zero-knowledge proofs close the privacy and negative balance gaps. A zk-SNARK can prove that every balance is non-negative and that they sum to the declared total without revealing other users' balances.
• Reserve reports are not audits. The US PCAOB's investor advisory says proof of reserve engagements are not audits, are point in time, may not address liabilities or borrowed assets, and should be relied on with extreme caution.
• Proof of reserves cannot see off-chain obligations or controls. Loans, fiat balances, governance and key management sit outside the proof, so it complements, and never replaces, audited financial statements and regulation.

What it is

Proof of reserves (often shortened to PoR) is the practice of a custodial platform publishing evidence that customer assets are fully backed. The term covers very different things:

Proof of reserves is related to, but narrower than, solvency. An exchange can hold every customer coin and still be insolvent if it owes lenders more than its own capital, and an exchange can be solvent overall while lending customer coins out. Proof of reserves answers one question: are the customer balances backed by assets the platform controls at this moment?

How it works

Proof of liabilities with a Merkle sum tree

Vitalik Buterin's 2022 essay "Having a safe CEX: proof of solvency and beyond" sets out the classic technique. The exchange puts each customer's balance, with a salted hash of their identity, into the leaf of a Merkle sum tree. Each parent node holds the hash of its two children and the sum of their balances, so the root carries both a single hash and the total of all customer balances. The exchange publishes the root. Each customer receives a proof (the sibling nodes along the path from their leaf to the root) and can recompute the path to confirm that their balance is included in the published total.

The sum is essential. If an exchange tried to hide a shortfall by adding a fake account with a negative balance, every customer whose path passes through that node would see a negative value and reject the proof. Buterin notes that to get away with it, the exchange would have to hope nobody in that part of the tree checks, which is no better than simply leaving some users out of the tree. That is the core limitation: a Merkle proof only protects customers who verify, and only against omission to the extent that enough of them do.

Proof of assets

The asset side shows that the platform controls on-chain funds at least equal to the liability total. The simplest method is to sign a message with each address's key, or move funds in a transaction at an agreed time. Buterin identifies two practical problems: cold storage, where most customer funds sit in offline wallets that are costly and risky to use for frequent proofs, and collateral dual use, where platforms could pass the same funds between each other to appear solvent at snapshot time. His options include a small set of published long-term addresses, random sampling of many addresses, and more complex zero-knowledge schemes. Fiat balances cannot be proven cryptographically and fall back on bank or auditor attestation.

Zero-knowledge proofs of solvency

A zero-knowledge proof lets the exchange prove a statement about hidden data. Applied here, a zk-SNARK proves that every balance committed in the tree is non-negative and that the balances sum to the declared total, so customers no longer need sibling balances in their proof and nothing about other users leaks. Open implementations exist. Binance's published zkmerkle-proof-of-solvency repository uses Groth16 proofs over the BN254 curve through the gnark library, and its design document describes a "dummy user attack", reported by an Ethereum Foundation researcher, in which fake users with equity in low-value assets could offset debts in high-value ones; the updated design adds collateral fields and ratio tiers to counter it. Summa is an open-source zk proof of solvency protocol on GitHub with a Halo2-based prover, Solidity contracts and a Rust backend. Platforms are listed here alphabetically as examples of published designs, not as a ranking. For the underlying cryptography, see the Zero-Knowledge Proofs Guide.

Accountant reserve reports

Some platforms hire accounting or assurance firms to perform procedures on wallet balances and customer liability data. The PCAOB's March 2023 investor advisory explains that these engagements vary: some are reasonable or limited assurance engagements, others are agreed-upon procedures where management chooses the procedures and the firm reports only factual findings without judging whether they are sufficient. Management also decides whether and how much to publish.

Why it matters

Customers of a custodial exchange are unsecured creditors of a platform that holds the keys. When a platform lends out, pledges or loses customer assets, customers usually discover it only when withdrawals stop. Proof of reserves emerged as an attempt to make that visible earlier. Buterin's essay traces attempts back to 2011, when Mt. Gox moved 424,242 BTC to show it held funds, and his 2022 essay was written in the weeks after the FTX collapse revived demand for cryptographic assurance.

For security and due diligence teams the relevance is practical:

• Counterparty risk: treasury, payments and trading teams holding assets on an exchange need evidence beyond marketing claims. A verifiable liability proof plus audited accounts is stronger than a wallet list.
• Key control evidence: a signed proof of asset control shows that keys exist and are usable, which links to the custody and signing controls covered in the Crypto Exchange Identity and Key Security Guide and the CryptoCurrency Security Standard Guide.
• Breach impact: a theft from hot or warm wallets creates a shortfall. The Bybit hack, where stolen developer session tokens led to a $1.5 billion theft, shows how fast reserves can change, and why a proof from last month says little about today. See also Crypto exchange breaches.
• Regulation: rules such as the EU's MiCA regime require safeguarding and segregation of client crypto-assets, which go further than voluntary proofs. See the MiCA and DORA for Crypto-Asset Service Providers Guide.

Common misconceptions

• "A proof of reserves report is an audit." The PCAOB advisory states that PoR engagements are not audits, are not subject to PCAOB auditing standards or inspection, and give no opinion on whether reserves are adequate or whether the entity is financially stable.
• "If the reserve ratio is above 100%, my funds are safe." A ratio compares proven assets with included liabilities. Excluded products, off-chain debt, fiat obligations and borrowed snapshot assets are all invisible to it, and the PCAOB notes reports may not reveal whether assets were borrowed to appear backed.
• "The proof covers the platform going forward." It is point in time. The PCAOB says such reports say nothing about reserves after the date or whether assets were lent or used afterward.
• "A Merkle proof protects me even if I do not check it." The design relies on users verifying. Accounts that nobody checks, or that were left out, are exactly where a shortfall can hide.
• "Zero-knowledge proofs make it trustless." ZK closes privacy and negative balance gaps, but the inputs still come from the exchange's database. Off-chain liabilities, fiat and governance remain matters of trust, regulation and audit.
• "Proof of reserves tells me about security." It gives no assurance on internal controls or governance, as the PCAOB notes. Key management, access control and incident history need separate assessment.

Related concepts

• Proof of liabilities: the customer balance half of the proof; without it, proof of reserves is just a wallet balance.
• Proof of solvency: the stronger claim that assets exceed all liabilities, not only customer balances. Cryptography can approach it for on-chain items only.
• Customer asset segregation: a legal and operational separation of client assets from the firm's own, so they are protected in insolvency. It is a regulatory control, not a cryptographic proof.
• Stablecoin reserve attestations: issuers publish reports on the reserves backing tokens; the token supply is on-chain, so liabilities are visible, but reserves are fiat and securities that rely on accountants and banks.
• Self-custody: holding keys yourself removes exchange counterparty risk and adds key loss and theft risk. See the Crypto Wallet Security Guide.
• Validiums and non-custodial exchange designs: Buterin's essay describes designs where the operator cannot move user funds without consent, at the cost of user account recovery.

Practitioner checklist

• Demand the liability side: Ask whether the proof includes customer liabilities and how they are committed, because assets alone prove nothing about backing.
• Verify your own inclusion: Check your balance against the published Merkle sum tree root, since a Merkle proof only protects customers who actually verify.
• Prefer zero-knowledge proofs: Favour proofs that show every balance is non-negative and sums to the declared total without revealing other users' balances.
• Check proof of key control: Look for signed messages or transactions from the addresses, not just a wallet list, to show the platform controls the keys.
• Read reserve reports with caution: Treat an accountant's reserve report as point in time and not an audit, as the PCAOB advises, and check who set its scope.
• Ask about off-chain obligations: Confirm how loans, fiat balances and borrowed assets are handled, because the proof cannot see them.
• Pair it with audited accounts: Use proof of reserves alongside audited financial statements and regulation, never as a replacement for them.

Standards and references

• PCAOB: Investor Advisory, Exercise Caution with Third-Party Verification (Proof of Reserve) Reports
• Vitalik Buterin: Having a safe CEX, proof of solvency and beyond
• Binance (GitHub): zkmerkle-proof-of-solvency
• Summa (GitHub): Summa Solvency
• Ethereum Research (GitHub): Merkle sum tree example implementation

Related NHI Mgmt Group resources: Crypto Exchange Identity and Key Security Guide · Zero-Knowledge Proofs Guide · CryptoCurrency Security Standard Guide · Cryptocurrency Scam Awareness Guide