What proof of reserves actually proves

Proof of reserves answers a narrow question: at a named moment, did the platform hold assets covering the user balances it included in the exercise?

The question people hear is different. They hear that the platform is solvent, that their money is safe, and that withdrawals will be honoured. None of those follow. Solvency is a statement about all assets against all obligations, including debt, undisclosed lending, obligations to counterparties, and anything the platform owes that is not a user balance. A reserve snapshot sees none of that, because none of it is on a chain.

In plain terms: proof of reserves shows that one column covers another column, for the rows that were included. Everything outside those rows is invisible to the method, and the things that have historically destroyed platforms mostly lived outside them.

This is not an argument against it. A narrow claim, stated accurately, is worth considerably more than a broad claim nobody can check. The failure is in presenting the narrow claim as the broad one.

A platform publishes a list of wallet addresses holding a large balance. Anyone can read the chain and confirm the balance is there. It feels like proof, and it establishes almost nothing.

An address is public. Showing you can read a balance does not show the balance is yours. The holdings could belong to somebody else, be borrowed for the occasion, or be the same funds a second platform is also pointing at.

Control is demonstrated by signature. The platform signs a message, chosen by the verifier and unpredictable in advance, from each address in the inventory. That is the evidence that separates an address you own from an address you can see. Where a holding cannot be demonstrated that way, assets sitting with a custodian being the common case, the honest report marks it as attested by a third party rather than proved cryptographically, and says which rows are which.

In plain terms: ask whether the reserve claim rests on addresses or on signatures. If it rests on addresses, it is a screenshot rather than a proof.

Assets are observable. Liabilities are not. The platform is the only party that knows what it owes its users, and the entire value of the exercise depends on that number being complete.

The standard mechanism is a Merkle tree. Every user balance becomes a leaf, the tree is reduced to a single root, and the root is published. A user can then check that their own balance is inside the tree without learning anything about anyone else. That part works and it is genuinely useful.

What it does not do is establish that the tree holds every account. A platform that omits a tranche of liabilities produces a smaller total, a flattering coverage ratio, and a tree in which every user who checks still finds themselves present. The omission is invisible from inside, by construction, because the people who could notice are the ones who were left out and they have no reason to look.

This is why the number of users who actually verify their inclusion matters, and why a platform should be publishing that figure. A tree nobody checks constrains nothing.

In plain terms: the asset side can be verified by strangers. The liability side can only be verified by the users themselves, one at a time, and only if enough of them do it.

A reserve inventory is a set of wallets, and the risk is that two entries in the set represent the same economic holding.

The straightforward version is one pool of funds moved between addresses during the snapshot window, counted twice. The harder version crosses chains: an asset held on one chain and a wrapped representation of it held on another, both appearing in the inventory, both counted. The backing and the claim on the backing are added together as though they were separate reserves.

A related case is assets that are deployed rather than held. Funds lent out, supplied to a liquidity pool or staked are real holdings with real claims attached, and whether they belong in a reserve figure depends on whether they can be recovered on the timescale the liability implies. Lumping them in without saying so overstates coverage in exactly the circumstances where coverage matters.

In plain terms: the inventory is only as sound as the reconciliation between its rows, and the rows that look most convincing individually are often the ones double-counting each other.

Every proof of reserves is taken at a moment. A platform that knows the moment in advance can arrange to look solvent at it.

Borrowing to cover a snapshot is the known manoeuvre. Funds arrive before the block height, the inventory records them, and they leave afterwards. Nothing in the method detects this, and pretending otherwise is worse than stating it plainly.

Two things constrain it. Timing that is not announced in advance removes the ability to prepare. And repetition raises the cost: borrowing to cover one date is a financing exercise, while borrowing to cover an unpredictable date every month is a standing expense that competes with whatever the shortfall was funding in the first place.

In plain terms: a single proof of reserves is a photograph taken on a day the subject chose. A schedule with unannounced timing is the closest the method gets to continuous evidence, and it is still not continuous.

Three confusions do most of the damage, and they are worth separating.

It is not a financial audit. A financial audit examines the accounts of an entity under an accounting framework, by a licensed auditor, with obligations attached to the opinion. Proof of reserves examines holdings on a chain and a commitment to a liability set. The two answer different questions and only one of them carries a regulated opinion.

It is not a security review. Reserves say nothing about whether the platform code is sound, whether its keys are held safely, or whether an attacker could remove the funds tomorrow. A platform can hold full reserves and lose them in a week.

It is not a licence or a regulatory permission. Several regimes expect disclosure about customer asset segregation, and a reserve attestation can support that, but it does not discharge the obligation and no regulator treats it as doing so.

In plain terms: it proves a holding relationship, at a moment, for the balances included. Each of those three qualifiers is doing work.

If you are deciding whether to keep funds somewhere, or running diligence on a platform, the published artefact is readable and most of the questions are answerable from it.

The table below sets the common claims against what each one establishes. The gap between the two columns is where the risk sits.

Six properties separate a reserve proof that constrains behaviour from one that decorates a marketing page.

Control demonstrated by signature on a challenge the verifier chose, not by a published address list

A fixed block height, stated, so the claim can be checked against the chain by anyone later

Coverage reported asset by asset rather than averaged into one figure, since a surplus in one asset does not cover a shortfall in another

A liability tree with published verification tooling, and the proportion of users who have actually verified

Timing that is not announced in advance, on a repeating schedule

An explicit statement of what was not covered, including holdings that were attested rather than proved

That last one is the strongest signal available from outside. A report that names its own limits was written to be checked. A report that names none was written to be quoted.