What Is Proof of Reserves (PoR)? Learning to Verify a PoR Report From Scratch

FTX filed for bankruptcy on November 11, 2022, and the lesson it left is this: the coins you deposit on an exchange can be moved by the platform, and you will not know. That same week, Changpeng Zhao (CZ), then Binance's CEO, publicly called on every exchange to publish proof of reserves.

I read that as a one-line test: an exchange either publishes proof of reserves on a regular schedule, or my advice is to stay away from it. This piece is about PoR itself: what it is, which problems it solves, which it does not, and how to read one on your own.

I. What PoR actually proves

Proof of Reserves is a disclosure an exchange publishes about its own holdings, sometimes checked by an outside firm and sometimes backed by cryptographic proofs that users can verify for themselves. Its purpose is to establish three things:

1. The amount of on-chain crypto assets the exchange holds at a given point in time (verified by adding up the balances of all the exchange's publicly disclosed wallet addresses).
2. The total the exchange actually owes its users at that same point in time (verified with a Merkle tree or a zk-SNARK proof showing that every user balance sums correctly).
3. Assets ≥ liabilities (ideally a reserve ratio above 100%, meaning assets clearly exceed liabilities and leave a buffer).

In plain terms: a proper PoR should let any user independently check two things. First, that their own balance really is counted in the platform's total liabilities. Second, that the platform's on-chain assets really are at least equal to that total.

In its entire lifetime, FTX never published a single PoR that met this definition.

II. What PoR cannot prove

This section matters more than the last one. PoR is not a certificate of safety, and its limits are very clearly drawn:

1. PoR does not prove fiat reserves. A PoR report usually covers only the crypto side: BTC, ETH, stablecoins and the like. If what you deposited was US dollars, euros or yen, PoR has no way of showing that this money reconciles too. There is still no standard fix for that gap.
2. PoR is a snapshot of a single moment. A PoR report dated May 1, 2026 proves only the balances at 12:00 UTC that day. Between that moment and the next report (the interval is whatever the exchange chooses), the platform in theory has time to move funds out and put them back. That is why monthly matters more than quarterly, and quarterly more than annual.
3. PoR does not prove that liabilities are complete. User liabilities are a known quantity; the platform knows how much each user has deposited. But it may also carry hidden liabilities to outside parties: money owed to a market maker, a loan commitment to an affiliated company, unsettled derivatives positions. None of that sits inside user liabilities, so PoR cannot see it.
4. PoR does not prove the business is healthy. An exchange can pass PoR cleanly while losing money, burning cash and facing regulatory lawsuits. PoR only asks whether the users' coins are still there, not whether the exchange can keep operating.

Taken together, these four limits make PoR sound weak. And it is only a necessary condition: failing it definitely means trouble, but passing it does not mean you are absolutely safe. Mt.Gox, QuadrigaCX and FTX, three wrecks, had one thing in common: they did not even meet that necessary condition.

III. A short history of PoR

On Mazars, two things can be checked. Mazars paused producing these reports for crypto clients on December 16, 2022, giving as its reason concerns about the way such reports are understood by the public. And Binance's current PoR page carries no third-party signature (viewed October 2026); what it describes is a Merkle tree plus zk-SNARKs, checked by users themselves. What Mazars paused was its own work producing these reports, which is not the same as PoR itself failing. The criterion this archive uses: a report issued by an independent third party is more credible; where there is none, all you can do is check the on-chain addresses yourself.

IV. Four steps to verify a PoR yourself

Binance's PoR page is the example below, because it puts the self-check entry point and method on a public page; at another exchange the steps are the same set.

Step 1: Find the PoR page

Go to the main binance.com domain and search for "Proof of Reserves", or go straight to the URL `/en/proof-of-reserves`. Elsewhere, Kraken uses `kraken.com/proof-of-reserves`; at Bybit and other exchanges, search the official site for "Proof of Reserves" to find the equivalent page.

Step 2: Check who did the verification

Check who, if anyone, verified the current report or PoR page: you are looking for an independent audit or verification firm you can actually look up, and a small outfit you have never heard of and cannot find deserves a little wariness. A report issued by an independent third party is more credible; where there is none, all you can do is check the on-chain addresses (Step 3) and your own record (Step 4) yourself. The Binance page used as the example here does not list a third-party verifier.

Step 3: Check the asset side

A PoR report lists the wallet addresses the exchange declares it holds. Pick a few of the largest and check them independently on a block explorer (Etherscan, Mempool, Tronscan and so on): does the balance match what the report says?

Step 4: Check the liability-side method

This is the most rigorous step. The report should state clearly how user liabilities were verified: Merkle tree, zk-SNARK or something else. On Binance, log in, find the proof-of-reserves verification entry under your wallet, and pick a snapshot date. The page gives you a Record ID and Merkle Leaf specific to your account for that round, plus the assets and balances it counted. Note that seeing those on the page is not the same as having verified anything: that is still data the exchange is showing you. Use the self-verification method described on the official PoR page to check that your Record ID / Merkle Leaf really sits in that round's liabilities Merkle tree. If it checks out, your balance was counted in that round's liabilities. If it does not, or you cannot find a record for that round, treat the round as unverified, take screenshots and ask support. Even a pass only shows your balance was counted; whether the assets cover the total is what Step 3 is for.

V. Why zk-SNARK proofs of liabilities matter

The traditional Merkle tree PoR has a potential loophole: in theory, an exchange can slip a few fake accounts with negative balances into the tree, pulling its total liabilities down. From the outside, every user can confirm their balance is in the tree, yet the total has been faked.

zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) closes that gap with the mathematics of zero-knowledge proofs. In simplified form:

• The exchange generates a mathematical proof that the sum of all user balances equals the total liabilities it has publicly declared.
• The proof does not reveal any individual user's balance (privacy is preserved).
• Anyone can check that the proof is correct using a public verification program.
• The proof also requires every account balance to be non-negative; if the exchange tries to cheat (by adding negative-balance accounts, for example), the proof itself will fail verification.

In plain terms: on the liability side, you no longer have to rely on trusting whoever signed off; you can check the maths instead. Maths cannot be bought, and it does not soften its conclusions under PR pressure.

Binance first launched zk-SNARK PoR in February 2023. With an exchange that does not use a zk proof on the liability side, it is worth asking one more question when you read its report: how exactly were the liabilities checked?

VI. Five red flags in a PoR report

If you run into any one of the following, mark that exchange's PoR down a notch:

1. The reporting cadence suddenly drops. Monthly becomes quarterly, quarterly becomes annual, or the reports simply stop. This is the strongest negative signal there is.
2. The verifier suddenly changes. A switch may be purely commercial, but it calls for caution, especially when a large independent audit firm is replaced by an outfit that does not sound like an audit firm at all.
3. Only the asset side is verified, not liabilities. This was a common flaw in early PoR, and today it is no longer enough.
4. Liabilities are checked with a Merkle tree alone, with no zk-SNARK-style proof. This one is softer. A Merkle tree is not ruled out as such, but on its own it cannot stop the negative-balance trick. If an exchange uses a Merkle tree alone, ask one more question when you read its report: what actually guarantees the total liabilities?
5. There is neither outside verification nor a way to check it yourself. A report issued by an independent third party is more credible; where there is none, the exchange should at least give a list of wallet addresses and a way for users to check for themselves. A "PoR" with neither is essentially a statement the exchange wrote about itself, and it carries almost no weight.

By now you have the basic ability to read a PoR for yourself. The next time an exchange puts out a press release boasting about industry-leading transparency, you will be able to reach your own conclusion.