Proof of Reserves vs Proof of Liabilities: Half a Balance Sheet Is Not Solvency

The short answer

A reserve ratio is assets ÷ liabilities. Proof of reserves is a technology for the numerator. Proof of liabilities is a technology for the denominator. They are different claims, made with different completeness assumptions, and the ratio between them inherits every weakness of the weaker one.

The identity that governs the whole subject is a balance sheet:

assets − liabilities = equity

An exchange that publishes only the first term has published one line of that statement. The line is useful, and it is not the answer to the question most readers are asking, which is whether the second line is larger than the first.

What a proof of reserves actually claims

Two published implementations show the structure clearly, because they solve the same problem in different mathematics.

Kraken’s review is accountant-led. Kraken describes a procedure performed by an independent third-party accountant: an anonymised snapshot of all client balances is aggregated into a Merkle tree; the accountant obtains the Merkle root, a cryptographic fingerprint of that combination of balances; Kraken then produces digital signatures proving ownership of the on-chain addresses with publicly verifiable balances; and the accountant compares the two, confirming “that these balances exceed or match the client balances represented in the Merkle tree”. The snapshot date on the page read on 2026-10-29 was June 30, 2026, with ratios of 102.9% for BTC, 100.5% for ETH, 100.6% for SOL, 102.3% for XRP, 100.3% for ADA, and “105%+” for USDC, USDT and USDG.

OKX’s review is zero-knowledge. Its 48th report, read on 2026-10-29, states $29.4 billion in primary assets and covers 22 coins. Each user’s balance snapshot is placed in an encrypted Merkle tree and fed into a zk-STARK proof with three stated constraints: a total balance constraint (the claimed total is the sum of every account’s balance), a non-negative constraint (every account’s total balance is above zero), and an inclusion constraint (every balance is in the calculation). Wallet ownership is proved separately, by signed messages on published addresses.

Both reports answer two questions and only two:

1. Does the venue control on-chain assets of at least the stated amount?
2. Is your balance included in the total the venue published?

Neither answers the third question — whether the total is the whole of what the venue owes.

The liability side is a definition, not an observation

Here is the part that gets lost. The asset side can be observed on a public chain. The liability side cannot. Someone has to decide which balances to count, at what value, and how to treat the accounts that are not a simple spot balance.

Kraken publishes its conventions, and they repay reading closely. For margin positions, the review adds positive position values to the asset balance, and the page is explicit about the other half of the entry: if you are long 1 BTC/USD on margin, “your Proof of Reserves balance will reflect a positive +1 BTC adjustment to your BTC balance. There will be no negative adjustment to your USD balance.” For futures, unrealised profit and loss is applied to the collateral balance for single-collateral contracts; for multi-collateral contracts the unrealised P&L is tracked in USD, and since USD is not an in-scope asset for that review, the balance is not adjusted.

That is an honest disclosure of a measurement choice, and it is still a choice. A long margin position adds an asset to the customer’s reported balance without adding the corresponding liability anywhere in the snapshot. Whether that is the right convention is a question about the accounting model, not about cryptography. A reader comparing Kraken’s 102.9% BTC ratio with a venue that treats margin differently is not comparing two measurements of one quantity.

Kraken also states the scope limits plainly: the verification reflects balances in in-scope assets at the time of the review, not subsequent trades, and not assets outside the scope. The page lists Bitcoin, Ether, Solana, USD Coin, Tether and Ripple as in scope for the most recent review, while the ratio table on the same page also shows ADA and USDG figures — a discrepancy worth noticing rather than resolving in the venue’s favour.

What the asset side leaves out

OKX’s page, read on 2026-10-29, gives a second lesson in the same direction. Its per-asset table has two columns that are easy to conflate: “OKX account assets” and “OKX wallet assets”. The first is the sum of what customers hold. The second is what the venue controls on chain, and it is the one split into “Exchange” and “Third-party custody”.

The USDT row read:

Dividing wallet assets by account assets gives 1.054, which is where the 105% in the table comes from. The arithmetic is exact and the ratio is real. The composition is the interesting part: about 1.5% of the USDT backing sits with third-party custodians, and the page’s disclaimer says so — “third party custody balances are held at third party custodians. You may contact your third party custodians for verification of these balances.”

A balance you have to verify somewhere else is still an asset of the venue. It is a different kind of asset from one the venue holds the keys to, and a reserve proof that reports a single ratio hides that distinction unless it discloses the split. OKX does disclose it. Not every venue does.

What a proof of liabilities adds

A proof of liabilities commits to the total owed, and lets each customer verify that their own balance is part of it, without publishing anyone’s balance. Layered under a proof of reserves, it converts the ratio from “assets versus a number the venue wrote down” into “assets versus a committed total”.

It still does not prove completeness. A Merkle tree over 100 accounts is a valid tree. The constraints OKX describes — that the claimed total equals the sum of every account, and that no account is negative — are checked inside the proof, but the set of accounts entering the proof is an operational input. Cryptography can prove that the arithmetic over a set is correct; it cannot prove that the set is the population.

That is why the useful question about any report is not “how many constraints does the proof have” but “what is the complete list of things that would have to be true for this ratio to mean what I think it means”. For a proof of reserves, that list starts with: the liability figure includes every customer balance; no category is excluded; assets are counted at realisable values; and the snapshot is simultaneous on both sides.

Five questions that survive the cryptography

1. What is the denominator? Sum of account balances, sum of positive balances, or sum of balances after adjustments? Negative balances — a customer who owes the venue — change the total depending on whether they are netted.
2. Which accounts are in scope? Sub-accounts, earn products, margin accounts, futures wallets and third-party custodial balances are each a decision.
3. Is the snapshot simultaneous? An asset snapshot at 23:59 and a liability snapshot at 00:01 measure different books.
4. At what price are non-USD assets valued? A ratio in coin units avoids the question; a ratio in dollars does not.
5. What is excluded from both sides? Loans payable, unsettled fiat in transit, and obligations to parties who are not customers are liabilities that a customer-balance proof will never include.

Reading a reserve report in practice

Start with the denominator, not the ratio. If the venue publishes only a percentage, treat it as a marketing figure until the liability definition is available.

Then check the asset composition: how much is held by the venue, how much sits with custodians, and how much is in assets the venue could not liquidate at the stated value in a week.

Then check the timestamp discipline. OKX states that its report is a snapshot of account balances at the time of data capture, and that subsequent transactions are not included. Kraken states the same limitation for its review. A snapshot is a photograph of a moving object, and the honest reading of any snapshot is “this was the position then”, not “this is the position now”.

The OKX 103% report guide works through one venue’s per-asset figures, and the reserve attestation guide covers the stablecoin version of the same document problem. Both are worth reading before quoting any ratio, because both show how much of the number is definition.

For the margin conventions specifically, the maintenance margin guide explains why a position is collateral as well as exposure, and the OKX portfolio margin comparison explains why the same book can produce different margin numbers under two account modes. The same logic applies to a liability total: change the mode, change the number.

Risk note. The figures in this article were read from OKX’s and Kraken’s own proof-of-reserves pages on 2026-10-29 and are reproduced as those pages stated them, including their as-of dates. Reserve reports are point-in-time disclosures produced by the venues themselves or by accountants engaged by them; this article does not audit either report, does not verify any on-chain address, and makes no claim about the solvency of any venue. Reserve ratios, methodologies and scope change without notice. Nothing here is investment advice.