When a business or institution leaves bitcoin with a third party, the central question becomes: are the coins actually there? Bitcoin is unusual among financial assets in making that question partially answerable in public, because holdings live on a transparent blockchain that anyone can inspect. Proof of reserves is the family of techniques built on that property.
The Two Halves of a Proof of Reserves
A meaningful PoR has two components, and the distinction matters because many published attestations include only the first:
- The reserve side. Evidence that the entity controls specific on-chain funds: a list of addresses together with proof of control, observable by anyone with access to the blockchain.
- The liability side. Evidence about what the entity owes customers: a commitment to the full set of customer balances, structured so each customer can check that their own balance was included in the total.
Reserves without liabilities prove little on their own. An entity could display a large balance while owing customers far more. Solvency is the comparison between the two sides, which is why the liability proof carries most of the weight.
How Reserve Attestations Work
Proving control of on-chain funds is the straightforward half. The entity publishes the Bitcoin addresses (or descriptors) holding its reserves and then demonstrates control, typically by signing a designated message with the keys for each address, occasionally by moving a specific amount at an agreed time. Bitcoin signatures use ECDSA and, since the Taproot upgrade, Schnorr, and either works for the attestation. Anyone can then confirm two things independently: the signatures are valid for those addresses, and the addresses held the claimed balances at the reference block height.
This verification requires no trust in the attesting entity or in any auditor. The blockchain is the evidence, and a verifier with their own node or explorer access can check it directly. The honest caveat is attribution: a signature proves the signer had access to the keys at that moment, and the remaining questions (whose keys, held under what arrangement, encumbered by what claims) live off-chain.
How Merkle-Tree Liability Proofs Work
The liability side uses a Merkle tree, the same data structure Bitcoin uses to commit to the transactions in a block. The entity takes every customer balance, hashes each one (with an identifier) into a leaf using a cryptographic hash function such as SHA-256, then repeatedly hashes pairs of nodes together until a single root hash remains. Interior nodes also carry the sum of the balances beneath them, so the root commits to both the full customer set and its grand total.
The entity publishes the root. Each customer can then request their inclusion path: the short chain of sibling hashes connecting their leaf to the root. If the path checks out, the customer has cryptographic evidence that their exact balance was counted in the published total, without seeing any other customer's data. Customers who verify are the enforcement mechanism: an entity that understated liabilities by omitting accounts risks any omitted customer discovering the omission the moment they check.
The research behind these schemes predates their industry adoption. The summation Merkle-tree scheme behind most exchange liability proofs traces to Gregory Maxwell and Peter Todd in the early 2010s, later written up as a distributed-auditing proof of liabilities. The Provisions paper (2015) then extended the idea to privacy-preserving proofs of solvency that hide the amounts and address set while still proving reserves exceed liabilities. Production deployments of the privacy-preserving variants remain rare; the plain Merkle-tree approach is what most published attestations use today, with the zero-knowledge variants covered below.
Zero-Knowledge Proofs of Reserves
The plain Merkle-tree approach has two costs an entity may want to avoid: it reveals the total liability and the account count, and its guarantee depends on enough customers actually checking their branch. Zero-knowledge constructions address both. A zero-knowledge proof lets one party prove a statement is true without revealing the data behind it, so a custodian can prove a fact about its books while keeping the books private.
The Provisions protocol (2015) applied this to solvency directly: an exchange proves it controls reserves at least as large as its liabilities without disclosing which addresses it owns, the total reserve amount, or any individual customer balance. Later constructions use ZK-SNARKs, a compact proof format that stays cheap to verify, to make both the proof of assets and the proof of liabilities efficient enough to generate at exchange scale, which is what makes the approach practical for an entity with millions of accounts.
Zero-knowledge proofs improve privacy and can lower the verification cost, but they inherit the structural limits below. A proof that reserves exceeded liabilities at one block height still says nothing about the next block, and it still depends on the liability set being complete. The cryptography hides the amounts; it does not certify that every account was included or that the reserves are unencumbered.
What a Proof of Reserves Proves
Read precisely, a well-constructed PoR with both halves establishes: the entity controlled the listed on-chain funds at the reference block height; the published liability tree commits to a specific set of customer balances summing to a specific total; reserves met or exceeded that total at that moment; and any customer who verifies inclusion has evidence their balance was in the count. Those are real, falsifiable claims.
What a Proof of Reserves Does Not Prove
Every limit below is structural, meaning a flawless execution of the standard methodology still carries it:
- Liability completeness. The Merkle tree commits to the balances the entity put into it. Accounts omitted from the tree are invisible unless their owners verify and speak up, and verification rates among customers are typically low. Independent involvement in extracting the liability records is the main mitigation.
- Encumbrances. On-chain control says nothing about legal claims. Reserves may be pledged as loan collateral, subject to liens, or owed to non-customer creditors, and none of that appears in a signature or a Merkle root.
- Borrowed reserves. Funds can be borrowed shortly before the snapshot and returned after it, so a point-in-time proof cannot distinguish temporarily staged reserves from durably held ones. The PCAOB has flagged this limitation in an investor advisory on third-party proof-of-reserve reports. Repeated attestations at unpredictable times, and continuous monitoring of the disclosed addresses between attestations, shrink this window without closing it.
- The point-in-time problem. The proof speaks to one block height. Solvency the following week is a fresh question, which is why frequency is itself a credibility signal.
- Off-chain obligations. Fiat balances, obligations on other ledgers, and operational liabilities sit outside the scheme entirely. A complete solvency picture still requires examining the whole balance sheet, which is the job of a financial statement audit rather than a PoR attestation.
The Post-FTX Adoption Wave
Proof of reserves moved from proposal to industry expectation after November 2022, when FTX, then one of the largest exchanges in the world, filed for Chapter 11 bankruptcy after halting customer withdrawals. The CFTC's subsequent complaint charged FTX's founder and related entities with fraud, alleging that customer funds had been commingled and misappropriated rather than held in custody. The failure demonstrated the precise gap PoR targets: customers held balance claims against an entity whose actual holdings nobody outside it could see.
In the months that followed, Merkle-tree attestations spread rapidly across major trading venues, and accounting bodies began publishing criteria for how such engagements should be performed and reported. Institutions evaluating venues today can reasonably treat the absence of any reserve transparency as a signal in itself, while keeping the structural limits above in view when transparency is offered.
How Institutions Should Read a Proof of Reserves
An allocator, treasurer, or compliance officer reviewing a PoR can work through a short set of questions, each one falsifiable from the published material:
- Does the attestation include a liability proof, or only a display of reserve addresses?
- Does an independent firm participate, and under what engagement standard: an audit opinion, an attestation, or agreed-upon procedures with defined scope?
- Does the report state how the liability records were extracted and whether the full customer population was covered?
- Does the entity disclose encumbrances, related-party exposures, and whether any reserves are borrowed or pledged?
- Does the scheme let every customer verify inclusion, and does the entity report how many do?
- Does publication recur on a schedule frequent enough that the point-in-time limit is tolerable?
- Does the entity hold customer assets in segregated accounts attributable to each client, or in commingled omnibus wallets?
A venue that answers these questions well is offering meaningful transparency. A venue that publishes a list of well-funded addresses and a press release is offering something weaker, and the difference is exactly where diligence belongs. How this fits alongside regulatory status is covered in What Is a Qualified Custodian?
Self-Custody Removes the Question
The strongest answer to "prove you hold my bitcoin" is for no third party to hold it at all. An institution that controls its own keys verifies its reserves continuously, against its own node, with no attestation, auditor, or disclosure schedule in the loop. The balance at its addresses is the proof, refreshed every block. Operating that way at corporate scale is a governance problem rather than a cryptography problem, solved with distributed key control as described in Multisig Governance for Businesses and approval controls as described in What Is a Policy Engine?
The same on-chain transparency applies when working with a provider. Blockstream Enterprise structures custody around segregated accounts with on-chain verifiable reserves, so a client's holdings are attributable and checkable against the blockchain rather than resting on a statement. Whichever path an institution takes (full self-custody, a provider with verifiable segregated reserves, or a mix), the decision framework is covered in How Do Businesses and Institutions Take Custody of Bitcoin?
Frequently Asked Questions
What does proof of reserves actually prove?
A proof of reserves demonstrates that an entity controlled certain on-chain funds at a specific moment, and, when paired with a Merkle-tree liability proof, that the customer balances included in the tree sum to no more than those reserves. It proves control of assets at a point in time, under stated assumptions about the liability data.
Is proof of reserves the same as an audit?
No. A financial statement audit examines an entity's full balance sheet, including off-chain assets, liabilities, and internal controls, under established assurance standards. Most proof-of-reserves reports are narrower attestations or agreed-upon procedures covering specific addresses and a balance snapshot. Reading one as an audit opinion overstates what was verified.
Can a proof of reserves be gamed?
Known weaknesses exist: an entity could borrow funds shortly before the snapshot, omit liabilities from the Merkle tree, exclude negative balances improperly, or hold reserves that are pledged as collateral. Independent oversight of the liability extraction, disclosure of encumbrances, and frequent repetition narrow these gaps, which is exactly what a careful reader checks for.
How often should a proof of reserves be produced?
Each attestation covers only its snapshot moment, so value decays quickly. Monthly or quarterly publication is common practice, and more frequent or rolling attestations reduce the window in which a shortfall could hide. An attestation that has not been refreshed in a year says little about present solvency.
Why did proof of reserves become standard after 2022?
The November 2022 collapse of FTX left customers unable to withdraw assets the exchange claimed to hold, and U.S. regulators alleged customer funds had been misappropriated. In the aftermath, trading venues adopted Merkle-tree attestations to demonstrate backing, and customers and institutions began expecting them. The technique itself predates the collapse by nearly a decade.
Does proof of reserves prove an exchange is solvent?
No. Proof of reserves shows what an entity holds, not what it owes, so it is half of a solvency proof rather than the whole of one. Solvency is the comparison of reserves against liabilities: an entity can control real reserves and still owe customers more than it holds. A reserves-only proof is consistent with insolvency, which is why a complete proof pairs the reserve side with a customer-verifiable liability proof.
What is a zero-knowledge proof of reserves?
It is a construction that lets a custodian prove its reserves meet or exceed its liabilities without revealing the underlying addresses, the total reserve amount, or any individual balance. The 2015 Provisions protocol introduced this for exchange solvency, and later schemes use ZK-SNARKs to make the proofs efficient at scale. Zero-knowledge proofs improve privacy but inherit the same point-in-time and liability-completeness limits as other methods.