What Is Proof of Reserves? Merkle Trees and Exchange Solvency
Proof of reserves is a check that a crypto exchange holds enough assets to cover customer balances. How the Merkle tree commitment works, how to verify reserve addresses on-chain yourself, and what the method still cannot prove.
By the BitcoinDatabase team
July 2026 · 9 min read
The short answer
Proof of reserves is a check that a crypto exchange or custodian holds enough assets to cover what it owes customers. It has two halves: the reserves, which are on-chain balances at addresses the platform controls, and the liabilities, which are customer balances committed to a Merkle root or a zero-knowledge proof so each user can verify their own account was counted without seeing anyone else's.
Proof of reserves went from a niche idea to an industry expectation after 2022, when several platforms turned out to be lending or losing customer assets they claimed to be holding. The pitch is simple: instead of asking people to trust a balance sheet, publish something they can check themselves against a public blockchain. The execution is where it gets interesting, because half the problem is cryptographically clean and the other half is not.
What is proof of reserves in crypto?
Proof of reserves is a periodic, publicly verifiable demonstration that a custodian's assets are at least equal to its customer liabilities. In its usual form, the platform publishes a set of on-chain addresses it controls, publishes a cryptographic commitment to the full list of customer balances, and lets anyone total the first and compare it to the second. If reserves are greater than or equal to liabilities, the platform is solvent at that moment for that asset. The result is often presented as a reserve ratio, where anything at or above 100 percent means fully backed.
How does a Merkle tree proof of reserves work?
Every customer balance is hashed into a leaf. Pairs of leaves are hashed together, then pairs of those hashes, level by level, until the whole customer list collapses into one hash called the Merkle root. The platform publishes only the root. To check your own account, you request your Merkle proof, which is the short list of sibling hashes along the path from your leaf to the root, then recompute the root yourself. If it matches the published one, your balance was included in the total. If the platform tried to shrink anyone's balance to make the books look better, the root changes and the check fails.
The privacy property is the reason this design won. You verify inclusion without seeing any other customer's balance, and the platform does not have to publish a customer list. Some exchanges have gone further and wrap the whole thing in a zero-knowledge proof, which additionally proves that no leaf carried a negative balance, closing a hole where a platform could offset real liabilities with fake negative accounts.
| Piece | What it proves | Who can check it |
|---|---|---|
| Reserve address list | How much the platform holds on-chain | Anyone, from public chain data |
| Signed message or test spend | That the platform controls those keys | Anyone, if published |
| Merkle root of balances | Total liabilities, tamper-evident | Each customer, for their own leaf |
| Auditor attestation | That the process was followed as described | Readers of the report |
Only the first row is fully independent. The rest depend on what the platform chooses to publish.
How do you verify an exchange's Bitcoin reserves yourself?
Take the reserve address list the exchange publishes, look up each address on-chain, and total the balances at a stated block height. That number is the reserves figure, and it does not require trusting the exchange for anything except the claim that those addresses are theirs. Doing it by hand breaks down quickly, because a large exchange may publish thousands of addresses or an extended public key covering many more. That is a batch job: expand the key, resolve every derived address, and sum balances to the satoshi at a fixed height, which is what a Bitcoin proof of reserves API is for. Pinning to a block height matters, because a total taken a few blocks apart will not reconcile with the published figure.
What are the limitations of proof of reserves?
It is a snapshot, not a guarantee. A platform can borrow coins the day before the snapshot, prove reserves, and return them afterward, a practice usually called window dressing. It also says nothing about off-chain debts: an exchange can be fully backed on-chain and still owe a lender more than it is worth. And the customer liability side is only as honest as the list fed into the Merkle tree, since omitted accounts shrink liabilities without breaking any individual's proof unless that individual checks. Frequent snapshots, independent auditors and proof of control all reduce these gaps, but none of them turn proof of reserves into a full audit.
Does proof of reserves prove an exchange controls an address?
Not on its own. Anyone can list an address they do not own. Control is demonstrated separately, either by signing a message with the address key or by moving a small amount at a time and in a way the auditor specifies. Without that step, a reserve list is a claim rather than a proof, and it is worth checking whether the platform published proof of control alongside the balances. Address reuse across platforms has happened, and it is visible on-chain if you compare published lists.
How often should proof of reserves be published?
Most major exchanges publish monthly, and a few refresh more often. There is no US rule setting a cadence for exchanges generally, so it is a market practice rather than a requirement. The useful signal is consistency: a platform that has published every month for two years, with an auditor named and the reserve addresses unchanged except for explainable movements, is telling you more than one that publishes a single glossy report. Tracking the same address set across snapshots is how you spot coins arriving right before a report and leaving right after, and pulling those histories into one place alongside your other risk data is a job for the sort of pipeline that connects your systems and APIs into a single store.
Proof of reserves versus a financial audit
A financial audit examines a company's complete books, including liabilities that never touch a blockchain: loans, payables, legal exposure, related-party transactions. Proof of reserves examines one narrow question at one moment in time. Both are useful and they are not substitutes. Reading a proof of reserves report as if it were an audit opinion is the most common mistake, and the reports themselves usually say so in the fine print, often describing the work as agreed-upon procedures rather than an audit.
Getting the on-chain half right
The reserves side is the part anyone can verify independently, and it is also the part that gets sloppy, because totalling thousands of addresses at a fixed height is real engineering work. BitcoinDatabase indexes every block since 2009, so you can submit a reserve address list or an extended public key, get balances to the satoshi at a chosen block height, and pull the movement history between snapshots over REST, SQL or dashboards. If you are building this into a compliance workflow, see crypto transaction monitoring and how to screen a Bitcoin address for sanctions. This is informational on-chain data, not an audit opinion and not financial or legal advice.
Hit Run to query the fully-indexed Bitcoin blockchain.
BTC
30-day trend
informational on-chain data · not financial advice
Query the Bitcoin blockchain yourself
Pull balances, UTXOs, transactions, on-chain metrics and fund flows from the fully indexed Bitcoin blockchain by REST API, SQL and dashboards. Indexed since 2009, new blocks within seconds, no node to run.