Proof of Reserves Explained: What It Verifies and What It Doesn't

Published August 1, 2026 · Updated August 1, 2026

AI-assisted content · Swoopr is responsible for the final published article.

Key Takeaways

Proof of reserves (PoR) is a cryptographic exercise, usually built on a Merkle-tree structure, that lets an exchange demonstrate it held on-chain assets sufficient to cover published customer balances at a specific moment, and lets each individual customer verify their own balance was part of that published set without exposing anyone else's. It's a genuinely useful transparency mechanism compared to disclosing nothing at all. It is also, on its own, a far weaker claim than "this exchange is solvent and safe," and the gap between those two things is the single most important thing to understand before treating a PoR badge as reassurance.

Direct answer: Proof of reserves shows that an exchange controlled enough on-chain assets to cover the customer balances it included in a snapshot, at the moment that snapshot was taken. It does not show that every customer liability was counted, that the reserve assets weren't temporarily borrowed to pass the check, or that those same assets are still there the next day. None of that makes proof of reserves worthless — it rules out one real failure mode, reserves that never existed at all — but it is not, by itself, a solvency guarantee, and it is not the same thing as an independent financial audit.

Proof of reserves typically uses a Merkle tree so each customer can verify their own balance was included without seeing anyone else's balance.
It's a snapshot: valid for the instant it was taken, not a continuous or forward-looking guarantee.
Most PoR exercises verify assets only — they say little to nothing about whether every customer liability was actually counted.
Reserves can be borrowed just long enough to pass a snapshot, then moved again immediately after, sometimes described as reserve rehypothecation risk.
A self-published PoR snapshot is not the same as an independent financial audit performed under a recognized accounting standard.
Treat PoR as one positive signal among several, weighted more heavily when it's published regularly and paired with independent verification.

What Proof of Reserves Typically Means

"Proof of reserves" describes a category of exercise, not a single fixed standard, but the common thread across how exchanges use the term is this: the exchange publishes cryptographic evidence that it holds on-chain assets sufficient to cover the account balances it says it owes to customers, as of a particular date and time. The word "cryptographic" matters here — the point of the exercise isn't just a press release stating a total dollar figure, which would require the reader to simply trust the exchange's word. It's a verification method built so that individual users can check a specific, personal claim about their own account without needing to trust the exchange's summary of it.

That individual-verifiability property is what separates proof of reserves from an exchange simply saying "we hold $2 billion in customer assets, trust us." With a properly built PoR system, a customer with a $10,000 balance can confirm that their specific $10,000 was included in the total the exchange claims to be backing, using data made available to them directly, rather than taking the exchange's aggregate number at face value. Crucially, this happens without any customer being able to see anyone else's individual balance — the mechanism proves inclusion in a set without exposing the rest of the set, which is exactly what the Merkle-tree structure covered next is designed to do.

On the liabilities side, the exchange separately needs to show it controls assets, on-chain, equal to or greater than the sum of everything it owes customers — usually by publicly attesting to a set of wallet addresses, proving control over them through a signed message, then showing those addresses' on-chain balances add up to at least the claimed total. Put together, proof of reserves answers one narrow question well: at this moment, did the exchange's on-chain holdings cover what it told customers they were owed? It is not, by itself, designed to answer broader questions about ongoing financial health, which is the theme the rest of this page focuses on.

How the Merkle-Tree Verification Mechanism Works

You don't need a cryptography background to understand what a Merkle tree accomplishes here, only the shape of the problem it solves. An exchange with, say, three million customer accounts needs a way to publish one single, short, tamper-evident summary of all three million balances at once, and then let any one of those customers check that their own balance was correctly included — without publishing all three million balances in the open, and without anyone needing to trust the exchange's word that the summary is accurate.

Think of it as a tournament bracket built out of balances instead of teams. Each customer's account balance, combined with an identifier unique to that account, is first turned into a short cryptographic fingerprint — a "hash." The exchange pairs up those fingerprints two at a time and combines each pair into a new fingerprint one level up, the same way two bracket winners advance to face each other in the next round. That process repeats, level after level, until only one remains at the top: the Merkle root, the single number the exchange actually publishes. It depends mathematically on every balance that went into the tree — change even one customer's balance by a single unit, and the root comes out completely different — which is what makes it a tamper-evident summary rather than an easily faked headline figure.

The clever part is what happens when a customer wants to verify their own inclusion. Instead of needing the entire tree, the exchange gives each customer only a small handful of "sibling" fingerprints along the path from their own balance up to the published root — typically around twenty values even for millions of accounts, since the tree's height grows logarithmically rather than linearly with the number of participants. The customer, or a tool built to do this automatically, recombines their own balance with that short list step by step and checks whether the result matches the published root. A match mathematically confirms their exact balance was one of the inputs — with no need to trust the exchange's assurance and no visibility into anyone else's balance along the way.

In plain terms, the mechanism accomplishes individual verifiability without full disclosure: every customer can confirm their own balance is counted, and no customer's balance is exposed to any other. What it does not accomplish, and this is the pivot point for the rest of this page, is confirming whether the exchange's claimed liabilities were complete, whether the on-chain assets backing the root were the exchange's own or temporarily borrowed, or whether any of it remains true a moment after the root was published.

The Critical Limitation: A Snapshot, Not a Guarantee

Every limitation covered in this section flows from the same root fact: proof of reserves, as commonly implemented, certifies a single point in time. That's not a minor footnote — it's the central thing this page exists to make clear, because the marketing framing around PoR badges routinely implies something much closer to an ongoing solvency guarantee than what the mechanism actually delivers.

It says nothing definitive about liabilities

A proof-of-reserves exercise is, at its core, a check on the asset side of the balance sheet: does the exchange control enough on-chain value to cover a stated total? That stated total is itself a number the exchange has to report, and the Merkle tree's math does nothing to independently verify it reflects everything the exchange owes. If an exchange quietly excludes certain account types, liabilities owed to institutional partners, or amounts tied up in withdrawal disputes, the resulting snapshot can still check out mathematically while understating true obligations. The mechanism proves the published liabilities figure is backed by real assets; it does not prove that figure is complete.

It says nothing about what happens between snapshots

A snapshot is, definitionally, a moment — and a balance sheet isn't frozen around it. Assets present at the moment of a published snapshot can be moved, withdrawn, or otherwise redeployed immediately afterward, and nothing about a past PoR publication detects that. This is sometimes called reserve rehypothecation risk: reserves genuinely present for the purposes of passing a check, then put to other use before the next one, if there even is a next one. Because most PoR exercises happen periodically rather than continuously, the gap between snapshots can be long enough for a real change in the exchange's asset position to go entirely unreflected in what customers see.

It says nothing about the source or legitimacy of the reserve assets

Controlling an asset at the moment of a snapshot and owning it outright aren't necessarily the same thing. An exchange under financial strain has an incentive — and in some documented industry cases has been alleged to have acted on it — to temporarily borrow assets from a third party specifically to bulk up its holdings long enough to pass a check, then return them once the snapshot is published. The cryptographic proof can't distinguish an exchange's own long-term holdings from assets borrowed for the occasion, because both look identical on-chain: a wallet address the exchange controls, holding a given balance. Verifying legitimate, unencumbered ownership over time requires a different kind of scrutiny than a point-in-time proof can provide.

Why Proof of Reserves Is Not the Same as a Full Audit

"Proof of reserves" and "audit" get used interchangeably in casual conversation, since both involve outside verification of a financial claim, but the two are structurally different exercises with very different guarantees attached, and understanding the difference is what lets a reader correctly calibrate how much confidence a PoR badge should inspire.

A genuine independent financial audit is performed by a qualified, credentialed third party operating under a recognized accounting standard, with professional and often legal accountability attached to its conclusions. A real audit examines both sides of the ledger — assets and liabilities — in comprehensive detail, typically covering a period of time rather than a single instant, and often testing internal controls and related-party transactions. The auditor's independence and professional exposure are what give an audit opinion its weight: a reputational and sometimes legal cost exists if the audit missed something it should have caught.

Proof of reserves, especially the self-published, non-audited version most common in crypto, is a considerably narrower exercise. It typically covers assets only, reflects one moment rather than a period under examination, and is frequently designed and published by the exchange itself or a technical vendor, rather than by an independent auditor accountable for the overall conclusion. That doesn't make the cryptography fake — the Merkle-tree math genuinely proves what it proves — but the scope of what's being proven is much smaller than "this institution is financially sound." Some exchanges do pair proof of reserves with a real third-party attestation; when that pairing exists, it meaningfully strengthens the claim, which is why the practical guidance below treats that combination as the stronger signal.

Worked Example: A Snapshot That Passes While Insolvency Hides Underneath

Hypothetical, generic example — for education only. Not based on any specific real exchange or event.

Picture a mid-sized exchange holding roughly $500 million in customer crypto balances, according to its own internal ledger. It has committed to publishing proof of reserves quarterly, and its marketing describes this as proof that "customer funds are fully backed at all times." Assume it has, over the preceding months, quietly used a portion of customer deposits to fund a separate lending arm — undisclosed and outside its terms of service — leaving a genuine shortfall of roughly $80 million between what it holds on-chain and what it owes customers.

With the quarterly snapshot date approaching, the exchange arranges a short-term loan of $80 million in crypto assets from a market-making partner, structured informally enough that it doesn't appear in any public disclosure. The borrowed assets move into wallet addresses the exchange controls and will include in its attestation, timed to arrive just before the snapshot is taken.

At the moment the snapshot is generated, everything checks out. Control over the relevant addresses is genuinely verifiable, the on-chain total genuinely equals or exceeds the $500 million reported, the Merkle tree is built correctly, and any customer who checks their own balance gets a valid result. Every piece of the cryptographic proof is technically accurate. Within a day or two, the borrowed $80 million is returned to the lending partner, and actual holdings drop back to roughly $420 million against $500 million still owed.

Nothing about the published proof of reserves was fraudulent in the narrow cryptographic sense, and nothing about it would have looked different to a customer checking their own balance's inclusion. What it could never have shown, by design, is that the reserves were borrowed for the occasion, that they left again almost immediately, or that the shortfall persisted before and after the check. This is precisely the scenario the limitations above describe in the abstract, and it's why regulators and exchanges themselves have increasingly pushed toward pairing PoR with genuine third-party audits and more frequent reporting rather than treating an occasional snapshot as sufficient on its own.

Practical Guidance: How Much Weight to Give a PoR Badge

None of the limitations above mean proof of reserves is worthless or that customers should ignore it. An exchange publishing verifiable, cryptographically sound proof of reserves has still done something meaningfully more transparent than one that discloses nothing at all, and the specific failure mode PoR rules out — reserves that simply never existed, the mechanism behind several of the industry's largest collapses — is a real risk worth ruling out. The right posture is treating a published proof of reserves as one positive signal that raises confidence somewhat, not as a complete solvency guarantee that ends the due-diligence conversation.

Practical checklist

Treat a single, one-time proof-of-reserves publication as a weaker signal than a recurring one; an exchange publishing PoR on a regular cadence — monthly or quarterly, consistently, over time — is demonstrating more than an exchange that did it once, possibly around a moment of public pressure.
Give meaningfully more weight to a proof-of-reserves exercise that's paired with some form of independent third-party verification or audit component, rather than one that's entirely self-reported and self-published by the exchange with no outside party involved.
Look for disclosure of methodology: does the exchange explain what liabilities were included, which asset types were counted, and how the Merkle-tree or equivalent verification process actually works, or is it just a badge and a headline number with no supporting detail?
Check whether the exchange discloses anything about liabilities beyond the raw total, such as a breakdown by asset type or account category, since a liabilities figure with more disclosed structure is harder to quietly under-report than an opaque single number.
Run your own verification if the exchange provides the tooling to do so — confirming your own balance was included in the published Merkle root is a low-effort way to personally confirm at least the individual-inclusion part of the claim.
Don't let a PoR badge substitute for the account-level hygiene that matters regardless of an exchange's transparency practices: don't keep more on any single platform than you need for active use, and understand what protections, if any, actually apply to your account through the exchange's own terms.
Read a PoR announcement's actual language carefully; "reserves fully back customer assets" is a claim about a moment, and marketing copy that implies an ongoing, continuous guarantee is overstating what the underlying mechanism proves.

Common mistake

The common mistake is treating a single proof-of-reserves publication as if it settles the solvency question permanently, then not revisiting that conclusion again. A PoR snapshot answers a question about one moment; an exchange's financial condition afterward is an entirely separate, ongoing question that a one-time check cannot answer on your behalf indefinitely.

Misconceptions Versus Reality

Misconception	Reality
An exchange publishing proof of reserves proves it's fully solvent and safe	Proof of reserves typically verifies assets at a single moment; it usually says little about whether all liabilities were counted, whether reserves were borrowed for the occasion, or what happens to those assets afterward
Proof of reserves and an independent financial audit are basically the same thing	A real audit is performed by an accountable third party under a recognized standard and examines assets and liabilities together over a period; self-published PoR is a narrower, typically self-reported, point-in-time asset check
If the Merkle-tree math checks out, the exchange's reserves claim can't be misleading	The math correctly proves the published root reflects the input balances; it cannot detect whether those balances were borrowed short-term, or whether the reported liabilities total was itself understated
Once an exchange publishes proof of reserves, its solvency is settled going forward	A snapshot reflects one instant; assets can be moved, borrowed against, or reused immediately afterward, and nothing about a past PoR publication detects that
Proof of reserves is worthless because it can be gamed	PoR still rules out a real and historically significant failure mode — reserves that never existed at all — and is a meaningfully more transparent practice than disclosing nothing, even though it isn't a complete solvency guarantee
Only large, well-known exchanges bother with proof of reserves, so any exchange doing it is automatically more trustworthy than one that doesn't	Publishing PoR is a genuinely positive signal relative to publishing nothing, but the strength of that signal still depends heavily on frequency, disclosed methodology, and whether it's paired with independent verification, not on the mere fact that a badge exists

Common Mistakes

Treating a one-time proof-of-reserves publication as ongoing proof of safety. A snapshot expires the moment after it's taken; an exchange's financial position afterward is a separate, unverified question until the next check.
Not distinguishing self-reported PoR from an independently audited financial statement. These carry very different levels of accountability and scope, and conflating them overstates the confidence either one actually supports.
Reading "reserves fully back customer assets" as a permanent, continuous guarantee rather than a statement about one moment in time. Marketing language around PoR frequently implies more durability than the underlying mechanism provides.
Assuming the asset-side proof also verifies the liabilities figure was complete and accurate. The cryptography verifies inclusion in a published set; it does not independently verify that the set itself was honestly and completely reported.
Ignoring how frequently an exchange actually publishes proof of reserves. A single historical snapshot from months ago says far less than a consistent, recent, recurring publication record.
Letting a PoR badge replace ordinary account hygiene. Even a well-run, transparent exchange still carries counterparty risk that a PoR badge doesn't eliminate, and balances beyond what's needed for active use still carry that risk unnecessarily.

Risks, Limitations, and Exceptions

Implementation details of proof-of-reserves systems vary meaningfully between exchanges and vendors; not every published PoR uses the same rigor, methodology, or disclosure standard described generally in this guide.
Some exchanges pair PoR with a genuine third-party attestation or audit component, which meaningfully strengthens the claim relative to a purely self-reported version; this guide's cautions apply most strongly to the self-reported case.
A customer's ability to personally verify their own balance's inclusion depends on the exchange actually providing usable verification tooling; not all published proofs are equally accessible to non-technical users.
Regulatory requirements and industry practices around proof of reserves continue to evolve, and standards may become more rigorous or more standardized than what's described here over time.
This guide focuses on the Merkle-tree approach most commonly used in practice; some proof-of-reserves implementations use other cryptographic or accounting methods with different specific properties.
Nothing in this guide should be read as a claim that any specific exchange's proof-of-reserves practice is or isn't trustworthy; evaluate each exchange's actual disclosed methodology and history individually.

Sources

Chainalysis, "What Is Proof of Reserves?" chainalysis.com — a blockchain analytics firm's technical overview of proof-of-reserves methodology, including Merkle-tree verification and its limitations.
Chainalysis, "Merkle Trees and Proof of Reserves," chainalysis.com — a deeper technical explainer on how Merkle-tree structures are used to let individual customers verify balance inclusion without exposing others' balances.
Nansen, "Proof of Reserves Explained," nansen.ai — an on-chain analytics firm's discussion of what proof-of-reserves attestations do and don't verify, including liability-side gaps.

Frequently Asked Questions

What does "proof of reserves" actually prove?

Proof of reserves proves that, at a specific point in time, an exchange controlled on-chain assets at least equal to the customer balances included in the published set. It does not prove those assets are unencumbered, that every liability owed to customers was counted, or that the same assets remained in place a moment after the snapshot was taken.

How does the Merkle-tree method work in proof of reserves?

The exchange combines every customer's balance into a single cryptographic structure called a Merkle tree and publishes only the resulting root hash. Each customer can then use a small piece of data specific to their own account, called a Merkle proof, to confirm their exact balance was included in the set the root hash represents, without that process revealing any other customer's individual balance.

Does proof of reserves prove an exchange is solvent?

No. Solvency requires assets to meet or exceed liabilities, and most proof-of-reserves exercises only demonstrate the asset side at a single moment. They typically say nothing about whether every customer liability was included in the count, whether those assets were borrowed specifically to pass the snapshot, or what happens to the assets immediately afterward.

What is reserve rehypothecation, and why does it matter for proof of reserves?

Rehypothecation, in this context, refers to reserve assets that are moved, lent out, or otherwise used elsewhere shortly after a proof-of-reserves snapshot is taken. Because a snapshot only certifies a single moment, it cannot detect or prevent reserves from being withdrawn, borrowed against, or reused immediately after publication, which means the certified figure can become stale within hours.

How is proof of reserves different from an independent audit?

A genuine independent financial audit is performed by a qualified third party under a recognized accounting standard, examines both assets and liabilities in detail, and typically covers a period of time with ongoing accountability. Proof of reserves, especially a self-published version, is usually a narrower, self-reported snapshot of assets alone, produced without the same external scrutiny or liability-side verification.

Can an exchange pass a proof-of-reserves snapshot while still being insolvent?

Yes. An exchange could temporarily borrow assets specifically to cover a snapshot, undercount customer liabilities so the published total looks smaller than it really is, or move reserves out again immediately after the snapshot is published. A single passed snapshot cannot rule any of these scenarios out on its own.

What should I look for when an exchange publishes proof of reserves?

Treat a published proof of reserves as one positive signal rather than a complete solvency guarantee. Give more weight to exchanges that publish snapshots regularly rather than once, that disclose their methodology and what liabilities were included, and that pair the exercise with some form of independent verification or audit rather than relying purely on a self-reported claim.

Conclusion

Proof of reserves is a real, cryptographically meaningful transparency tool, and an exchange that publishes it well has done something genuinely more accountable than one that discloses nothing at all. But the Merkle-tree math behind it was only ever built to answer one narrow question — did the claimed assets exist at this moment — and treating that answer as equivalent to "this exchange is solvent and safe" misreads what the mechanism actually delivers. The gap between a passed snapshot and true solvency is exactly where liabilities can go undercounted, reserves can be borrowed for the occasion, and assets can move again the moment the check is over. Weigh a PoR badge as one positive input among several, favor exchanges that publish it consistently and pair it with independent verification, and keep the broader account-security habits covered across this Security Center in place regardless of what any single exchange discloses.