Does Proof of Reserves Prove Solvency? The Half That Is Missing

2026-09-20

Solvency is a comparison between two quantities: what an exchange holds and what it owes. Proof of reserves does serious work on the first quantity and much weaker work on the second, so a passing report tells you assets exist and were committed to, not that the platform can meet its obligations. Knowing which half is covered is what turns the report from a slogan into evidence.

Solvency compares assets against liabilities: proof of reserves establishes the asset side strongly and the liability side only as far as the balances that were included

What solvency actually means

Solvency is not a feeling about an exchange and not a synonym for having a lot of money. It is a comparison: total assets against total obligations to customers and to everyone else. An entity is solvent when the first is at least as large as the second.

That definition has a consequence people skip past. You cannot establish solvency by measuring one side well. A perfectly measured pile of assets says nothing until you know what is owed against it, in the same way that a bank statement tells you nothing about whether someone can pay their debts.

Proof of reserves was designed to attack the side that was previously invisible. Before it existed, a customer had no way at all to see whether coins were held. That is a real advance, and it is also why the mechanism gets asked to carry more than it can.

The two halves, side by side

Claim	Does the report establish it	Why
These assets exist on chain	Largely yes	Addresses and balances are publicly readable
The exchange controls them	Yes, if signatures are shown	Control is demonstrated cryptographically
My balance was counted	Yes, for your own row	Your inclusion proof runs against the published root
Every balance was counted	No	An omitted account leaves no trace for others
Assets exceed customer balances	Partly	Only against the balances that were included
The exchange is solvent	No	Obligations beyond customer balances are outside the report

Look at the last two rows together, because that is where the confusion lives. A report can be entirely truthful and still leave the bottom row unanswered.

Why the asset half is the easier half

Assets sit on public chains. Anyone can read the balance of an address, at any time, without permission from the exchange, and that is unusual in finance. The exchange does not get to tell you what the number is; the chain does.

Control is harder than existence but still tractable. Holding coins at an address means nothing unless you can spend from it, so a disclosure that includes signatures from those addresses turns a claim about ownership into something the reader can check. Doing that check is covered in how to verify proof of reserves.

What the asset side never establishes on its own is exclusivity. Coins visible at an address may have been borrowed for the day, or pledged elsewhere, and the chain shows the balance rather than the encumbrance. This is why the asset half, strong as it is, is not the same as free and unencumbered assets.

Why the liability half is the hard one

Liabilities are internal facts. What an exchange owes lives in its own ledger, and no outside observer can read that ledger the way they read a chain. The only thing published is a commitment to a set of balances that the exchange itself assembled.

The structural problem is asymmetric. If an account is left out of the tree, every remaining user still verifies successfully, because their own path to the root is unaffected. Nobody who is inside the set can detect who was left outside it, which means completeness cannot be established by users checking their own rows.

Customer balances are also not the whole of what is owed. Loans taken by the business, obligations to counterparties, and amounts owed under agreements that never appear in customer accounts are all liabilities, and none of them belong to the set the tree commits to. That distinction is developed further in proof of reserves and liabilities.

What user verification adds, and where it stops

Individual verification is not decorative. When many users independently confirm their rows against the same published root, the exchange loses the ability to quietly shrink the liability set, because any account it drops belongs to somebody who can notice.

The strength of that argument scales with participation, and it has a sharp limit. It makes deliberate omission risky rather than impossible, and it says nothing about accounts whose owners never check. It is a deterrent built from many small checks, not a proof of completeness.

Treat it accordingly. A high verification rate is meaningful evidence about the liability set; a report with a root nobody ever checks is a commitment that nothing tests.

Why a snapshot is not a state

Every report describes one moment. Balances are frozen at a timestamp, the tree is built from that freeze, and the root commits to that instant and no other.

Between snapshots, everything can move. Assets can leave, obligations can be taken on, and the next report describes a different moment rather than the interval between the two. Frequency helps, because shorter gaps leave less room, but no publication schedule turns a series of instants into continuous coverage.

This is the ordinary condition of periodic reporting rather than a defect unique to crypto. Financial statements have the same property; the difference is that readers of financial statements are used to remembering it.

What would actually close the gap

Establishing solvency requires an outside party with access to the internal records, a defined scope, and a signature on the conclusion. That is a different exercise from publishing a root, and it produces a different document with different consequences for whoever signed it.

The two are complements rather than rivals. A report gives frequent, self-checkable evidence about the asset side and about your own inclusion; an engagement by a qualified firm can address the parts that no self-check reaches. Neither one makes the other unnecessary, and the division of labour is set out in proof of reserves versus audit.

For a user, the practical stance is neither dismissal nor over-reading. Take the strong claims as strong, hold the weak ones loosely, and let the difference inform how much you leave on any platform.

The bottom line

Proof of reserves proves that specific assets exist and are controlled, and that your balance was inside the committed set. It does not prove that the set was complete, that the assets were unencumbered, or that obligations outside customer balances are covered.

Solvency is the comparison of both halves, and the report measures one of them well. Read it as strong evidence about assets and partial evidence about liabilities, and the mechanism becomes genuinely useful instead of either oversold or dismissed. For more from Bitbase Academy, keep reading.