Crypto exchanges increasingly publish proof-of-reserves material to demonstrate that customer balances are supported by digital assets. Yet the label covers different forms of verification, and a favorable snapshot does not by itself establish that an exchange is solvent. A BlockBriefing review of published provider documentation and a U.S. audit regulator’s warning highlights the distinction between evidence of holdings and comprehensive assurance about financial obligations.
The Public Company Accounting Oversight Board’s investor advisory states that proof-of-reserves engagements are not audits under its standards and do not offer the assurance associated with audited financial statements. It specifically flags unresolved questions about liabilities, borrowed assets, internal controls and what happens after a snapshot. The advisory is a caution about the method, not an allegation that any exchange has misrepresented its reserves.
What a Merkle proof actually verifies
A Merkle tree allows users to verify that a particular balance record was included in a larger dataset represented by a cryptographic root. It can help identify an omitted customer entry, subject to the design and availability of the verification procedure. But inclusion in a dataset does not independently prove that the entire dataset contains every customer liability, nor that the institution has no separate debts or claims against assets.
In its December 2025 proof-of-reserves disclosure, Kraken says its process includes customer liabilities, a user-level verification mechanism and third-party checks of relevant assets. That is a more detailed claim than simply publishing wallet addresses. Even so, the report concerns specified assets and a particular review date; it should not be read as a continuously updated company-wide audit.
The time and ownership gaps
A wallet balance can be visible on-chain without demonstrating who has the ultimate economic claim to the tokens. A snapshot also cannot establish whether assets were borrowed temporarily, pledged elsewhere or moved afterward. Those questions require procedures beyond inspecting a blockchain address. Kraken’s verification documentation describes reconstructing an account’s Merkle path, but that process answers an inclusion question, not every question about company finances.
The PCAOB separately identifies governance and internal controls as areas outside the usual scope of proof-of-reserves engagements. A report may therefore be technically accurate within its agreed procedures and still leave customers unable to assess liquidity management, off-chain obligations, legal ownership or the financial condition of affiliated companies. These gaps become especially important during a run, when withdrawal demand and asset availability can change rapidly.
How customers can assess disclosures
The practical test begins with the report’s scope. Readers should identify the snapshot timestamp, supported assets, treatment of margin and derivatives accounts, the liabilities included, and whether the verifier has described its procedures. They should distinguish a cryptographic inclusion check from independent assurance over a balance sheet, review whether exceptions were identified and look for disclosures about subsequent changes.
An exchange that offers no customer-level inclusion check requires greater reliance on management’s account of what was measured. Conversely, having a check does not eliminate the need to examine the auditor’s actual report, qualifications and limitations. Consumers also should not infer that proof-of-reserves participation protects against hacks, insolvency, frozen withdrawals or legal disputes. Those are different risks requiring different evidence.
Methodology and findings
This review compares the PCAOB’s published limitations with Kraken’s public methodology and historical reserve disclosure. It does not audit Kraken, independently verify exchange wallets or establish the solvency of any named institution. The defensible conclusion is narrower: better reserve reporting can increase transparency, but a cryptographic snapshot is not a substitute for comprehensive financial statements and controls assurance.
The underlying evidence and its limitations
The starting point is the PCAOB Office of the Investor Advocate’s March 2023 advisory. It describes proof-of-reserves work as inherently limited and emphasizes that engagements differ in scope and methodology. The document itself expressly represents the views of investor-advocate staff, not a formal rule or policy of the PCAOB. That nuance matters: it is strong evidence about the limitations the office identified, not a regulatory finding that a particular exchange was deficient. The warning concerns what the measurement does not establish, regardless of whether the reported balances are mathematically correct.
A second primary document is Kraken’s public proof-of-reserves methodology, which explains how an individual can reconstruct a record identifier and Merkle leaf, then compare the result with the tree root used in a third-party review. This is a useful operational demonstration because it presents an action customers can take rather than merely asking them to trust a headline reserve ratio. The publicly described workflow, however, still must be interpreted through the accountant’s actual engagement scope, the assets tested and the review date.
What an individual balance check can establish
Consider a hypothetical customer whose exchange account contained a defined balance at the published snapshot time. If the exchange discloses the appropriate record information and Merkle proof, the customer can verify that a corresponding record was included in the committed tree without learning other users’ balances. Successful verification offers evidence against omitting that individual’s account from the disclosed dataset. It does not show whether other accounts were omitted, whether internal liabilities were categorized correctly or whether related companies have claims against the assets. An apparently complete tree is only as reliable as the source records used to construct it.
A user who finds that an account is missing or misrepresented can raise a concrete discrepancy with the exchange or reviewer. That is meaningful, particularly when many customers are able to independently test their inclusion. But participation may be uneven: inactive customers might never inspect their records, and users cannot necessarily reconstruct the entire liability ledger. The presence of a publicly available checker is therefore different from independently demonstrating the completeness of every account and every liability category.
Asset ownership is a separate question
Blockchain records can show that tokens exist at an address and may help establish that an entity can sign a message with a relevant private key. Neither proves the company owns those tokens free of restrictions. An address could hold collateral pledged to a lender, assets borrowed for a short period or funds connected to another business within a corporate group. The PCAOB advisory explicitly raises temporary borrowing as an example of a risk that limited procedures may not detect. Comprehensive ownership testing would require legal documentation, counterparty records and other evidence outside a blockchain explorer.
Even an accurate asset count can be insufficient if an exchange owes more than the chosen liabilities figure reflects. Customer spot balances, margin positions, futures exposures, lending arrangements, vendor obligations and affiliated-party debts are not interchangeable. A narrowly scoped reserve review may deliberately exclude some of them. Readers should look for the report’s exact definition of liabilities and whether negative balances, pledged collateral or contingent obligations are treated consistently. Without such disclosure, comparing the value of a wallet list against a headline customer figure risks false precision.
Liquidity under a withdrawal stress scenario
Solvency is not the only test of a financial intermediary. An exchange might hold assets with a reported value matching specified obligations while still lacking immediately transferable assets on the networks customers need. Frozen addresses, custodial delays, pending settlement, legal injunctions, operational controls and crowded withdrawal infrastructure can constrain access. Liquidity risks are especially acute when many users seek payment simultaneously. A proof-of-reserves snapshot ordinarily does not model how quickly assets could be delivered during a run or how counterparties would react.
For a customer, the decisive questions may include whether withdrawals remain operational, how quickly requests are processed, whether client assets are segregated and how disputes are handled. Those are not answered merely by confirming inclusion in a Merkle tree. Where an exchange provides audited financial statements or regulatory filings, they may supply additional evidence about obligations, governance and risk management, although they also have scope limitations and are dated. Different types of disclosure should complement rather than substitute for one another.
What a stronger transparency package would contain
A more informative disclosure would identify the legal entities and customer products in scope; define eligible assets and liabilities; explain whether accounts with negative or borrowed balances are included; name the verifier and applicable engagement standard; describe the snapshot methodology; and provide a customer-level inclusion check. It would also publish exceptions and limitations in accessible language. A periodic schedule helps readers assess continuity, but a regular snapshot still cannot guarantee uninterrupted availability of funds between reviews.
A credible verification framework should also address change management. If major asset movements, new liability products, ownership arrangements or significant legal restrictions arise after the measurement, customers need material updates rather than relying indefinitely on a previously positive number. The strongest reporting separates independently tested facts from management representations. Marketing phrases such as ‘fully backed’ should be traceable to a defined calculation and to named entities, not generalized from a single chain balance.
Methodology, scope and right of reply
This investigation reviewed the regulator’s advisory and the exchange’s public verification instructions. It did not obtain proprietary account ledgers, private loan agreements or unredacted reviewer work papers. No adverse finding is made about Kraken or other named exchanges; the examination is of verification methods and disclosure gaps. A definitive solvency conclusion would require a substantially broader financial and legal examination. Future coverage should examine new reports individually, identify the reviewed entities and dates, and invite relevant institutions to clarify materially ambiguous claims before drawing company-specific conclusions.
The reader’s bottom line
The strongest available inference from a successful inclusion check is that a particular balance appears within a defined cryptographic commitment at a defined time. It is not that every liability has been counted, every asset is unencumbered or every customer will be able to withdraw immediately. The PCAOB’s warning and the exchange’s own methodology can both be true: cryptographic verification offers a useful form of transparency while remaining materially different from an audit of a business’s finances. Treating the two as interchangeable would obscure, rather than reduce, customer risk.
