What Is Proof of Reserves?

Introduction

Proof of reserves is a way for a custodian, exchange, or token issuer to show that it holds assets backing customer claims. The stakes are obvious: when users hand assets to an intermediary, they lose direct visibility into whether those assets are still there, have been lent out, rehypothecated, or mixed with other obligations. In crypto, that opacity is especially jarring because the underlying systems are public enough to make verification feel possible, yet private enough that the crucial part of the picture often remains hidden.

That tension explains why proof of reserves exists. A blockchain can show that certain addresses hold certain on-chain assets. But a customer does not just need to know that some assets exist. The real question is whether the institution controls those assets and whether they are enough to cover what it owes. That means proof of reserves is never just about balances in wallets. It is about connecting assets, liabilities, and control into a claim outsiders can test.

The central difficulty is that the two sides of that claim live in different places. Assets may be partly visible on-chain. Liabilities are usually recorded in an internal ledger. If an exchange says it holds 100,000 BTC, that tells you little unless you also know what customers are entitled to withdraw. If it says customer liabilities are 95,000 BTC, that also tells you little unless you know those liabilities were counted completely and honestly. Proof of reserves is the family of techniques built to bridge that gap.

What does proof of reserves actually prove about an institution’s solvency?

At first glance, the phrase sounds simpler than it is. “Reserves” suggests assets sitting somewhere, waiting to be checked. But the meaningful claim is not merely “we have coins.” It is closer to: we control assets whose value is at least as large as the obligations we owe to customers covered by this proof.

That wording matters because there are several distinct questions hidden inside one slogan. The institution must show that the assets exist, that it controls them, that the liabilities are counted correctly, and that the comparison is being made over the right scope. If even one of those pieces is missing, the result can be impressive-looking but economically weak. An exchange can point to a large wallet it does not control. It can sign from wallets while omitting some liabilities. It can publish a customer-liability root that excludes negative-account adjustments or off-platform obligations. Each failure mode produces a proof-shaped object without producing much safety.

So the cleanest way to think about proof of reserves is as a solvency snapshot. At a chosen moment, the institution tries to demonstrate that a set of assets under its control is sufficient to cover a defined set of liabilities. “Snapshot” is important. These proofs are generally point-in-time statements. They do not guarantee that the institution was solvent yesterday, will remain solvent tomorrow, or will honor withdrawals even if the numbers line up at the moment of the proof.

That is why some researchers prefer the more precise phrase proof of solvency. the 2015 Provisions paper frames the problem directly this way: the exchange should be able to prove assets, prove liabilities, and then prove in zero knowledge that assets minus liabilities is nonnegative or zero, depending on the construction. In practice, the industry still says “proof of reserves,” but the useful version is always trying to get at solvency, not just inventory.

How do blockchains enable proof-of-reserves and what limitations remain?

The idea becomes plausible in crypto because on-chain assets are public state. If an exchange controls a Bitcoin address or an Ethereum account, the associated balance can usually be observed. That is already different from traditional finance, where outsiders often cannot even see candidate reserve accounts.

But visibility alone is not enough. A wallet balance is not the same as a reserve. Here is the mechanism behind that distinction. A reserve is an asset that is both owned or controlled by the institution and available to satisfy the relevant claims. If a firm merely points to an address with a large balance, it still must show control, usually by signing a message or performing a cryptographic proof tied to the key. Even then, there is another gap: the asset may be pledged elsewhere, borrowed temporarily, or economically encumbered in a way the chain does not reveal. The blockchain tells you some things with great precision, but not every fact that matters for solvency.

Liabilities are the mirror image. They are often invisible on-chain because they live in the operator’s internal database. A centralized exchange may custody Bitcoin, Ether, SOL, and stablecoins for millions of users, but the detailed customer entitlements are off-chain records. The exchange therefore needs some way to publish a commitment to those liabilities such that each customer can confirm, “my balance is included,” without revealing everyone else’s balances. This is where Merkle trees became the standard practical tool.

The result is a split design. On the asset side, proof of reserves leans on the public verifiability of blockchains plus signatures or zero-knowledge proofs of control. On the liability side, it leans on cryptographic commitments that compress many customer balances into a single public fingerprint while preserving some privacy.

How do asset proofs, liability commitments, and the matching check work in proof-of-reserves?

A useful proof of reserves has three moving parts.

The first is a proof of assets. The institution identifies on-chain assets it claims to control and provides evidence of control. In simple deployments, this can mean publishing wallet addresses and signing a challenge message from those wallets. In more privacy-preserving designs, the institution proves control without revealing exactly which addresses it owns. The Provisions system, for example, uses an anonymity set of public keys and zero-knowledge proofs to show that the exchange controls some secret subset whose balances sum to a committed asset amount.

The second is a proof of liabilities. The institution takes its internal customer ledger and commits to the balances included in the proof. The practical industry pattern is a Merkle tree. Each customer balance is transformed into a leaf, leaves are hashed upward into a root, and that root acts as a compact commitment to the whole liability set. Each customer can then be given a path from their leaf to the root and verify that their balance was included in the committed total.

The third is the comparison. The institution, an auditor, or both must establish that the proved assets are at least as large as the proved liabilities. In a basic attestation, this comparison may happen through a combination of signed wallet control checks, balance observations, and auditor procedures over the internal ledger. In more cryptographic systems, the comparison itself can be proved directly using commitments with additive homomorphism, so that outsiders learn the result without learning the underlying totals.

This structure explains why any “proof of reserves” that shows only wallets, or only a Merkle liability root, is incomplete. Showing assets without liabilities answers the wrong question: you may be rich, but still owe more. Showing liabilities without assets is equally incomplete: you may have counted obligations carefully, but still be short.

How does a Merkle-tree prove customer liabilities in practice?

The Merkle-tree approach became popular because it solves a concrete scaling problem. An exchange needs to commit to a large set of customer balances without publishing a plain list of every account and balance. A Merkle tree lets it compress that set into a single hash, called the Merkle root, while still allowing each customer to verify inclusion.

The mechanism is simple once the purpose is clear. Suppose an exchange has a million customer balances. It hashes each customer’s balance record into a leaf, combines pairs of leaves and hashes them again, then repeats this upward until only one hash remains. That top hash is the root. If even one underlying balance changes, the root changes. So publishing the root is a commitment to the full dataset as it existed at the snapshot.

Now imagine a customer named Maya. After the snapshot, the exchange gives Maya her leaf data and a small set of sibling hashes that connect her leaf to the root. Maya recomputes the path upward. If her calculation matches the published root, she knows her balance was included in the liability set committed by the exchange. She does not need to see every other customer record. That is the efficiency gain.

But the details matter more than people often realize. Early explanations of Merkle-based proof of reserves pointed out two subtle privacy and integrity requirements. First, leaf data should include something unique to the customer, so two customers with identical balances do not receive the same proof and become linkable. Second, leaves should include a fresh random nonce known only to the customer and exchange, so customers cannot infer too much about neighboring leaves or correlate accounts across different proofs over time. Without those precautions, a seemingly privacy-preserving tree can leak more than intended.

There is another operational issue: the exchange must commit publicly to a single root. If it can privately show different customers different roots, it can fabricate tailored trees. A public commitment (for example, publishing the root through a well-known channel, or anchoring it on-chain) reduces that risk because everyone can verify they are checking against the same declaration.

Even with these safeguards, Merkle proofs by themselves do not force correctness. They allow customers to detect omission if they check and discover their balance was left out or altered. But detection depends on participation. If many users never verify, an exchange may hope that omissions remain unnoticed.

What do zero-knowledge proofs add to proof-of-reserves, and what limits remain?

Merkle trees are popular because they are practical, but they leak structure. Even when balances are hashed, the operator still has to choose how much metadata to reveal, how customer identifiers are derived, and how totals are computed. Zero-knowledge methods try to strengthen the proof by reducing what must be exposed.

The key idea is straightforward: instead of publishing the sensitive data, publish a proof that a statement about the data is true. In proof-of-reserves settings, the statement might be: *the sum of liabilities in this committed ledger equals L; the sum of assets under keys I control equals A; and A - L is at least zero`. * Outsiders verify the proof without learning the full ledger, the institution’s exact wallet set, or in some designs even the aggregate totals.

The Provisions paper is the canonical research treatment of this approach. It builds the problem from three protocols. For assets, the exchange constructs a proof over an anonymity set of public keys, combined with Pedersen commitments and zero-knowledge proofs, to show that the balances of the keys it controls sum to a committed amount. For liabilities, it commits to customer balances using Pedersen commitments and proves properties such as nonnegativity through range proofs. Then it combines the commitments homomorphically and proves that the difference is zero in the committed space. Because Pedersen commitments are additively homomorphic, commitments to separate values can be combined into a commitment to their sum or difference without revealing the values themselves.

This is powerful for two reasons. First, it can preserve commercial and operational privacy. The exchange may not want to publish all wallet addresses, total holdings, or customer totals. Second, it can make the proof more complete by binding assets and liabilities together in one cryptographic argument rather than leaving the comparison to trust in a report.

But stronger cryptography does not make the real-world problem disappear. The proof still depends on the snapshot’s scope and correctness. If liabilities are excluded before they ever enter the committed ledger, zero knowledge proves the wrong statement very elegantly. And some constructions have technical limits. Provisions, in its basic form, cannot support every possible Bitcoin script type; it works cleanly only for cases tied to a single public key whose public key is already revealed. Extending to more complex script conditions may require heavier tools such as zk-SNARKs or further protocol work.

What does a credible exchange proof of reserves look like in practice?

Consider a centralized exchange that holds ETH, BTC, and SOL for its users. On the day of the snapshot, it freezes a liability view of all customer accounts included in the proof. For each user, it computes a leaf from a user-specific identifier, the asset balance, and a fresh nonce. Those leaves are hashed into a Merkle root for each asset or for a structured multi-asset ledger, depending on the implementation. The exchange publishes the roots and the snapshot time.

At the same time, it assembles the wallets it claims as reserves. For Bitcoin, it signs a challenge from the relevant addresses or uses a privacy-preserving proof of control. For Ethereum and Solana, it can similarly demonstrate control through signatures or on-chain movements, while observers inspect balances at the chosen block heights. Now there is public evidence that the exchange controls a set of on-chain assets at the snapshot.

An independent auditor may then test whether the internal ledger extract used for the Merkle roots was complete under the agreed scope, whether negative balances were treated appropriately, whether excluded accounts were justified, and whether the summed liabilities match the published commitments. Some operator descriptions, such as Kraken’s, emphasize exactly this point: meaningful proof of reserves requires both proof of assets and proof of liabilities, plus a way for clients to verify their own inclusion.

After publication, a customer logs into a verification portal, retrieves their leaf data and Merkle branch, and recomputes the root. If it matches the published root, the customer has evidence that their balance was included in the liability snapshot. If the auditor’s report and public asset proofs also indicate that reserves exceed liabilities, the customer now has a bounded but real transparency signal: at that moment, within that scope, the exchange appeared fully reserved.

Notice what made the example credible. It was not any single cryptographic gadget. It was the combination of a committed liabilities set, client-level inclusion checking, evidence of wallet control, and some independent procedure over the mapping from internal records to the public commitment.

When and how can proof-of-reserves be misleading or fail?

Most misunderstandings come from asking proof of reserves to answer questions it was not built to answer. The first limitation is timing. These proofs are usually snapshots. An institution can appear solvent at one moment and become insolvent later. It can even borrow assets temporarily to look healthy at the checkpoint. This is why periodic attestations improve transparency but do not eliminate gaming.

The second limitation is scope. A proof only covers what it includes. If an exchange proves reserves against customer spot balances but has large off-balance-sheet obligations, loans, guarantees, or affiliated-party exposures outside the liability set, users may overread the proof. Likewise, an issuer can show that token circulation is backed by reserves while leaving open important questions about reserve quality, encumbrances, legal segregation, or operational redemption capacity.

The third limitation is user participation. Merkle-based liability proofs rely on customers checking inclusion. If few users verify, omission becomes harder to detect. The early Merkle-tree literature was explicit about this: the system works only if a significant portion of customers actually perform the check they are empowered to perform.

The fourth limitation is that control is not the same as availability. A signed message proves key control, not that the asset is unencumbered or readily withdrawable for customers. Some reserve assets may sit in custodial accounts, separately managed accounts, money market funds, or other structures. That does not make them unreal, but it means “on-chain balance visible in a wallet” is not the only custody pattern and not always the strongest economic test.

The fifth limitation is behavioral. Proof of reserves does not guarantee willingness to honor withdrawals, prevent fraud, or stop post-audit theft. Both early explainers and the Provisions paper make this point clearly: a successful proof says something about a snapshot, not about future honesty. Enforcement history around failed crypto firms reinforces the broader lesson. A business can present reassuring public narratives while its internal records, risk transfers, or use of customer assets tell a different story.

Why involve auditors in proof-of-reserves, and what can they not guarantee?

Cryptography helps because it reduces room for quiet manipulation. But cryptography does not decide which liabilities belong in scope, whether internal records are complete, or how to treat unusual assets and obligations. Those are assurance problems as much as they are protocol problems.

That is why many practical proof-of-reserves programs involve independent accountants or auditors. Practitioner guidance emphasizes that outside assurance can test data completeness, controls, and the mapping between company records and the public proof. Operator commentary makes the same point more bluntly: wallet screenshots or unsigned address lists are not proof, and a liability root without independent challenge procedures can still conceal omissions.

Still, independence is not magic. Industry guidance also notes that there is no single universal standard for proof-of-reserves engagements, and some accounting frameworks sharply distinguish reserve attestations from broader solvency opinions. In the United States, for example, practitioner materials cited in the evidence emphasize that certain standards do not treat “solvency” in the broad legal-financial sense as the object of the attestation. So an attested reserve report can be valuable while still being narrower than many readers assume.

Recent institutional developments show this gap being narrowed rather than closed. The PCAOB has publicly stressed that auditors must respond to crypto-specific risks, including fraud. The AICPA has published stablecoin reporting criteria intended to support more consistent disclosure around backing assets for asset-backed fiat-pegged tokens. These efforts matter because proof of reserves becomes much more useful when the cryptographic layer is paired with a clear assurance scope and repeatable reporting criteria.

How is proof-of-reserves applied by custodial exchanges and stablecoin issuers?

The concept appears in two main forms.

For custodial trading platforms, the problem is mostly proving that customer account balances are backed by controlled digital assets. Here the classic architecture is proof of assets plus proof of liabilities, often with Merkle-tree inclusion checks for users and some independent review of the ledger extraction. This is the setting most people have in mind when they talk about exchanges proving reserves.

For stablecoin issuers, the pattern is related but not identical. The issuer is typically trying to support a redeemability claim, such as one token being redeemable 1:1 for a fiat currency. In that case, the liabilities are token supply and redemption obligations, while the assets may be cash, Treasuries, reverse repos, or fund holdings rather than only on-chain coins. Circle’s public transparency program illustrates this broader style: weekly reserve disclosures and monthly third-party assurance that reserves exceed USDC in circulation. The mechanism is still proof of backing, but the asset side extends beyond what blockchains alone can reveal.

This difference is worth remembering because “proof of reserves” is not chain-specific and not limited to native crypto collateral. The core idea is always the same: publicly constrain an institution’s claims about backing assets and customer entitlements. But the evidence available changes with the asset architecture. Bitcoin held in self-controlled addresses invites one style of proof. Treasury bills held through custodians invite another.

Conclusion

**Proof of reserves is best understood as a transparency control for custodial risk. ** It exists because customers can usually see neither side of the balance sheet on their own: assets may be partly visible but not attributable, while liabilities are attributable but not visible. The mechanism of proof of reserves is to bind those two sides together through cryptographic commitments, wallet-control proofs, and often independent assurance.

The memorable version is simple: assets, liabilities, and a verifiable match between them. If any of those pieces is missing, the proof is weak. If all are present, the result is still not a guarantee of future honesty; but it is a meaningful reduction in opacity, which is exactly the problem proof of reserves was designed to solve.

What should I verify before taking exposure to a custodian’s proof-of-reserves?

Before taking exposure to an operator based on its proof-of-reserves, verify the legal structure, the proof’s scope, and custody arrangements; then use Cube Exchange to execute only after those checks are complete. On Cube, you can fund an account and trade or allocate after you confirm that the reserve evidence, auditor attestations, and custody terms match the exposure you intend to take.

1. Request the custodian’s legal-entity chart and account terms; confirm the legal entity that issues redemptions and the governing law.
2. Download the published proof-of-reserves artifacts (Merkle root or ZK proof), note the snapshot time and anchoring method, and save the independent auditor’s report that describes the assurance scope.
3. Obtain custody statements and counterparty confirmations showing segregation and encumbrance status; if possible, schedule a test withdrawal or confirm a documented settlement timeline.
4. Match the exposure type (spot, tokenized Treasury, or redeemable stablecoin) to the proof scope; then fund your Cube account via fiat or a supported crypto transfer, open the relevant market or transfer flow, choose order type (limit for price control, market for immediacy), review fees and settlement terms, and submit.