Proof of Reserves: What an Attestation Proves
Proof of reserves became standard after several large failures. Most implementations prove considerably less than the name suggests, and the gap is where the risk lives.
The short version
- Reserves alone are meaningless. Solvency is assets minus liabilities.
- Merkle proofs let you check your own balance was included — few users ever do.
- An exchange can omit liabilities and still produce a valid proof.
- A point-in-time snapshot can be satisfied with borrowed assets.
After a sequence of large failures, proof of reserves became an expected disclosure. It is a genuine improvement over nothing. It is also routinely presented as demonstrating something considerably stronger than it does.
Where the practice came from
The disclosure became an expectation because a sequence of custodial failures revealed that customers had no way to distinguish an exchange holding their assets from one that had lent them out. In every case the information that would have mattered existed inside the company and nowhere else, and by the time it emerged the assets were gone.
Proof of reserves is an attempt to move some of that information outside the company, where it can be checked without permission. That is a worthwhile goal, and the criticisms below are about how far current implementations get toward it rather than about whether the effort is worth making.
Reserves are half the equation
Solvency means assets exceed liabilities. A proof of reserves demonstrates the asset side: here are addresses, here is a signature demonstrating control, here is the balance.
On its own that is not informative. An exchange holding a billion in assets against two billion owed to customers is insolvent, and its proof of reserves is entirely valid. The liability side is what matters, and it is the harder half.
How the liability side is attempted
The standard approach builds a Merkle tree of customer balances. Each user receives a proof allowing them to verify their own balance was included in the total, without revealing anyone else’s.
This is a real cryptographic contribution and it has a structural weakness: it only works if users actually check. The scheme detects an exchange omitting liabilities only when an omitted user notices their absence. In practice the proportion of users who ever verify their inclusion is very small, so an exchange could exclude a meaningful share of liabilities with limited chance of detection.
Well-designed schemes mitigate this with negative-balance protections and third-party verification of the tree’s construction. Many implementations do neither.
The snapshot problem
Proofs are point-in-time. Assets are demonstrated at a particular block.
This creates an obvious opportunity: borrow assets, demonstrate control, return them. From the chain, temporarily borrowed assets are indistinguishable from owned ones. The mitigation is more frequent and unannounced attestations, which makes borrowing continuously expensive rather than a one-off cost — but a quarterly proof on a known date is close to unfalsifiable theatre.
Control is not ownership
Signing from an address demonstrates access to a key. It does not demonstrate that the assets are unencumbered.
They may be pledged as collateral elsewhere, subject to a repurchase agreement, or owed to a counterparty under an arrangement invisible on chain. Off-chain obligations are exactly what a chain cannot see, and they are where the leverage that destroys an exchange usually sits.
What would make it meaningful
- Both sides, verified. Assets and liabilities, with the liability construction reviewed by an independent party rather than asserted.
- Frequent and unpredictable timing. Continuous or at unannounced intervals, so borrowing is not a viable strategy.
- Off-chain obligations disclosed. Encumbrances, loans and related-party exposure — the things a chain cannot show.
- Meaningful user verification rates. Published, so the omission risk can be assessed rather than assumed away.
- A named party accountable for the attestation, with something to lose if it is wrong.
Attestation is not audit
Worth stating plainly because the terms are used interchangeably and are not equivalent. An attestation reports on a narrow set of agreed procedures at a point in time. A financial audit examines an entity’s complete financial position with a much broader scope and a materially higher standard of assurance.
Most crypto proof-of-reserves exercises are the former. Describing them as audits is a category error that flatters the exercise considerably.
The reasonable position
Proof of reserves is better than opacity, and an exchange publishing one is doing more than an exchange that is not. It should be read as a partial disclosure with known gaps rather than as evidence of solvency — and the specific gaps above are the right questions to ask of any implementation.
Keep reading
Related from the newsroom
How Crypto Custody Actually Works
How crypto custody works: omnibus versus segregated accounts, qualified custodians, multi-party computation, and what actually…
What Crypto Market Makers Actually Do
How crypto market makers work: spreads, inventory risk, retainer versus loan-and-option deals, and why the contract structure…
Reading On-Chain Data Without Fooling Yourself
Why on-chain metrics mislead: addresses are not users, volume is not economic activity, and the clustering assumptions behind…
Leave a comment