Proof of reserves became standard practice after it was demonstrated, expensively, that a platform can report balances it does not have. The mechanism that emerged is genuinely useful and it is routinely described as more than it is. It answers one of the two questions that matter, and the missing one is the one that has historically done the damage.
Solvency is a comparison. What a platform holds on one side, what it owes its users on the other, and whether the first is at least as large as the second. Neither figure means anything without the other, and a large reserve alongside a larger liability is insolvency rather than reassurance.
A proof of reserves addresses the first figure. It demonstrates that a set of addresses holds a set of balances and that the platform controls those addresses, usually by signing a message from each one. That part is cryptographically solid and there is very little to argue with about it.
The second figure is the total owed to users, and it is not visible on any chain. It lives in the platform's own database, which is exactly the record that failed in the cases that made this practice necessary. Publishing the first figure without the second is publishing a numerator and calling it a ratio.
Solvency is a comparison. A proof of reserves publishes one side of it, and the side that has historically been falsified is the other one.
The mechanism for the liabilities side, where it exists, is a Merkle tree. Each user's balance is hashed into a leaf, leaves are combined pairwise up to a single root, and the root is published. The structure lets one participant check their own inclusion without seeing anybody else's balance.
In practice the platform gives you the small set of intermediate hashes needed to recompute the root from your own leaf. If your recomputation matches the published root, your balance was counted in the total. If it does not, something is wrong, and this is a check any user can run on their own machine.
The property that matters is that the platform cannot omit you without breaking your verification, and cannot alter your balance without breaking it either. That is a real guarantee against the specific failure of quietly excluding liabilities from the total, and it only works if users actually run the check.
The tree proves that the balances included sum to the published total. It does not prove that every user was included, because the only people who can detect an omission are the ones omitted, and a platform excluding a small number of accounts is unlikely to be caught by anybody else.
It also permits a subtler manipulation: inserting negative balances or fabricated accounts to reduce the total. Implementations that constrain leaves to non-negative values and publish the count of accounts remove part of this, and not every implementation does either.
The honest reading is that a Merkle proof converts an unverifiable claim into one that a diligent population of users can partially audit. That is a substantial improvement over nothing and it depends on participation, which is the part nobody can guarantee and few measure.
Most published proofs come with a document from an accounting firm, and the word on that document matters enormously. An attestation states that agreed-upon procedures were performed and reports what they found. An audit expresses an opinion on whether financial statements present fairly, according to a standard, with the liability that attaches to an opinion.
An attestation on agreed-upon procedures is scoped by the party requesting it. If the procedures do not include verifying that no borrowed assets were counted, that gap is not a failure of the document, it is the document doing exactly what it was asked to do. The scope is usually stated on the first page and rarely read.
This is not a reason to dismiss attestations, which are useful. It is a reason to read the scope section before treating one as an audit, because the two words carry different weight, cost different amounts, and are frequently used interchangeably in the announcement that accompanies them.
A proof describes a moment. Assets can be borrowed before the snapshot and returned afterwards, and the proof would be entirely truthful about that moment while describing a position that existed only for it. This is not hypothetical, it is a documented pattern in adjacent industries and the reason single-date verification is treated sceptically by people who do this professionally.
Frequency is the partial answer. A proof published monthly at an unpredictable moment is much harder to arrange around than one published quarterly on a known date, and continuous publication with live addresses is harder still. The cost of borrowing to pass a check rises with how often and how unpredictably the check happens.
The complete answer would require knowing that the assets are unencumbered, which is to say not pledged, lent or otherwise promised to somebody else. Nothing on the chain says whether an asset is encumbered, because encumbrance lives in agreements. This is the structural limit of the whole approach.
Newer implementations use cryptographic proofs to demonstrate properties of the liability set without publishing it. A platform can prove that every balance in the tree is non-negative and that they sum to a stated total, without revealing any individual balance or the number of users to competitors.
That removes the strongest practical objection to publishing liabilities, which was never technical but commercial: a platform does not want rivals to know its user count or the distribution of its balances. Being able to prove the property without the data changes the calculation for the operator.
It does not touch the encumbrance problem, and it is worth being clear about that. A proof that liabilities are correctly summed and that reserves exceed them is still a proof about a moment, about assets whose legal status is not on the chain. The cryptography improves the accounting and does not reach the agreements.
Cryptography can prove the accounting. It cannot prove that the assets are not already promised to somebody else, because that promise lives in a contract, not on a chain.
Publishing addresses and signing from them proves control at the time of signing. It does not prove exclusive control, and it does not prove that the same assets are not being presented by two entities, which has happened and is detectable only by comparing lists across platforms.
There is also a difference between an address the platform controls and an asset the platform owns. Custody arrangements, shared wallets and assets held for another party can all appear as balances at controlled addresses, and none of them are available to cover user liabilities in a failure.
The practical version of this check is to look at whether the addresses are stable over time, whether balances move in patterns consistent with an operating business, and whether the same addresses appear in somebody else's proof. All three are visible to anybody who looks, and looking is rare.
Four things, in order of usefulness. Whether a liabilities mechanism exists at all or only a reserve figure. Whether your own account appears in the tree, which the platform should give you the tools to verify. Whether the accompanying document says audit or attestation. And how frequently proofs are published and whether the dates are predictable.
The first is the one that filters hardest. A platform publishing addresses and calling it proof of reserves has published half the comparison, and a substantial number of published proofs are exactly this. Noticing takes one glance at whether user balances are represented anywhere in the material.
None of this requires technical skill beyond following the platform's own verification instructions. What it requires is doing it, which almost nobody does, which is why the mechanism protects less than its existence suggests.
Three additions would change what proofs establish. Liabilities proven with the same rigour as reserves, ideally with a non-negativity constraint and a published account count. Frequent publication at unpredictable moments rather than on a calendar. And a statement, from a party with liability, that the assets are unencumbered.
The third is the hard one because it is not a cryptographic problem. It requires somebody to examine agreements and take responsibility for the answer, which is what an audit is and why audits cost what they cost. No amount of chain analysis substitutes for it.
Some platforms do more than the minimum and it is possible to tell which by reading the material rather than the announcement. The gap between the best and the worst practice in this area is very wide, and it is entirely visible to anybody who spends ten minutes on it.
A proof of reserves describes a balance sheet position. It says nothing about operational security, about whether keys are held in a way that survives a compromise, about the jurisdiction the entity sits in, or about what happens to your claim in an insolvency. Those are separate questions with separate answers.
It also does not change the fundamental position of holding a balance on a platform, which is a claim on an operator rather than possession of an asset. A well-proven reserve makes the claim better supported and does not make it a different kind of thing.
Used for what it is, it is one of the more useful disclosures available in this industry. Used as a general assurance of safety, it is doing work it was never built to do, and the distance between those two uses is where most of the reassurance people take from it actually lives.
That a set of addresses held certain balances at a certain moment and that the platform could sign from them. That part is cryptographically solid. Whether the platform owes its users more than it holds is a separate question, answered by a separate mechanism that is frequently absent from what gets published.
It represents the liabilities side. Each user's balance is hashed into a leaf and combined up to a published root, so you can verify your own inclusion without seeing anybody else's balance. The platform cannot omit or alter your balance without breaking your verification, provided you run it.
An audit expresses an opinion on whether financial statements present fairly, according to a standard, with the liability that attaches. An attestation reports what agreed-upon procedures found, and those procedures are scoped by the party requesting them. The scope is usually stated on the first page.
A proof describes a moment, so assets borrowed before a snapshot and returned after would make it truthful about that moment and unrepresentative of any other. Frequent publication at unpredictable times raises the cost of doing this. It does not eliminate the possibility.
Whether the assets are already pledged, lent or promised to somebody else. Nothing on a chain says this, because encumbrance lives in agreements rather than in balances. It is the structural limit of the entire approach and the reason cryptography alone cannot settle solvency.
They let a platform prove that every balance is non-negative and that they sum to a stated total, without revealing individual balances or the user count. That removes the commercial objection to publishing liabilities. It does not touch the encumbrance problem, which is not a cryptographic one.
No. Custody arrangements, shared wallets and assets held for another party all appear as balances at controlled addresses, and none are available to cover user liabilities in a failure. Signing also proves control at that moment, not exclusive control, and the same assets have appeared in two proofs before.
Whether a liabilities mechanism exists at all or only a reserve figure, because a substantial number of published proofs are half the comparison. Then whether your own account verifies in the tree, whether the document says audit or attestation, and how frequently and predictably proofs appear.