Stablecoin
What Is Proof of Reserves? A Plain Explainer
July 18, 2026
10 mins read
What is proof of reserves? A plain explainer of how PoR works, what it actually proves, and why it isn't full solvency on its own.
TL;DR: Proof of reserves (PoR) is a way for an exchange or issuer to show that customer-facing liabilities are backed by real assets, usually via a Merkle tree of balances checked against signed wallet holdings. Basic PoR proves assets exist at a snapshot moment; it does not by itself prove full solvency unless liabilities are included in the same check.
When FTX collapsed in November 2022, depositors learned that "we are fully backed" had been a claim, not something anyone outside the company could check, and proof of reserves went mainstream almost overnight. This article explains how the method works, what a Merkle tree contributes to the proof, why a snapshot is different from continuous verification, and where its honest limits sit.
Key Takeaways:
- Proof of reserves cryptographically shows that a Merkle tree of customer liabilities matches signed, on-chain asset holdings at a specific point in time.
- Basic PoR proves assets exist; it does not automatically prove solvency, since solvency requires assets to exceed total liabilities, not just be present.
- Snapshot PoR (most current implementations) is a one-time check that ages the moment it is published; continuous, cryptographic PoR closes that gap by making the check re-runnable at any time.
- zkDatabase functions as an independent re-verification layer (Merkle trees plus Zero-Knowledge Proofs), not a replacement for an issuer's auditor.
What is proof of reserves?
Proof of reserves is a verification method that shows customer-facing liabilities are matched by real, held assets, usually by combining a Merkle tree of balances with signed on-chain wallet ownership. The concept predates crypto: banks and custodians have always had to demonstrate backing, but the crypto version formalized it as a specific, publishable artifact after FTX exposed how easily "fully backed" could be asserted without proof.
The mechanism has two halves. First, every customer balance gets hashed into a Merkle tree, producing a single root value that represents the sum of all liabilities without revealing any individual account. Second, the exchange or issuer signs a set of on-chain wallet addresses to show it controls assets of a certain total value. Comparing the two totals answers one question: does the asset side cover the liability side, at this moment.
Related terms that show up across proof of reserves coverage: Merkle tree, cold wallet attestation, reserve ratio, over-collateralization, cryptographic audit, and solvency proof. Understanding how these fit together matters more than memorizing the acronym, because each term maps to a specific part of the mechanism above. Our guide to how on-chain reserve proofs work walks through each construction in detail.
How does proof of reserves actually work?
A user's balance is hashed into a leaf of a Merkle tree; every leaf combines upward into a single root, and that root is checked against signed on-chain wallet totals. Kraken, for example, has an independent auditor construct the tree from account data, then signs known wallet addresses so anyone can see the wallets hold at least as much as the tree claims.
A Merkle tree, rather than a simple published total, lets an individual depositor verify their own balance is included in the reported figure, without seeing anyone else's balance, an inclusion check a plain PDF report cannot offer.
| Step | What happens | What it proves |
|---|---|---|
| 1. Collect balances | Every customer account balance is gathered | Nothing yet — raw input |
| 2. Build Merkle tree | Balances hashed into leaves, combined into a root | A single committed total of liabilities |
| 3. Sign wallets | Exchange signs on-chain addresses it controls | Assets exist and are controlled by the issuer |
| 4. Compare totals | Root-derived liability total checked against signed asset total | Assets ≥ liabilities, at this moment |
| 5. Publish | Root, wallet list, and comparison result go public | A snapshot anyone can spot-check |
Some exchanges add a Zero-Knowledge Proof on top of the Merkle tree. Binance uses a zk-SNARK; OKX uses a zk-STARK; our comparison of crypto exchanges with proof of reserves covers who publishes what. Both let the exchange prove three things at once, that all balances sum to the published total, that no balance is negative, and that every account is actually included, all without revealing a single individual's holdings. That is a genuine privacy upgrade over a plain Merkle tree, which still requires trusting that the auditor built the tree honestly. For a deeper walkthrough of how a zero-knowledge proof accomplishes that without revealing the underlying data, see our plain-language explainer.
What a basic proof of reserves shows, and what it doesn't: assets exist and cover liabilities at a point in time, but not full solvency or that the same still holds tomorrow.
Does proof of reserves prove full solvency?
No. Basic proof of reserves shows that assets exist and match a liability total at a single moment; it does not automatically prove solvency unless the check explicitly includes total liabilities in the same computation. Solvency means assets exceed liabilities across the whole balance sheet, not just that some wallets hold some coins.
This distinction gets flattened in casual usage, and it matters. An exchange could hold enough Bitcoin to cover its stated reserves while quietly running undisclosed liabilities elsewhere, a side lending book, an obligation to a sister entity. A Merkle-tree PoR that only checks "these wallets hold this much" says nothing about those other liabilities. Binance and OKX's constructions are stronger because the liability side (the Merkle tree of user balances) sits inside the same cryptographic check as the asset side, not as a separate, unaudited claim.
The honest framing: proof of reserves proves assets are present and, in the strongest implementations, that they cover the disclosed liability set. It is not a general audit of every obligation a company carries, and vendors that imply otherwise are overstating what the mechanism does. For a closer look at how cryptographic verification compares against traditional CPA attestation, including where each fits, see our companion piece.
Why did proof of reserves become a standard after FTX?
FTX's collapse in November 2022 showed that a stated reserve backing could be entirely false, with no way for depositors to check it before the company failed. Before that, "we are fully backed" was accepted on trust in the brand and a periodic external report.
What changed was buyer behavior, not regulation. Depositors and DeFi protocols that wanted to use a token as collateral needed to verify solvency claims themselves, not just read them. Platforms that shipped verifiable PoR gained trust and unlocked composability, other protocols would accept their token as collateral; platforms that didn't lost users to ones that did.
The US GENIUS Act, passed in 2025, adds a related but distinct requirement: payment-stablecoin issuers must hold 1:1 reserves in cash and short-term US Treasuries and publish a monthly disclosure examined by a registered accounting firm. That obligation sits alongside, not in place of, the on-chain PoR mechanisms exchanges and issuers build voluntarily. Proof of reserves as most people encounter it today is still primarily a trust-and-composability tool the market demanded, with regulation tightening the disclosure baseline underneath it. Our stablecoin reserve verification piece covers why DeFi composability is the sharper driver for issuers specifically.
What is the difference between snapshot and continuous proof of reserves?
A snapshot PoR is accurate only at the exact block or timestamp it was generated; a continuous or cryptographically re-runnable PoR lets any party check the backing again, at any later moment, without waiting for the next scheduled report. Most exchange PoR today, even the sophisticated zk-SNARK and zk-STARK versions, still runs on a periodic cycle, monthly for OKX, "periodic or frequent" for Binance.
The gap this leaves is straightforward: between two snapshots, a reserve shortfall could open and close without anyone outside the company knowing. A snapshot that passed last month says nothing about today.
| Snapshot PoR | Continuous / cryptographic PoR | |
|---|---|---|
| Frequency | Monthly, quarterly, or "periodic" | Re-runnable on demand, no fixed cycle |
| What's checked | Assets vs. liabilities at one block | Assets vs. liabilities against committed, tamper-evident data |
| Who can re-verify | Depends on published methodology | Any party, using the proof and a public verifier |
| Gap between checks | Real, and unmonitored | Closed — the check can be repeated at will |
| Underlying data | Static export at snapshot time | Continuously committed, so history can't be silently edited |
zkDatabase's approach to this gap uses the same Merkle-tree-plus-Zero-Knowledge-Proof construction Binance and OKX already run in production, generalized into a continuous database layer rather than a single-purpose snapshot circuit. The reserve check does not have to wait for the next scheduled report; it can be regenerated and independently re-verified whenever a counterparty, auditor, or regulator wants to look. That is independent re-verification (Merkle trees plus Zero-Knowledge Proofs) in practice, anyone can re-run the proof rather than trusting that whoever signed the last report did so honestly. This is a supplementary layer that sits alongside an issuer's existing accounting relationship, not a replacement for it; zkDatabase does not audit the company or certify its books, it makes the reserve claim itself independently checkable. Our deep dive on stablecoin reserve proofs compares this directly against oracle-fed reporting, and our privacy-preserving proof of reserves piece covers how Zero-Knowledge Proofs prove solvency without publishing every balance.
Bottom line
Proof of reserves answers a narrower question than it sounds like. It shows that assets exist and, at its best, that they cover disclosed liabilities, at one moment. It does not audit a company's full obligations, and a snapshot check ages the second it is published. The direction the strongest implementations are moving, exchange zk-SNARK constructions and cryptographic re-verification layers alike, is toward making that check continuous and independently re-runnable, rather than a periodic report someone has to take on faith.
Explore zkDatabase
See how zkDatabase makes reserve proofs independently re-verifiable, without exposing the underlying balances.
FAQ
What is proof of reserves?
Proof of reserves is a method that shows an exchange, stablecoin issuer, or custodian actually holds the assets backing customer balances, typically by combining a Merkle tree of liabilities with signed on-chain asset holdings. It became a standard practice after FTX's 2022 collapse, when depositors needed a way to verify backing claims themselves rather than trust a company statement.
Does proof of reserves mean a company is fully solvent?
Not automatically. Proof of reserves proves assets exist and, in stronger implementations, that they cover a specific disclosed liability set at one moment. Full solvency requires assets to exceed total liabilities across the whole balance sheet, which a narrow asset-only check does not confirm.
How is proof of reserves different from a financial audit?
A financial audit is a broad, periodic examination of a company's full books by a licensed accounting firm, typically covering more than reserve backing. Proof of reserves is a narrower, often more frequent cryptographic check focused specifically on whether disclosed assets match disclosed liabilities, and it complements rather than replaces that audit relationship.
What role does zkDatabase play in proof of reserves?
zkDatabase provides the same Merkle-tree-plus-Zero-Knowledge-Proof construction that exchanges like Binance already use, as a continuous, general-purpose layer rather than a single snapshot circuit. It lets any party independently re-verify a reserve claim on demand, functioning as a supplementary verification layer alongside, not instead of, an issuer's existing accounting and audit relationships.
Related toStablecoin
