Proof of Reserves on crypto exchanges, how to verify your balances with a Merkle tree check, and what red flags look like

Keeping coins on an exchange is a bit like leaving cash in a shop’s back room. You can still spend it, but you’re trusting the shop to not run out, not mix funds, and not quietly borrow your cash for something else. That’s why proof of reserves became a “must ask” topic after the exchange failures of 2022 and 2023. In January 2026, many platforms claim they publish PoR, but the quality swings a lot, from solid and user-verifiable, to mostly a glossy PDF and vibes. This guide explains what PoR does (and doesn’t) prove, how Merkle tree checks work, how to verify your own balance, and what red flags should make you withdraw first and ask questions later. What proof of reserves actually proves (and what it doesn’t) A good proof of reserves report tries to answer one narrow question: at a snapshot moment, did the exchange control enough on-chain assets to cover customer balances included in the snapshot? But the words around it matter, because exchanges mix terms in confusing ways. Term you’ll see What it usually means Common gap to watch PoR “reporting” Exchange posts addresses, numbers, or a dashboard Can be self-produced, no outside check PoR “attestation” A third party checks a defined snapshot process May still be limited scope, not a full audit Financial “audit” Full financial statements, controls, broader liabilities Rare, expensive, and still time-bound Two big limits almost always apply: PoR without full liabilities is incomplete. A Merkle tree can prove your account was included in a liabilities list, but it can’t prove the list included everyone. If certain accounts, negative balances, institutional credits, or off-platform obligations are excluded, the math looks great while reality is messy. PoR is a snapshot, not a live X-ray. A strong report shows the snapshot date clearly, plus how often it repeats. Even respected pages can show older snapshots, for example Kraken’s public page lists a snapshot date and reserve ratios on its proof of reserves page, which is useful, but still time-bound. If you’re comparing platforms, it helps to look at transparency as one factor (not the only one) alongside licenses, security history, and withdrawal behavior. A practical starting point is this internal roundup: Investor’s Guide to Choosing a Crypto Exchange. Merkle tree checks in plain English (what you are verifying) Diagram of Merkle tree PoR flow, from hashed balances to a single root, created with AI. A Merkle tree is basically a “receipt compressor.” Imagine millions of customer balances, each turned into a short fingerprint (a hash). Those fingerprints are paired, hashed again, paired again, until one final fingerprint remains: the Merkle root. Here’s the key idea: if you have your own “leaf hash” (your fingerprint) and the exchange gives you the “proof path” (the sibling hashes you need), you can recompute upward and see if you land on the exact same Merkle root the exchange published. So what does this check prove? It proves inclusion, meaning your balance (as recorded in that snapshot) was part of the liabilities set that produced the published root. It doesn’t prove completeness, meaning it doesn’t force the exchange to include all customers, all products, or all obligations. It doesn’t prove solvency long-term, because reserves can change after snapshot, and liabilities can exist off-chain. Some exchanges publish user instructions for this process. One example of a step-by-step explainer is OKX’s help article on how to verify assets in a Merkle tree. Don’t treat any single implementation as the standard, but it shows the general shape of what you should be able to do. Step-by-step: how to verify your balances with a Merkle tree check User checking a PoR dashboard and verifying inclusion, created with AI. Different exchanges label buttons differently, but the workflow is usually the same. You’re trying to match three things: your balance inputs, your computed root, and the published root for the snapshot. Open the exchange’s PoR page (often “Transparency”, “Proof of Reserves”, or “Attestation”). Confirm it shows a snapshot date/time, covered assets, and a published Merkle root per asset or per report. Find “Verify” or “Merkle proof” inside your account area. Some platforms generate a downloadable proof file, others show it inline. Check what balances are included. Spot wallet only, or also Earn, staking, margin, futures, loans? If the exchange quietly excludes products where liabilities concentrate, the check is weaker. Copy your user identifiers and values exactly as shown (often a user ID hash plus balances per asset). If they show a “leaf hash” already computed, save that too. Run the built-in verifier (preferred) or the exchange’s official verification steps. The result must show your computed root equals the published Merkle root for the same snapshot. Validate reserve ownership evidence. A credible PoR also shows reserve wallet addresses and some method to prove control (on-chain signing, message signing, or clear methodology). If it’s only a number with no addresses, treat it as marketing. Save evidence for your own records (small habit, big payoff): Screenshot of snapshot date, published Merkle root, reserve ratios. Your leaf hash, proof path (or downloaded proof file). The “verification success” screen with timestamp. PDF report or attestor letter, if provided. If you want a wider “platform selection” context (fees, jurisdictions, trust signals), cross-check with a comparison guide like Best Crypto Exchanges of 2025 Comparison, but keep your PoR verification as a separate, hands-on step. Red flags: what misleading proof of reserves looks like in real life Common warning signs around weak PoR disclosures, created with AI. A PoR page can look clean while still being low value. These are the red flags that matter more than design: Missing liabilities coverage. If it only covers spot balances but the exchange runs heavy leverage, lending, or “earn” programs, you’re not seeing the full pressure on reserves. No clarity on negatives and netting. If margin users have negative balances, are those included, or netted away? Netting can make liabilities look smaller than what users assume. Outdated or irregular snapshots. In January 2026, it’s common to see dashboards that are not updated monthly, or show a last snapshot months ago. Old data isn’t proof, it’s history. Unverifiable wallet ownership. Addresses alone are not enough if the exchange can’t show control. Also watch for “borrowed funds for the snapshot” behavior, where wallets look full briefly. No independent attestor, or vague scope. “Reviewed by” language with no clear scope, standards, or limitations is a soft warning. An attestation should say what was tested, and what wasn’t. To sanity-check where an exchange even claims transparency, you can use aggregators as a starting map, then verify on the source pages. CoinMarketCap’s overview of its PoR feature explains how it surfaces exchange disclosures on listings pages: CoinMarketCap’s proof-of-reserves feature. Questions to ask an exchange before trusting its PoR Ask these in support tickets, community calls, or public threads, and pay attention to how direct the answers are: Which liabilities are included (spot, earn, margin, futures, loans, institutional accounts)? Are negative balances included (or netted), and how is that handled in the Merkle tree? Is fiat included (or only on-chain crypto), and where are fiat custodians disclosed? Are reserve assets encumbered (pledged, lent out, used as collateral), or free and clear? What’s the update cadence, and will the exchange publish past roots and reports for comparison? If verification fails: what you should do next A failed check can be user error, or it can be a real issue. Treat it as a risk event until resolved. First, confirm you are looking at the same snapshot date the proof was generated for, and the same account (sub-accounts can confuse this). If the platform offers both “estimated” and “final” liabilities files, use the final one. If it still fails, save screenshots and exported proof data, then open a support ticket asking for written clarification (not just chat). Reduce exposure while waiting: withdraw to self-custody, or spread balances across platforms. Don’t keep “emergency money” on an exchange that can’t pass its own inclusion check. Conclusion: use proof of reserves, but don’t outsource your skepticism Proof of reserves is useful when it’s user-verifiable, frequent, and paired with clear liabilities coverage, but proof of reserves alone isn’t a full solvency guarantee. Your Merkle tree check answers a simple question, “Was my balance included in this snapshot?”, not the larger question, “Is the exchange safe under stress?” Run the check, save your evidence, ask hard questions, and keep your on-exchange balances sized like you might need to move them fast.