Proof of reserves: how to read a crypto exchange report

Research checked 22 September 2026. Methods and reproducible files are documented below. The hero is an AI-generated editorial illustration.

A proof-of-reserves page says 105%. Before treating that as evidence about your Litecoin, identify what sits above and below the division sign. Which assets were counted? Which customer balances were included? At what time? Can you check your own record? A reserve ratio without that scope is difficult to use.

We examined the public Kraken and OKX reserve pages on 22 September 2026 and built a separate four-account Merkle-tree exercise. The exercise demonstrates a specific limit: a customer's inclusion proof can pass even when a different customer's liability was never submitted to the tree. It is a teaching example, not an allegation about either exchange.

Read the report as a set of claims

Start with the legal entity and the snapshot timestamp. A brand may operate several entities, custody arrangements and products. A balance held under one entity's terms does not automatically fall within another entity's report. A report for a past instant does not measure every subsequent deposit or withdrawal.

Then identify the engagement. Was an accountant applying agreed procedures, providing another form of attestation, or auditing financial statements? Read the actual document's scope and conclusion. A badge, the word “audit,” or an accounting firm's registration does not answer that question. The SEC's investor-education bulletin explains that proof-of-reserves reports are not equivalent to financial-statement audits. SEC staff bulletin, 27 July 2023.

A useful reading note should preserve the answers and the document that supplied them. Mark a field “not established from the material reviewed” when necessary. Filling a gap with a marketing statement creates false precision.

Two public-page observations, with their limits

On the Kraken page, the displayed snapshot was 30 June 2026. The reserve cards named BTC, ETH, SOL, XRP, ADA, USDC, USDT and USDG. LTC was absent from those cards and from the page's explicit spot-scope list. The FAQ list named six assets, omitting ADA and USDG despite their cards. That documentation inconsistency is a reason to inspect the dated report's scope; it is not evidence of a reserve shortfall.

The OKX page displayed its 46th report, associated with August 2026, and said its reports covered 22 coins. Its public instructions separated account inclusion, total-balance/non-negative constraints and wallet verification. The initially displayed asset cards were paginated, so the first page alone was insufficient to establish whether LTC was covered. We did not treat a partial list as a complete asset inventory.

This review used public pages. We did not log into an account, verify a customer's private inclusion file, audit the exchanges' books or establish unencumbered ownership of every reserve asset. The linked Kraken accountant-report portal could not be retrieved in this research environment. The observations therefore describe the public disclosures, not a completed audit of either platform.

For a Litecoin holder, the practical rule is to locate an explicit LTC entry and the relevant account scope in the dated evidence. A platform supporting LTC trading does not by itself establish that LTC was included in a particular reserve review. If that scope cannot be established, write “LTC coverage unverified” rather than borrowing a Bitcoin reserve percentage.

Recalculate the ratio in matching units

Reserve ratio = in-scope eligible reserves / in-scope customer liabilities
              × 100%

Use the same asset, timestamp and scope on both sides. Ten thousand LTC of customer liabilities should not be compared with a headline dollar value assembled from several assets without understanding the conversion and collateral assumptions. If a report does aggregate assets, inspect its prices, haircuts and netting rules.

Consider a synthetic statement showing 10.5 LTC of reserves against 10 LTC of reported liabilities. The ratio is 105%. That arithmetic is correct. If an additional 5 LTC liability was omitted, however, coverage against the complete 15 LTC ledger would be 70%. The numerator has not changed; the reporting perimeter has.

This sensitivity calculation does not establish that any actual exchange omitted liabilities. It shows why a complete denominator matters. Nor does a ratio above 100% establish that the assets are immediately available for withdrawals, free of third-party claims or sufficient for obligations outside the report.

A Merkle proof you can inspect

Our fictional custodian owes four synthetic customers: A is owed 2 LTC, B 3 LTC, C 4 LTC and D 1 LTC. Each record is serialized as an account letter, a vertical bar and an eight-decimal balance. The total is 10 LTC.

We hash each record with SHA-256 after a one-byte leaf prefix 0x00. Parent nodes hash 0x01 followed by the two child hashes in left-to-right order. These prefixes separate leaf records from parent records. This is our teaching format, not Kraken's or OKX's verifier format.

The resulting root is:

69b043a6b47f3f838f3c948340ea652f3dd783cf44a495cbe42fa8cb2e3d5706

To verify B, the reader needs B's exact serialized record, A's leaf hash as the left sibling, the C+D parent hash as the right sibling, and an independently obtained expected root. Recomputing those two parent levels reproduces the root. Changing B's balance from 3.00000000 to 3.10000000 breaks that equality.

Now suppose a fifth real-world customer E is owed 5 LTC but was left out before the published tree was constructed. B's proof still passes against the published four-account root. It correctly proves B is in that submitted dataset. It cannot discover an account never included in the input. In our exercise, the hash tree also does not itself prove the sum of balances; the separate script computes that sum.

Production designs may use Merkle-sum trees or zero-knowledge proofs to establish additional relationships and constraints. Those claims must be read precisely. Proving arithmetic about a submitted dataset is different from independently establishing that the dataset contains every relevant real-world obligation.

Verify your own inclusion without disclosing private data

Enter the exchange through your normal authenticated route, select the dated report and export the verification record provided for your account. Check the snapshot date and included products. Your current balance may differ because you traded or transferred funds after the snapshot.

Use the exchange's documented verifier for that report version, obtaining the software from its official source. Preserve the exact file and result privately. Do not upload an account-specific proof to an unsolicited “audit support” site, and do not supply credentials, private keys or a seed phrase. Verification of an exchange liability should not require spending authority over your personal wallet.

If the proof fails, distinguish a parsing or version mismatch from a mathematical failure. Check whether the file was truncated, the wrong report was selected or the verifier expects a newer format. Keep the original data and ask the provider about the discrepancy through its established support channel. A failed local command alone is not a published finding of insolvency.

Questions cryptography cannot settle on its own

A wallet signature can demonstrate control of a key. Establishing whether assets are pledged, borrowed, subject to legal claims or held for a different entity requires additional evidence. Likewise, an on-chain balance is observable at a specified point, but that observation does not guarantee future withdrawal processing.

Ask how negative balances, margin, derivatives, staking products, subaccounts and third-party custody are handled. Which obligations are netted? Are reserves held in the same asset customers are owed? Are operational wallets included? Does the accountant's work cover data completeness or only procedures performed on information supplied by management? The answers belong in the report-reading worksheet, not in assumptions made from a green badge.

Repeated reports can improve visibility into changes, but comparing successive percentages still requires stable scope. A ratio rising from 102% to 110% might reflect more reserves, fewer included liabilities or a changed method. Record absolute quantities and methodology changes where the report makes them available.

Use the result in a custody decision

A reserve report is one input alongside withdrawal access, operational history, account terms and your own ability to use self-custody. It is not a substitute for either custody planning or financial statements. Our exchange custody analysis covers the broader relationship, while the multisig guide examines one self-custody approval model and its recovery burden.

Do not turn this worksheet into a numerical safety ranking. “Three missing fields” is not a calibrated probability of failure. Its value is identifying what you have verified, what a provider claims and what remains unanswered.

Download the worksheet and experiment

Use the report-reading checklist, dated public-page observations, Merkle example with sibling hashes and reproduction script. The script operates on synthetic records locally and makes no network requests.

Frequently asked questions

Does passing my inclusion check prove the exchange is solvent?

No. It establishes the inclusion claim implemented by that verifier. Solvency also depends on the completeness of obligations, the nature and availability of assets and the report's wider scope.

Can I use a BTC reserve ratio to assess my LTC balance?

Not as evidence of LTC-specific coverage. Check whether the dated report explicitly includes LTC, your account's product and the relevant legal entity.

Method and sources

The public-page observations and synthetic Merkle experiment were checked on 22 September 2026. Primary sources are Kraken's and OKX's pages and verifier instructions linked above, plus the SEC staff bulletin for the distinction from financial-statement audits. The original calculations test the stated teaching format only. They are not a security review of either exchange's cryptographic implementation.