Proof of Reserves Explained: What It Proves and What It Misses
Proof of reserves explained: how Merkle tree attestations work, why reserves without liabilities prove nothing, what zero-knowledge approaches add, and how to read an attestation properly.
Last updated: 30 July 2026
After every custodial failure, the same phrase reappears in exchange marketing: proof of reserves. It sounds like the answer to the problem. An exchange proves it holds what it owes, users verify it cryptographically, and the era of hidden shortfalls ends.
The reality is more limited, and the limitation is not a technical detail. Most published proofs of reserves demonstrate something considerably weaker than what readers assume, and the gap between the two is exactly where the risk lives.
This guide explains how proof of reserves works, what it genuinely establishes, what it cannot, and how to read one without being reassured by the wrong thing.
What proof of reserves is
Proof of reserves is a cryptographic attestation that a custodian holds assets corresponding to customer balances. The standard implementation has two halves, and both are needed for the claim to mean anything.
The asset side
The custodian demonstrates control of on-chain addresses holding the assets, usually by signing a message with the private keys or moving a nominated amount. This part is genuinely strong: a blockchain is a public ledger, so anyone can verify that a given address holds a given balance.
The liability side
Harder, and the part that carries the actual proof. The custodian must demonstrate what it owes customers, without publishing everyone's balance. The standard technique is a Merkle tree.
Every customer balance becomes a leaf. Leaves are hashed in pairs, then those hashes hashed in pairs, repeatedly, until a single Merkle root remains. Publishing the root commits to the entire set of balances without revealing any of them. Each customer then receives a Merkle proof: a short path of hashes letting them verify that their own balance is included in the tree that produced the published root.
The elegance is real. Thousands of users can each independently confirm inclusion, and the custodian cannot quietly exclude a balance from the total without breaking someone's proof.
What it does not prove
Here is where marketing and mathematics part company.
Reserves without liabilities prove nothing
The most common failure is an exchange publishing wallet addresses and a total balance, and calling it proof of reserves. It is not. Showing you hold a billion dollars says nothing about solvency unless you also show what you owe. A firm holding one billion against two billion in liabilities is insolvent, and its reserves attestation looks magnificent.
If an attestation does not include a liability commitment, it establishes only that some assets exist somewhere.
Borrowed assets look identical to owned ones
A proof is a snapshot at a moment. Assets borrowed shortly before the snapshot and returned after it are indistinguishable from assets held continuously. This is not hypothetical; it is a documented pattern in traditional finance called window dressing, and nothing about the cryptography prevents it.
Frequent, unpredictably timed attestations reduce the window. A single annual proof barely narrows it at all.
Off-chain liabilities are invisible
A Merkle tree of customer balances captures customer balances. It does not capture loans from third parties, obligations to counterparties, litigation exposure, or intercompany debts. A custodian can pass a proof of reserves cleanly while carrying obligations that dwarf the customer book.
Nothing forces every customer into the tree
You can verify that your balance is in the tree. You cannot verify that everyone else's is. If a custodian omits a set of liabilities from the tree entirely, the arithmetic works and the affected users, who never check, never find out. Some designs mitigate this with third-party auditors verifying completeness, which reintroduces trust in a different place.
What zero-knowledge approaches add
Newer implementations use zero-knowledge proofs to strengthen the liability side. Rather than only committing to a set of balances, a ZK circuit can prove properties about the set: that all balances are non-negative, that they sum to the stated total, and that the total does not exceed reserves, without revealing individual figures.
This closes a real gap. A naive Merkle construction can be gamed with negative balances that reduce the apparent total; a ZK proof can rule that out mathematically rather than by promise. It does not solve borrowed assets, off-chain liabilities, or completeness, but it is a meaningful improvement over a bare root.
How to read an attestation
| Check | What weak looks like | What strong looks like |
|---|---|---|
| Liabilities included? | Assets only | Merkle root or ZK commitment of customer balances |
| Can you verify your own balance? | No user-facing proof | Merkle path you can independently check |
| Frequency | Annual, pre-announced | Frequent, ideally unpredictable timing |
| Third-party involvement | Self-published | Independent auditor verifying completeness |
| Negative-balance handling | Unaddressed | ZK proof of non-negativity |
| Scope | Silent on off-chain debt | Explicit about what is excluded |
The single most useful question: what does this attestation explicitly say it does not cover? An honest one names its limits. One that reads as unqualified reassurance is telling you something about the publisher.
Why this matters more in 2026
Three centralized venues announced wind-downs inside a single month this year: AscendEX, BitMEX and BitMart. Those were orderly, with published deadlines and honoured withdrawals, but they returned attention to a structural point covered in our piece on why crypto exchanges are closing. A custodial balance is a claim against a company, and proof of reserves is an attempt to make that claim inspectable.
It is a genuine improvement over the alternative, which was nothing at all. It is not equivalent to an audit, and it is not a solvency guarantee.
The structural alternative
There is another way to address the same problem, which is not to create the claim in the first place.
On a non-custodial protocol, there are no customer balances to attest to. Assets remain in wallets users control, and positions are recorded on-chain where anyone can verify them continuously rather than quarterly. Total value locked is not a published figure you are asked to believe; it is queryable state.
JewelSwap works this way across MultiversX, Sui and Radix. The protocol does not hold user assets, so the question "does it have what it owes?" does not arise in the same form. That is an architectural property rather than a virtue we can claim credit for, and it comes with its own risks: smart contract failure, oracle failure, and user error do not disappear because custody did. Our self-custody guide and CeFi vs DeFi comparison cover the trade-off honestly.
Frequently asked questions
What is proof of reserves?
A cryptographic attestation that a custodian holds assets corresponding to customer balances. It typically pairs on-chain evidence of asset control with a Merkle tree committing to customer liabilities, letting individual users verify their balance was included.
How does a Merkle tree proof work?
Each customer balance is a leaf, hashed in pairs repeatedly until one root hash remains. Publishing the root commits to all balances without revealing them. Each customer gets a short path of hashes proving their own balance contributed to that root.
Does proof of reserves prove solvency?
No. It can demonstrate that on-chain assets meet or exceed committed customer liabilities at a point in time. It cannot capture off-chain debts, borrowed assets timed around the snapshot, or liabilities omitted from the tree, all of which affect actual solvency.
What is the difference between proof of reserves and an audit?
An audit is a professional examination of complete financial statements, including off-chain obligations, performed under professional standards. Proof of reserves is a narrower cryptographic snapshot of specific assets and committed customer balances. They are not substitutes.
Can proof of reserves be faked?
The cryptography is sound, but the scope can be gamed. Borrowing assets before a scheduled snapshot, omitting liabilities from the tree, or publishing assets with no liability commitment all produce a passing attestation while misrepresenting the position.
Do DeFi protocols need proof of reserves?
Non-custodial protocols do not hold customer balances, so there is nothing to attest to in the same sense. Positions are verifiable on-chain continuously rather than through periodic attestation. Different risks apply, chiefly smart contract and oracle risk.
Keep reading
