Proof of Reserves: How to Verify an Exchange Yourself

Disclaimer: this guide is educational. It is not financial or legal advice and it does not rate the solvency of any company. Everything said about specific exchanges comes from their own published pages, read on 5 October 2026, and may have changed since.

TL;DR

• A proof of reserves (PoR) is a snapshot that tries to show an exchange holds at least as many coins on-chain as it owes its customers, for the assets in scope.
• It is not a guarantee of solvency. It says nothing about debts, about the days between snapshots, or about assets outside its scope.
• A credible PoR has three parts: a list of customer liabilities, a list of on-chain addresses the exchange proves it controls, and a way for each customer to check that their own balance is included.
• You can check the third part yourself in a few minutes, and the second part with any block explorer.
• If a report shows only assets and no liabilities, it is a balance of wallets, not a proof of reserves.

Why proof of reserves exists

When you leave coins on an exchange you do not hold the keys. The exchange holds the keys and records a number in its database that says you are owed that amount. That number is a promise, and the only thing that makes the promise good is that the exchange really holds the corresponding coins and does not lend or spend them.

The collapse of FTX in November 2022 made this concrete for millions of users: balances on screen were not backed by assets that could be withdrawn. Since then, many exchanges have started to publish some form of proof of reserves. Quality varies a lot, which is why it is worth knowing what to look for.

What a proof of reserves is, in plain words

A proof of reserves answers two questions at one point in time:

1. How much does the exchange owe its customers? This is the liabilities side: the sum of all customer balances for an asset such as BTC.
2. How much does it hold on-chain? This is the assets side: the balance of addresses the exchange says it controls.

The ratio of the second to the first is the reserve ratio. Kraken, for example, publishes reserve ratios per asset on its Proof of Reserves page. At the time of writing the page shows a snapshot dated 30 June 2026, with 102.9% for BTC, 100.5% for ETH, 100.6% for SOL, 102.3% for XRP and 100.3% for ADA. A ratio at or above 100% for an asset means the in-scope on-chain holdings are at least equal to the in-scope customer balances for that asset.

Note the words "in-scope". Each report defines what it covers. Kraken states that its reserve ratios may change materially between reports because of product changes and changes to its custody infrastructure, which can affect how some wallets are classified, and that the methodology is described in each report.

The Merkle tree, without the maths

The hard part is proving to every customer that their balance was counted without publishing everyone's balance. This is what a Merkle tree does.

Imagine each customer account as a leaf. The leaf contains a hash (a fingerprint) of the account identifier and balance. Two leaves are combined into a parent node, which stores the sum of the two balances and a hash of both children. Parents are combined again, and again, until one node remains at the top: the root. The root contains the total liabilities and a single hash that commits to every leaf below it.

Bybit describes this in its help centre: each parent's balance can only be composed of the balances of its two children, and the hash data lets you check that the node is legitimate. To verify, you need only your own path from your leaf to the root, which is a short list of sibling hashes. Bybit says a tree with 24 levels needs an array of 24 elements for a user to verify their balance, and that this data is only used for your own account.

The result is that if the exchange tried to leave your balance out or change it, your path would not recompute to the published root. And because the root carries the total, the published liabilities number cannot be lowered without invalidating somebody's proof.

Verify a proof of reserves in 5 steps

Step 1: find the primary report

Go to the exchange's own proof of reserves page, not to a news article or a third-party dashboard. Note the snapshot date, which assets are covered, and who produced or attested the report (an accounting firm, an auditor, or the exchange itself). Press releases are useful context, but they are marketing. For instance, Bybit's press release of 24 December 2025 says its 29th report, as of 17 December 2025 and verified by Hacken, shows reserve ratios of 105% for BTC (59,711 BTC owed against 63,206 BTC held) and 101% for ETH. That is the company's own statement, so treat the figures as claims you can test against the report, not as independent facts.

Step 2: check your own account is in the tree

Log in and open the verification page. Kraken offers an open-source Merkle verification tool and says clients can confirm that their balances are included in the accountancy firm's snapshot of liabilities. Bybit offers an in-account "Verify My Account" page that shows your Merkle path, plus open-source generation and verification code on GitHub. Its instructions: copy your proof data into a file called myProof.json, build the verifier with JDK 1.8 or later and Maven, and run it on that file.

Two practical points. First, if your account was opened after the snapshot, or you hold none of the audited tokens, there will be no record for you. Bybit says this explicitly. Second, a green tick in a web page is not a verification; recomputing the path with code you can read is. If you are not a developer, at least run the official tool rather than trusting a screen.

Step 3: confirm the on-chain addresses

The report should list the addresses (or a signed proof of control) behind the asset total. Copy a few into a block explorer and check that the balances roughly match the reported figure on the snapshot date. For Bitcoin, any public explorer will do. Look for two red flags: addresses that cannot be tied to the exchange by any signature or attestation, and balances that move out immediately after the snapshot date.

Checking all addresses by hand is not realistic for a large exchange, so this step is a spot check. The credibility comes from the independent party that attests control, not from you.

Step 4: compare with the liabilities

Look for the liabilities figure for the same asset and the same date. Kraken says it includes total client liabilities in every report and that its snapshot covers margin accounts, futures holdings and staked assets, not only spot balances (Kraken, December 2025 report post). If a report lists wallet balances only, or if the liabilities exclude derivatives or earn products, you cannot say much about solvency.

Step 5: read the date, the scope and the auditor

A strong report states: the snapshot date, the assets covered, the method, who attested it, and what the attestation does not cover. Check how recent it is. Kraken states a commitment to publish quarterly; Bybit says it publishes verification reports monthly. A snapshot that is many months old tells you little about today.

What a proof of reserves does not prove

• Solvency. Solvency means total assets exceed total liabilities, all of them. A PoR usually looks at customer crypto liabilities only. Loans, derivatives obligations, legal claims and fiat liabilities may sit outside it.
• Completeness of liabilities. The Merkle tree proves the accounts included are counted correctly. It cannot prove that no account was left out. This is why the independent attestor matters, and why you check your own inclusion: each customer who verifies catches an omission affecting them.
• Ownership of the assets. Control of an address at a given moment is not the same as owning the coins free of claims. Coins could be borrowed briefly to inflate a snapshot. A signed message at the time of the snapshot is evidence of control, not of ownership.
• Anything between snapshots. It is a photograph, not a film.
• Quality of operations. Security, key management, hacks and insider risk are separate questions.

This is also why the word "audit" needs care. A full financial audit and an agreed-upon-procedures attestation are different things, and an exchange's page will not always make clear which one you are reading. When in doubt, read the report's scope section.

The European angle: what MiCA requires

Regulation (EU) 2023/1114 (MiCA) does not use the words "proof of reserves", and it does not require an exchange to publish a Merkle tree. What it does require of crypto-asset service providers is set out in Article 70. According to the text published by ESMA, providers that hold clients' crypto-assets, or the means of access to them, must make adequate arrangements to safeguard clients' ownership rights, especially in the event of the provider's insolvency, and to prevent the use of clients' crypto-assets for their own account. Client funds other than e-money tokens must be placed with a credit institution or a central bank by the end of the business day after receipt, in an account separately identifiable from the provider's own.

In practice, this means a MiCA-authorised provider has a legal duty to segregate and protect client assets, and a supervisor to answer to. A voluntary proof of reserves is complementary evidence on top of that duty. It does not replace authorisation, and authorisation does not replace your own checks. To see whether a platform is authorised, use the official register rather than the platform's own claim.

Common mistakes

• Treating "100%+" as "safe". It is a reading of in-scope assets on one date.
• Trusting a third-party dashboard without opening the exchange's own report.
• Ignoring the date. Always compare the snapshot date with today.
• Comparing reserve ratios across exchanges as if they used the same method. They do not. Kraken itself notes that "more exchanges are now offering PoRs in some form" but not all with the same rigour, and that is a statement from an exchange with an interest in the comparison, so read it as a lead to check, not as a verdict.
• Leaving large long-term holdings on any platform because its PoR looks good. See below.

Where the proof ends and your own choices begin

The most reliable protection against exchange risk is not holding more coins on an exchange than you need to trade. For long-term holdings, a self-custody setup removes the counterparty entirely, at the cost of making you responsible for your keys. Our guides to hardware wallets and wallet security explain how, and what Bitcoin is covers the basics if you are new. If you want to compare platforms on more than reserves, see how to choose the safest crypto exchange. If you want to avoid custodial risk for trading altogether, read about decentralised exchanges.

Exchanges that publish a proof of reserves: what we could verify

We list only exchanges whose pages we could read and compare on the date shown. If an exchange you use is not here, that is not a judgement on it: it means we have not verified its report for this guide. Apply the five steps above to its own page. Figures are quoted as the companies report them and are not an independent confirmation of solvency.

A worked example: reading a reserve ratio

Take the Bybit figures from its December 2025 press release as an illustration of the arithmetic only. It reports 59,711 BTC of user assets against 63,206 BTC in Bybit wallets. The ratio is 63,206 divided by 59,711, which is about 1.058. The company states 105%, so the rounding is its own. The surplus is about 3,495 BTC. Three questions follow, and none of them is answered by the ratio itself.

1. Is the surplus real? It is real only if the addresses are controlled by the exchange and not borrowed at the snapshot. This is what the attestor's work and signed messages are for.
2. Is the surplus enough? A surplus of a few per cent is a buffer for the in-scope liabilities. It says nothing about obligations outside the scope.
3. Is the number stable? One snapshot cannot show whether the exchange keeps that buffer day to day. Look at several reports in a row, not at one.

The same reading applies to Kraken's ratios. A figure such as 100.3% for ADA is a thin margin on that date; a figure such as 105%+ for stablecoins is a thicker one. Neither is a statement about the company as a whole. Kraken itself warns that ratios may change materially between reports because of product and custody changes.

A short checklist you can reuse

1. Open the exchange's own PoR page. Write down the snapshot date and the covered assets.
2. Check that liabilities are shown, not only wallet balances.
3. Verify your own account with the official tool, ideally by running the open-source code.
4. Spot-check two or three addresses on a block explorer.
5. Note who attested the report and what the attestation excludes.
6. Compare the last three reports, not just the latest.
7. Decide how much you are willing to leave on the platform, regardless of the result.

A numeric Merkle example you can reproduce

The scheme below is a teaching toy, not the exact format of any exchange. Each exchange defines its own leaf and node format in its documentation, so always use its official tool for a real check. The toy is useful because you can recompute every number yourself with any SHA-256 tool.

Four hypothetical customers hold these BTC balances: A has 2, B has 5, C has 3 and D has 10. The rules of the toy: a leaf is the SHA-256 of the text name:balance (for example A:2), and a parent is the SHA-256 of the left hash, the right hash (both as full 64-character hexadecimal text) and the sum of the two balances written one after another as text. Shortened to the first 8 hexadecimal characters, the results are:

• Leaf A (2 BTC): 284bdbe2
• Leaf B (5 BTC): 268c48a8
• Leaf C (3 BTC): 509dd6e3
• Leaf D (10 BTC): 62967c5f
• Parent AB (7 BTC): f8e6fcf0
• Parent CD (13 BTC): 2fad7637
• Root (20 BTC): b21f288f

Now suppose you are customer B. The exchange gives you your proof: your own balance (5), the hash of the neighbouring leaf A together with its balance (2), and the hash of the neighbouring branch CD together with its balance (13). You recompute your leaf, combine it with leaf A to get the parent AB with a sum of 7, then combine AB with CD to get a root with a sum of 20. If your recomputed root matches the published root hash and the published total of 20, your balance was counted exactly as you hold it. If the exchange had recorded 4 instead of 5 for you, your leaf hash would differ, every hash above it would differ, and the root would not match.

Notice also what you did not learn: the balances of C and D individually. You saw only their combined branch total of 13. That is the privacy property. Notice what you cannot detect either: if the exchange had a fifth customer E who owed 8 BTC and left that customer out of the tree entirely, the published root of 20 would still be internally consistent. Only E, or an independent party with access to the full customer list, can catch that.

Proof of reserves, proof of liabilities and proof of solvency

These terms are often mixed up. A proof of liabilities shows how much the exchange owes, in a way each customer can check, as in the Merkle example above. A proof of reserves shows what the exchange controls on-chain. A proof of solvency combines both and asks whether the assets cover the debts. In 2015, researchers including Joseph Bonneau and Dan Boneh published Provisions: Privacy-preserving proofs of solvency for Bitcoin exchanges. In the abstract they describe a proof of solvency as demonstrating that the exchange controls sufficient reserves to settle each customer's account, and they propose a method that does not require the exchange to disclose its addresses, its total holdings or liabilities, or information about customers. The paper also proposes an extension meant to prevent exchanges from colluding to cover for each other's losses.

The practical lesson is that most public exchange reports are weaker than that ideal. They disclose the liabilities, they disclose the addresses, and they rely on an accounting firm for the rest. That is useful, but you should call it by its name: a snapshot of in-scope reserves against in-scope liabilities, not a full proof of solvency.

Why the details matter: two cases

FTX. According to the press release of the US Attorney's Office for the Southern District of New York of 28 March 2024, FTX's founder was found guilty on seven counts, including wire fraud and conspiracy to commit securities and commodities fraud, and was sentenced to 25 years in prison. The release states that he repeatedly told customers that their deposits were kept safe, held in custody for them and kept separate from company assets, and that those statements were false: customer deposits were channelled to the trading firm Alameda Research. It also states that co-conspirators were directed to alter FTX's computer code to let Alameda withdraw effectively unlimited amounts of cryptocurrency. The release describes allegations, evidence offered at trial and public filings. We cite it for one narrow point: what a company says about holding customer assets and what it does can diverge, and a public statement is not evidence by itself.

Mt. Gox. On the trustee's own site, mtgox.com, the exchange's creditors are still handled through civil rehabilitation proceedings in Japan, and the Rehabilitation Trustee has changed the deadline for the base, early lump-sum and intermediate repayments from 31 October 2025 to 31 October 2026 (Japan time). We do not quote loss figures here because the trustee's page does not state them in the part we could read. The point is simpler: when custody fails, recovery can take many years.

These two cases are not examples of a proof of reserves failing. They are the reason users ask for one. We do not claim that any particular proof of reserves would have prevented either case.

What to ask an exchange

If you hold meaningful sums on a platform, these are fair questions to put to its support team or to read in its documentation:

1. Which assets, products and accounts are included in the proof of reserves, and which are excluded?
2. Who attests the report, and is the attestation published in full?
3. Do the liabilities include margin, futures, staking and earn products?
4. How often is a snapshot taken, and are past reports kept online?
5. Is there an open-source verification tool, and where is the code?
6. Is customer money segregated from company money, and where is this written in the terms?
7. Is the platform authorised in your jurisdiction, and under which register entry?

A platform that answers clearly and in writing is easier to assess than one that answers with marketing language. A refusal to answer is itself information.

Limits of this guide

We tried to read the proof of reserves page of Binance and the full text of Regulation (EU) 2023/1114 on EUR-Lex on 5 October 2026, and neither could be loaded by our tools. For that reason this guide does not report Binance's figures and quotes MiCA Article 70 from the text published in ESMA's interactive single rulebook. We prefer to say so than to quote secondary sources. We could not open the Bybit verification report PDF of 23 September 2026 either, so the Bybit numbers above come from its December 2025 press release and its help-centre page. Check the exchange's current page before relying on any figure.

FAQ

Is a proof of reserves the same as an audit?

No. A PoR is a specific cryptographic and accounting exercise on a snapshot. A financial audit covers the whole balance sheet over a period. Read the report's scope to see which one you have.

Can an exchange fake a proof of reserves?

The Merkle method makes it hard to alter or omit a customer who checks. But an exchange can still understate liabilities by leaving accounts out, or inflate assets temporarily. Independent attestation and wide customer verification reduce the risk. They do not remove it.

What if my account is not found in the tree?

Check that your account existed at the snapshot date and held an in-scope asset. If both are true and you still cannot find it, ask the exchange's support in writing and keep the answer.

Does a high reserve ratio mean my funds are insured?

No. Reserves and insurance are different. Check the platform's terms for any insurance or compensation scheme and its exact conditions.

Should I move my coins off an exchange because of this guide?

This guide gives you a way to check, not a recommendation to act. Decisions about your assets are yours, and for larger sums you may want advice from a qualified professional in your own country.