Proof of reserves: what it proves, and what it cannot

Proof of reserves is one of the crypto sector’s most visible answers to a basic question: does a platform hold assets corresponding to the balances shown in its customers’ accounts?

A well-designed proof of reserves can provide useful evidence. It may demonstrate that specified digital assets existed at identifiable blockchain addresses at a particular time, that the platform could exercise control over those addresses, and that an individual customer balance was included in a committed set of liabilities. If the asset and liability sides use compatible scopes and measurements, the exercise can also show that the in-scope assets equalled or exceeded the in-scope customer balances at the snapshot time.

Each qualification matters. Proof of reserves is not a standardised term, and reports carrying the label can differ radically. Some publish little more than wallet addresses. Others combine blockchain balances, a cryptographic commitment to customer accounts and work performed by an independent accountant. More advanced systems add zero-knowledge proofs or frequently updated monitoring.

Even the strongest version remains narrower than a full financial statement audit and narrower than a legal assessment of how customer property would be treated in an insolvency. Proof of reserves can improve transparency, but only if its exact claim is understood.

What proof of reserves is trying to establish

For a custodial exchange, the central comparison is usually between two quantities:

• Reserves: assets held at blockchain addresses or with other custodians that the platform identifies as being within the exercise.
• Customer liabilities: the platform’s obligation to customers represented by account balances for the assets and products included in the exercise.

A reserve ratio is commonly expressed as in-scope reserves divided by in-scope customer liabilities. A ratio of 100 per cent means the measured assets equal the measured customer balances. More than 100 per cent indicates an excess within that defined scope.

This comparison is more informative than publishing wallet balances alone. A large wallet says nothing about adequacy without a corresponding measure of what the platform owes. Equally, a total liability figure is difficult to evaluate without evidence that the matching assets exist and are available to the entity responsible for those liabilities.

The word reserves is also used in a different context for stablecoins and tokenised assets. There, it can refer to assets backing tokens issued into circulation, including cash, bank deposits or government securities held off-chain. The verification methods, legal obligations and liquidity questions may therefore be quite different from those applying to an exchange’s custody of native crypto-assets.

How Merkle proofs represent customer liabilities

A platform cannot responsibly publish a list connecting every customer to every balance. That would expose confidential financial information. Merkle trees offer a way to commit to a large dataset while allowing limited verification.

The process begins with account records. Each record, or a structured representation of it, becomes a leaf in the tree. A cryptographic hash function converts the leaf data into a fixed-length output. Pairs of hashes are combined and hashed again, then the resulting hashes are repeatedly combined until one value remains. That final value is the Merkle root.

The root acts as a compact commitment to the dataset used to construct the tree. Altering a balance, removing a leaf or changing another committed field changes the hashes above it and ultimately produces a different root.

A customer can receive their leaf information and a Merkle path containing the neighbouring hashes needed to reconstruct the route to the root. By performing the hash calculations, the customer can test whether their record was included in the tree associated with the published root. The proof grows logarithmically rather than linearly, so it remains relatively compact even when the tree contains millions of accounts.

This is an inclusion proof. It demonstrates that a particular record belongs to the committed dataset, provided the cryptographic construction and verification software are sound. It does not independently demonstrate that every legitimate customer was included. A platform could omit an account from the source data and still create a mathematically valid tree. Detection depends partly on affected customers checking their own inclusion, and partly on procedures that test the completeness of the underlying ledger.

Nor does a basic inclusion proof necessarily prove that the total displayed at the root was calculated correctly. Implementations may augment the tree with balance sums, independent reconciliation or zero-knowledge proofs. A zero-knowledge system can, for example, prove that committed account balances satisfy specified rules and add to a stated total without revealing every balance. Binance describes a zk-SNARK system designed to prove that user balance sets contribute to its claimed aggregate balance and that each included account has a non-negative net balance.

Those additions address particular weaknesses, not every weakness. A cryptographic proof establishes the truth of the statement encoded in its circuit or protocol. It cannot establish that the input ledger captured all obligations unless completeness is itself supported by reliable source records, controls and verification procedures.

The liability side is where scope becomes decisive

Customer liabilities are more complicated than the numbers visible in spot wallets. A platform may offer margin trading, derivatives, lending, staking, institutional custody or products involving assets held by sub-custodians. Open positions can create receivables, collateral obligations and unrealised gains or losses. Fiat balances and assets outside the report may be omitted.

A useful disclosure therefore identifies the legal entities, products, assets, account types and valuation rules in scope. It also explains how negative balances, borrowed assets, pending transactions and open positions are treated. Kraken’s published methodology, for example, distinguishes spot, staking, margin and futures balances and warns that verification reflects only in-scope assets at the snapshot time.

Netting deserves particular attention. If positive and negative customer balances are offset, a platform can present a lower aggregate liability than the gross amount customers believe is held for them. Some cryptographic designs prohibit negative account-level totals, reducing one form of manipulation. That still does not answer how cross-asset debts, corporate borrowing or obligations outside the customer ledger have been treated.

The crucial distinction is between customer liabilities included in the proof and all liabilities of the business. Trade creditors, loans, tax obligations, legal claims and amounts owed to entities outside the selected population can affect solvency without appearing in a proof-of-reserves calculation.

Existence, ownership and control are different claims

A blockchain explorer can establish that assets exist at an address. It cannot identify the legal owner of those assets merely by reading the ledger.

A platform may demonstrate technical control by signing a challenge message with the relevant private key or by making a specified transaction. This is stronger evidence than an unsupported claim that an address belongs to the platform. It shows that the platform, or someone cooperating with it, could authorise activity from the address at that time.

Control is not identical to unencumbered ownership. The assets might have been borrowed temporarily, pledged as collateral, subject to another party’s rights or held under an arrangement that limits their use. They might belong to customers, the operating company, an affiliate or a mixture of those groups. A valid signature does not reveal these legal and contractual relationships.

Control can also be operationally divided. Multisignature wallets, third-party custodians and key-management systems may require several parties to approve a transfer. A report needs to describe what evidence was obtained and what conclusion that evidence supports. Calling every signed address “owned” can overstate the result.

Off-chain assets present a further challenge. Bank deposits, government securities and assets held through conventional custodians cannot be verified directly on a public blockchain. Evidence may instead include bank confirmations, custody statements, title records and valuation work. At that point, the exercise depends substantially on accounting evidence and the reliability of third parties rather than public cryptography.

The point-in-time problem

Most proof-of-reserves exercises are snapshots. They answer a question about a specified date and time, not about the period before or after it.

The US Public Company Accounting Oversight Board has warned that a proof-of-reserves report may not reveal whether assets were borrowed to make reserves appear sufficient at the snapshot. It also notes that a point-in-time report provides no assurance that assets were not subsequently used, lent or made unavailable to customers.

This is sometimes described as window dressing. Assets can be transferred into identified wallets before a known measurement time and moved out afterwards. Coordinated or unannounced snapshots, transaction testing and continuous monitoring can make that behaviour harder, but each approach has limits. Continuous observation of disclosed addresses still cannot see undisclosed wallets, off-chain obligations or private contractual encumbrances.

Timing can also create ordinary mismatches. Blockchain confirmations, internal ledger cut-offs and transactions in flight must be reconciled to a common snapshot. Without a clear cut-off policy, an apparent shortfall or surplus may result from inconsistent timing rather than the underlying financial position.

Why an attestation is not automatically an audit

The words audit, attestation, review and agreed-upon procedures are not interchangeable. The report itself should identify the type of engagement, the standards applied, the responsible practitioner, the subject matter and the level of assurance, if any.

In an agreed-upon procedures engagement, the practitioner performs procedures selected by the engaging parties and reports factual findings. The practitioner does not express an opinion about whether the procedures were sufficient or whether the business is financially sound. A limited- or reasonable-assurance attestation may reach a conclusion on a defined assertion, but it remains bounded by that assertion and the applicable criteria.

A financial statement audit addresses financial statements as a whole under an established reporting framework. Its scope extends beyond checking selected wallet balances against selected customer records. It includes risk assessment and evidence concerning material assets, liabilities, transactions, estimates, presentation and disclosures. Depending on the applicable standards and engagement, it also involves consideration of internal control relevant to the audit.

A March 2023 advisory from the PCAOB’s Office of the Investor Advocate states that proof-of-reserves engagements are not audits under PCAOB standards and fall outside PCAOB inspection. It says such reports do not provide meaningful assurance to investors or the public and do not establish reserve adequacy, protection of customer assets, effective internal controls or sound governance.

The identity of an accounting firm therefore does not transform a narrow engagement into a financial statement audit. The decisive information lies in the signed report: what was measured, against which criteria, through which procedures, with what exclusions and with what form of conclusion.

What proof of reserves can prove

When properly designed and accurately described, proof of reserves can establish several useful propositions:

• Specified assets existed at identified blockchain addresses at the stated snapshot time.
• The platform demonstrated technical control of specified addresses through an appropriate signing or transaction procedure.
• A particular customer record was included in the liability dataset committed to a published Merkle root.
• The committed, in-scope customer balances were aggregated according to the disclosed cryptographic method.
• In-scope reserve assets equalled or exceeded in-scope customer liabilities under the report’s stated methodology and valuation rules.
• Changes to the committed liability dataset after publication would produce a different Merkle root and be detectable.

These claims can reduce information asymmetry. Public wallet evidence makes fabricated on-chain balances harder to sustain, while customer-level inclusion proofs distribute part of the verification process beyond the platform and its accountant.

What it cannot prove on its own

A proof-of-reserves result does not, by itself, prove:

• Complete solvency. Solvency depends on all assets and liabilities, their values, maturities and legal availability, not only the categories selected for a reserve comparison.
• Completeness of liabilities. A Merkle tree faithfully commits to its inputs but cannot reveal obligations omitted before the tree was built.
• Unencumbered ownership. A private-key signature demonstrates control, not freedom from borrowing, pledges, liens or competing legal claims.
• Continuing coverage. A snapshot does not establish the position before or after the measurement time.
• Liquidity under stress. Assets can equal liabilities in value yet be unavailable, slow to realise or exposed to severe price impact during mass withdrawals.
• Asset quality. Nominal coverage may depend on volatile, affiliated or thinly traded tokens whose realisable value differs from the stated valuation.
• Segregation and bankruptcy protection. Blockchain visibility does not determine whether customer assets are legally separated from the platform’s estate.
• Effective controls or governance. A reserve calculation does not test the broader systems that prevent misuse, errors, unauthorised transfers or misleading reporting.
• Protection against fraud. Cryptography can make alteration of committed data evident, but it does not guarantee honest source data, complete disclosure or trustworthy business conduct.

Regulation asks broader questions

Proof of reserves is a transparency mechanism, not a substitute for the legal duties imposed on regulated custodians or issuers.

In the European Union, the Markets in Crypto-Assets Regulation requires crypto-asset service providers holding client assets to safeguard clients’ ownership rights and prevent the use of those assets for the provider’s own account. MiCA also requires custody providers to segregate client crypto-assets from their own holdings, including legal and operational segregation, and to maintain procedures for returning assets or means of access. These are substantive custody requirements. A favourable reserve ratio does not itself prove compliance with them.

MiCA separately regulates reserves for asset-referenced tokens and e-money tokens. Its provisions cover the composition, custody, investment and management of reserve assets, as well as redemption rights and independent audits for relevant issuers. This regime illustrates the difference between publishing a cryptographic snapshot and satisfying rules governing what reserves may contain, where they are held and how holders can claim against them.

In the United States, the GENIUS Act became law on 18 July 2025 and establishes a federal framework for permitted payment stablecoin issuers. Its operative provisions specify identifiable reserve assets backing outstanding payment stablecoins on at least a one-to-one basis, restrictions on pledging, rehypothecating or reusing those reserves subject to stated exceptions, monthly public reserve disclosures, accountant examinations of monthly reports and regulatory supervision. As at 8 September 2026, the Act was not yet generally effective: the OCC stated that it would take effect on the earlier of 18 January 2027 or 120 days after the primary federal regulators issue final implementing regulations, and implementing rules remained proposed. Its scope is payment stablecoin issuance, not a general proof-of-reserves mandate for every crypto exchange.

These examples show why regulatory compliance cannot be inferred from a PoR badge. Legal frameworks may address authorisation, custody agreements, segregation, capital, redemption, risk management, record-keeping, conflicts, governance and insolvency. Proof of reserves covers only part of that terrain.

A precise way to read the claim

The most accurate interpretation of a proof-of-reserves publication is conditional:

At the stated time, under the stated methodology, the disclosed evidence supports a comparison between the specified assets and the specified customer liabilities included in the exercise.

Its strength depends on what follows that sentence. Are all relevant entities, assets and products included? Can customers verify their own liability records? Does the system prove correct aggregation as well as inclusion? How was control of wallets demonstrated? Were encumbrances and borrowed assets examined? Are off-chain holdings independently confirmed? Is the report signed, current and explicit about the assurance provided?

A reserve ratio or an accessible Merkle proof should therefore be read as a starting point, not the endpoint. The consequential questions sit at the boundaries: completeness, legal ownership, encumbrance, timing, liquidity and the exact status of third-party work.

Proof of reserves is best understood as a component of transparency infrastructure. It can make a narrow factual claim more testable than a corporate promise. It cannot compress an entire balance sheet, custody regime, control environment and insolvency analysis into one hash. The distinction is not an argument against proof of reserves. It is the condition for describing honestly what the proof has established.