What Is Proof of Reserves, and What Does It Actually Prove?

How does proof of reserves actually work?

Three kinds of evidence are easy to run together, and this guide keeps them apart. Proof of assets shows that certain keys controlled certain on-chain balances at a moment. A proof or commitment of liabilities fixes a set of customer balances, sometimes with a committed total, so that each customer can check their own entry; it shows what is in the set and says nothing about obligations outside it. A full audit of financial statements, or a solvency assessment, is a different exercise: an auditor or supervisor with access to the platform's books forms a view on all of the entity's assets and liabilities, on-chain and off, including whether recorded liabilities are complete. The first two layers below are the first two kinds of evidence; the third layer, the comparison report, is often an agreed-upon-procedures engagement and falls short of the third kind.

Layer one: proof of assets

The platform publishes addresses and proves control of them, either by signing a message from the keys or by moving a designated amount at an announced time, and anyone can sum the holdings on-chain. Kraken's proof of reserves page describes this as using digital signatures to prove ownership of on-chain addresses with publicly verifiable balances (Kraken, proof of reserves page, platform statement, snapshot dated 30 June 2026). The same page states the limit in its own words: a proof of reserves "cannot prove exclusive possession of private keys" and cannot identify hidden encumbrances or prove that funds had not been borrowed. A signature shows that a key signed. It does not show who beneficially owns the coins, whether the key is shared with a lender or affiliate, or whether the balance was lent in for the day. Vitalik Buterin's November 2022 design note names the last problem "collateral dual-use": an operator can shuttle funds between venues so each looks solvent at its own snapshot (Buterin, "Having a safe CEX", 19 November 2022).

Assets alone are where weak publications stop, and their weakness is arithmetic: assets without liabilities are a numerator without a denominator. A venue owing customers twice its reserves and a venue owing half look identical from the chain.

Layer two: proof of liabilities

This is where the cryptography earns the name, and where the exact scheme matters.

A plain Merkle tree (the same hashing structure explained in how a blockchain works) hashes every account's balance into a leaf, combines the leaves pairwise up to a single root, and publishes the root as a commitment to the entire set. Each customer receives a proof path from their leaf to the root and can verify that their account was counted at its correct balance (ethereum.org, Merkle Patricia trie documentation, on how a root hash lets anyone prove inclusion of a leaf). Kraken describes its liability side this way: an anonymised snapshot of client balances aggregated into a Merkle tree, with a published root and a per-customer inclusion check (Kraken, proof of reserves page, platform statement). What a plain Merkle root proves is inclusion in the committed set. The root carries no balance totals, so it does not by itself state or verify an aggregate liability figure, and it cannot show that every customer account was placed in the tree.

A Merkle sum tree stores a balance at every node as well as a hash. Buterin's note describes each node as a "(balance, hash) pair", with each parent's balance the sum of the two below it, so the root commits to a total liability figure and each proof path shows how the customer's balance feeds into that total (Buterin, 19 November 2022). The sum tree does not by itself rule out negative balances. Buterin's example is an exchange that hides a shortfall behind a fake account with a negative balance; a customer in the affected part of the tree who checks their proof could expose it, but "to get away with the theft, the exchange would have to hope that nobody in the entire right half of the tree checks their balance proof" (in his example, the half holding the fake account). He adds that simply leaving those customers out of the tree would have the same effect (Buterin, 19 November 2022). Ruling out negative entries takes an extra constraint, such as a range proof inside a zero-knowledge proof. The scheme also leaks small amounts of information about neighbouring balances, which is the privacy cost of the design.

Zero-knowledge proofs of reserves add those constraints. Buterin describes using a ZK-SNARK "to prove that all balances in the tree are non-negative and add up to some claimed value" without revealing any other customer's balance (Buterin, 19 November 2022). What such a proof establishes is a set of properties of the committed set: its sum, the absence of negative entries and, in some designs, valid changes to the root. It does not establish that the committed set contains every liability the platform owes. Binance's proof of reserves page describes a zk-SNARK circuit that verifies each user's balance is included in the liabilities total, that net balances are non-negative and that changes to the Merkle root are valid (Binance, proof of reserves page, platform statement). The academic ancestor is Provisions, a 2015 privacy-preserving proof of solvency for Bitcoin exchanges that hides addresses, totals and customer data while proving reserves cover liabilities (Dagher, Bünz, Bonneau, Clark and Boneh, "Provisions", ACM CCS 2015).

Whichever scheme is used, one property is shared. An in-scope customer whose account was dropped will find no valid path when they look for one, so broad checking makes silent omission of those customers risky. That is the scheme's real force: it lets each in-scope customer check their own inclusion. It is also the scheme's exact limit, because those checks test entries in the set and cannot test whether the set is complete. Detection depends on the omitted customers checking and on their complaints being believed, as Buterin's note points out, and balance types or customer classes that were never in scope cannot surface the gap this way. Whether the committed set matches every obligation in the platform's books is a completeness question that needs reconciliation by someone with access to those books, covered in the next section.

Layer three: the comparison report

An accounting or specialist firm compares the demonstrated reserves with the committed liabilities at the snapshot. The US audit regulator notes that these engagements may be framed to give reasonable assurance, limited assurance or no assurance, the last being agreed-upon procedures (AUP) (PCAOB, Investor Advisory, 8 March 2023). The advisory is investor guidance from the US audit regulator and gives no count of how many exchange reports take each form; the Mazars reports discussed below were AUP engagements by Mazars' own description, as reported by CNBC. For AUP reports, the PCAOB says, the management of the crypto entity, not the provider of the report, determines the procedures to be performed.

Two kinds of rule are easy to confuse here. In the US, a practitioner performing an AUP engagement under the AICPA's attestation standards follows SSAE No. 19, which applies to AUP reports dated on or after 15 July 2021 and defines the engagement as one in which "a practitioner performs specific procedures on subject matter and reports the findings without providing an opinion or conclusion" (AICPA, SSAE No. 19, December 2019). That standard governs how such an engagement is performed and reported. It does not say which procedures a proof of reserves should include, and this guide cites no auditing or attestation standard written specifically for proof of reserves. The SEC staff's investor bulletin, which states that it "is not a rule, regulation, or statement of the Securities and Exchange Commission", describes the consequence: such services "may have no specific requirements for the engagement or the information reported" (SEC Office of Investor Education and Advocacy and Office of the Chief Accountant, Investor Bulletin, 27 July 2023). An AUP report lists what the accountant did and what they found. It carries no opinion, and it does not say the platform is solvent.

The PCAOB advisory also set out the limits: proof of reserve reports concern digital assets at one point in time, do not address the entity's liabilities, leave investors unable to tell whether the assets were borrowed, "do not express an opinion on the adequacy of the 'reserves'", and are not subject to PCAOB auditing standards or inspection (PCAOB, 8 March 2023). The SEC bulletin added that such reports may fall outside PCAOB oversight and that their providers may not be subject to the same independence requirements as firms providing audits that are subject to SEC rules (SEC, 27 July 2023).

The reference episode is Mazars. According to CNBC's report of 16 December 2022, Mazars Group said in a statement that it had "paused its activity relating to the provision of Proof of Reserves Reports for entities in the cryptocurrency sector due to concerns regarding the way these reports are understood by the public". The same statement, as CNBC reported it, described the reports as "performed in accordance with Reporting Standards relevant to an Agreed Upon Procedures report" and said they "do not constitute either an assurance or an audit opinion". CNBC named Binance, Crypto.com and KuCoin among the affected clients, reported that the Binance report published by Mazars' South African branch on 7 December 2022 was no longer on the firm's website, and quoted Binance as saying: "Unfortunately, this means that we will not be able to work with Mazars for the moment" (Mazars and Binance statements as reported by CNBC, 16 December 2022; this guide has not located the Mazars statement on Mazars' own site, so the wording rests on the press report). In Mazars' own account, then, the reports were no-opinion AUP engagements, and the pause followed concern about how the public understood them. CNBC's report does not say that Mazars identified an error in any individual report, and this guide draws no conclusion from the pause about the accuracy of any client's report or the solvency of any client.

What does a good proof actually establish, and what escapes it?

The establishment list deserves its credit before the caveats. A venue publishing control-proven reserves against an inclusion-checkable liability commitment, on a schedule, with a named accountant and a stated scope, is making a disclosure that its customers can partly check for themselves. Where such publications lapse or retreat, the exchange assessment framework reads the direction as a signal, which is this evidence class functioning exactly as evidence should.

The escapes are structural, and each one deserves precise wording, because imprecise wording is how the evidence gets over-read.

Your inclusion is not everyone's inclusion. An inclusion proof shows that your balance was in the tree at the committed amount. It does not show that all customer liabilities were included. Customer classes can be left out by design (fiat balances, a subsidiary's customers, a product line), and the tree still verifies perfectly for everyone inside it. Kraken's page, for instance, lists the assets and balance types in scope for each snapshot and states that fiat is not covered (Kraken, proof of reserves page, platform statement, snapshot dated 30 June 2026); a scope statement of this kind is what lets a reader see where the boundary sits. The property that many customers checking makes omission risky only protects the customers who were in scope and who check. Researchers have also documented production implementations that broke even the inclusion guarantee, through weak hashing, incorrect tree construction, and failure to guarantee unique user identifiers, so that a valid-looking proof could be issued for a mis-built tree (Chalkias, Chatzigiannis and Ji, "Broken Proofs of Solvency", IACR ePrint 2022/043). No hashing or zero-knowledge scheme closes the completeness gap on its own. A proof can show that the committed set sums correctly and holds no negative entries; whether that set matches every obligation in the platform's books is a matter for reconciliation by someone with access to those books, and for audit or regulatory oversight.

Key control is not beneficial ownership. A signature proves that whoever held the key at that moment could sign. It does not prove the platform owns the coins, that no lender has a claim on them, that no affiliate or third party also holds the key, or that the coins are not themselves customer assets held on behalf of someone else. Kraken's page discloses that its procedure cannot prove exclusive possession of private keys (Kraken, proof of reserves page, platform statement), a limit that applies to any signature-based proof of assets. Which entity's creditors can reach those keys in an insolvency is a question of custody structure, covered in who holds your crypto, and no signature answers it.

Borrowed reserves. Assets can be lent in for a snapshot and returned afterwards. The PCAOB advisory states that if the assets were borrowed, investors reading such a report would not know (PCAOB, 8 March 2023), and the collateral dual-use problem in Buterin's note is the same point from the design side. Sequential snapshots and accountant procedures reduce the window; the timing gap is inherent to any point-in-time design.

Same entity, same time. A comparison is only meaningful when the assets and the liabilities belong to the same legal entity and were measured at the same moment. An exchange group can hold addresses in one company and contract with customers through another, sometimes in a different jurisdiction. A report that sums a group's on-chain holdings against one operating entity's customer balances, or that dates the asset snapshot and the liability snapshot differently, compares two things that were never on the same balance sheet. Reading a report therefore starts with two questions: which legal entity's liabilities were committed, and are the addresses controlled by that same entity at that same timestamp? If the publication does not say, the comparison is unanchored.

Every other moment. The proof describes its instant. The machinery of loss, as recorded in the wallet vulnerability ledger and the Exchange Failure Index, operates on all the other instants, and the PCAOB advisory notes that a report gives no assurance about asset availability after the report date (PCAOB, 8 March 2023).

Key governance. Reserves demonstrate that keys signed. They say nothing about who can sign, under what controls, or what happens when a signer leaves or is coerced. That is the subject of how institutions custody crypto.

None of these escapes is an argument against the evidence; together they are the argument for its correct weight. The failure mode this guide exists to prevent is substitution: a reserve headline standing in for the four-dimension assessment, when the strongest thing a proof can accurately say is that one entity's in-scope liabilities, at one moment, appeared to be covered by addresses that one set of keys could sign for.

How should you actually use a proof of reserves?

The personal check comes first because it is the part of the scheme that depends on you. Where a venue offers inclusion proofs, the check sits in the account interface (Binance describes a Record ID and Merkle leaf under the wallet verification page; Kraken describes a per-account check against the published root), and performing the check is your contribution to the property that makes silent omission of in-scope customers risky. A platform advertising proof of reserves without customer-verifiable inclusion is publishing the numerator and asking for trust on the denominator, which is a legible fact about the publication.

The reading order for the publication itself:

1. Scheme. Is the liability side a plain Merkle tree, a Merkle sum tree, a zero-knowledge proof, or absent? A plain Merkle root proves inclusion only, a sum tree also commits to a total, and a zero-knowledge proof can add non-negative balances and privacy. None of them proves the liability set is complete, and a report that does not name its scheme cannot be weighed. 2. Entity and timestamp. Which legal entity's customer balances were committed, which entity controls the addresses, and were both measured at the same moment? A mismatch on either point makes the comparison unanchored. 3. Scope. Which assets, which balance types (spot, margin, staking, futures), which customer classes, and is fiat covered? The scope can be compared with the balance types an account actually uses. 4. Report type. Is the accountant's report an agreed-upon-procedures report (findings, no opinion), an examination, or part of audited financial statements? The attestation-versus-audit distinction set out in stablecoin failure modes applies here too. 5. Cadence and history. A schedule kept through bad quarters is worth more than a bull-market debut, and a lapsed schedule is information.

Then the weight. A good proof moves the solvency-transparency dial and leaves custody structure, segregation and jurisdiction exactly where they were. Those dimensions are assessed separately in the exchange assessment framework, and the trade-offs between custodial and self-custody arrangements, each with its own risks, are set out in who holds your crypto. Even a thorough publication leaves those questions open, and it is no substitute for an audit of the entity's financial statements or a supervisor's assessment of its solvency.

Frequently asked questions

Did proof of reserves exist before FTX?

Yes. The Provisions paper, a privacy-preserving proof of solvency for Bitcoin exchanges, was published in 2015 (Dagher et al., ACM CCS 2015), and the researchers who documented broken production implementations in early 2022 trace exchange interest in solvency proofs back to the Mt. Gox bankruptcy of 2014 (Chalkias et al., IACR ePrint 2022/043, January 2022). The norm arrived after November 2022, when venues raced to publish and the term entered retail vocabulary.

Does verifying my inclusion mean my balance is covered?

It means your balance was counted in the committed total at the snapshot, and no more than that: an inclusion check tests your own entry and cannot show that the committed set contains every liability. A hypothetical shows the gap. Suppose a tree commits to 1,000 BTC of customer balances and the proven addresses hold 1,050 BTC, so the publication shows 105 percent coverage. If a product line owing customers another 200 BTC sat outside the tree, the entity would owe 1,200 BTC against 1,050, and every inclusion check inside the tree would still pass. The PCAOB also notes that a report gives no assurance about whether the assets were later used, lent or became unavailable (PCAOB, 8 March 2023). Whether a customer's claim is met in an insolvency depends on the platform's terms and the insolvency law that applies to the entity, which no proof of reserves addresses.

Why would an accounting firm pause this kind of work?

According to CNBC, Mazars said in December 2022 that it had paused proof of reserves work for crypto clients "due to concerns regarding the way these reports are understood by the public" (Mazars statement as reported by CNBC, 16 December 2022). The same statement described the reports as agreed-upon-procedures engagements that report limited findings at a historical point in time and carry no assurance or audit opinion. The PCAOB and SEC advisories that followed in 2023 describe the gap between such reports and an audit from the regulator's side.

Can proof of reserves work for stablecoins too?

The same evidence class backs issuer reserve attestations, and the stablecoin cluster covers it there: reserve composition, attestation scope, the difference between a recurring reserve attestation and a financial statement audit, and redemption rights carry the analysis. The transferable skill is reading what was actually attested, by whom, under which standard.

What would stronger-than-current proofs look like?

More frequent snapshots, zero-knowledge liability proofs that show balances are non-negative and sum correctly without revealing them, reconciliation of the committed set against the platform's own books by an accountant or supervisor with access to those books (the step that addresses completeness, which no proof system settles by itself), proof-of-asset procedures that address encumbrances and shared keys, and reserve reporting folded into audited financial statements of the same entity that holds the customer contracts. All exist in parts across the industry and the literature. Until the parts converge, each publication has to be read for what its scheme, scope and report type actually cover.

Sources and further reading

Primary and reference sources for this guide. Platform pages are the publisher's own statements about its scheme and are cited as such. Volatile figures should be rechecked immediately before publication.

• Investor Advisory: Exercise Caution With Third-Party Verification/Proof of Reserve Reports. Public Company Accounting Oversight Board, 8 March 2023. https://pcaobus.org/resources/information-for-investors/investor-advisories/investor-advisory-exercise-caution-with-third-party-verification-proof-of-reserve-reports (accessed 24 September 2026)
• Investors in the Crypto Asset Markets Should Exercise Caution With Alternatives to Financial Statement Audits: Investor Bulletin. US Securities and Exchange Commission, Office of Investor Education and Advocacy and Office of the Chief Accountant, 27 July 2023. https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/investors (accessed 24 September 2026)
• Statement on Standards for Attestation Engagements No. 19, Agreed-Upon Procedures Engagements. AICPA Auditing Standards Board, December 2019. https://assets.ctfassets.net/rb9cdnjh59cm/3alzLEdOY9deLzGhlsHmJh/d9609d739e4139a512fc9ad2b783b04c/ssae-19.pdf (accessed 24 September 2026)
• Proof of Reserves (platform statement; scheme description, in-scope assets, stated limits). Kraken, snapshot dated 30 June 2026. https://www.kraken.com/proof-of-reserves (accessed 24 September 2026)
• Proof of Reserves (platform statement; Merkle tree and zk-SNARK scheme description, user verification steps). Binance, undated. https://www.binance.com/en/proof-of-reserves (accessed 24 September 2026)
• Having a safe CEX: proof of solvency and beyond. Vitalik Buterin, personal blog, 19 November 2022. https://vitalik.eth.limo/general/2022/11/19/proof_of_solvency.html (accessed 24 September 2026)
• Provisions: Privacy-preserving proofs of solvency for Bitcoin exchanges. Dagher, Bünz, Bonneau, Clark and Boneh, ACM CCS 2015, IACR ePrint 2015/1008. https://eprint.iacr.org/2015/1008 (accessed 23 September 2026)
• Broken Proofs of Solvency in Blockchain Custodial Wallets and Exchanges. Chalkias, Chatzigiannis and Ji, IACR ePrint 2022/043, 14 January 2022 (revised 17 March 2022). https://eprint.iacr.org/2022/043 (accessed 23 September 2026)
• Declaration of John J. Ray III in Support of Chapter 11 Petitions and First Day Pleadings, In re FTX Trading Ltd., Case No. 22-11068 (JTD). US Bankruptcy Court for the District of Delaware, 17 November 2022. https://storage.courtlistener.com/recap/gov.uscourts.deb.188450/gov.uscourts.deb.188450.24.0.pdf (accessed 23 September 2026)
• Mazars Group suspends all work with crypto clients including Binance, Crypto.com, citing concerns over public perception of proof of reserves (contemporaneous press report carrying Mazars' statement; this guide has not located the statement on Mazars' own site). CNBC, 16 December 2022. https://www.cnbc.com/2022/12/16/mazars-suspends-all-work-with-crypto-clients-including-binance-cryptocom.html (accessed 24 September 2026)
• Merkle Patricia Trie (how a root hash commits to leaf data and supports inclusion proofs). ethereum.org developer documentation, undated. https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/ (accessed 23 September 2026)