Proof of reserves

Conceptual illustration of a proof-of-reserves method.

Proof of reserves (PoR) is a set of methods used by cryptocurrency custodians to provide evidence about assets held at a stated time. A reserve disclosure may identify on-chain addresses, demonstrate control of keys, or compare assets with a representation of customer balances. The term is used for procedures with different scopes, so the evidence and limitations of each report must be read rather than inferred from the label.

Proof of reserves is not automatically proof of solvency. Solvency depends on the custodian's complete assets and liabilities, their valuation, legal ownership, encumbrances, and ability to meet obligations. A cryptographic or on-chain check can provide useful evidence without being a financial-statement audit.

Components

Reserve assets

For transparent blockchains, a custodian can publish addresses and let observers calculate balances at a specified block height. It may also sign a challenge or perform a transaction to demonstrate control of the relevant signing keys. These procedures can show an on-chain amount and evidence of technical control, but they do not by themselves establish beneficial ownership, whether an asset is pledged elsewhere, or whether all custodian-controlled addresses were included.

Reserve reports should identify the assets, networks, addresses or address-selection method, snapshot time or block height, and treatment of tokens, derivatives, borrowed assets, staking positions, off-chain assets, and cross-chain representations. A current explorer balance should not be substituted for the report's historical snapshot.

Customer liabilities

A custodian that claims customer assets are fully backed must also account for amounts owed to customers. Publishing every account would expose private financial data. Many systems therefore commit to account balances in a Merkle tree or related cryptographic structure. A customer receives a path that can be used to verify that the customer's account was included in the published root without revealing every other account.

An inclusion proof answers a limited question: whether particular data was committed into the tree. It does not independently prove that every customer and liability was included, that balances were classified correctly, or that the operator did not create negative or otherwise invalid entries. The method therefore needs rules for constructing the liability set, checks on totals and signs, privacy protections, and an independent way to detect omissions.

BitMEX, for example, publishes address-based reserve information and a Merkle-tree-based proof-of-liabilities process, while explaining these as distinct components.

Comparing reserves and liabilities

A snapshot may report a reserve ratio for each in-scope asset: qualifying reserves divided by the corresponding customer liability. Ratios are meaningful only within the report's definitions and time. Aggregating unlike assets at market prices introduces valuation and liquidity risk, while a per-asset comparison may omit obligations outside the selected assets.

Academic proposals use combinations of commitments, Merkle structures, digital signatures and zero-knowledge proofs to improve privacy and verifiability. The Provisions protocol, for example, was designed to prove that an exchange controls sufficient Bitcoin reserves to cover customer accounts without publicly revealing each account balance or reserve address.

Verification and attestations

Proof-of-reserves exercises may be performed entirely by the platform, verified by users with open-source tools, observed by an independent specialist, or reported by an accounting firm under agreed-upon procedures. These engagements are not interchangeable.

Under agreed-upon procedures, the practitioner performs specified tests and reports factual findings; the engagement does not necessarily express an audit opinion. The reader must examine who selected the procedures, what records were supplied by management, which entities and assets were covered, and whether subsequent events were considered.

The U.S. Public Company Accounting Oversight Board and Investor.gov have cautioned that proof-of-reserve reports are not equivalent to financial-statement audits and may provide no assurance about the reliability of the information, depending on the engagement.

Limitations

Common limitations include:

• a snapshot can become obsolete immediately after the observation time;
• addresses may be omitted, temporarily funded, borrowed against, or subject to undisclosed claims;
• technical control of a key does not by itself prove unencumbered legal ownership;
• customer liabilities, corporate debt, derivatives, pending withdrawals, or related entities may be out of scope;
• a customer can verify inclusion of an account without being able to detect omitted accounts belonging to other customers;
• privacy can be weakened if account balances or verification identifiers are poorly designed;
• tokens may be illiquid, concentrated, issued by a related party, or valued inconsistently; and
• the report may not evaluate governance, cybersecurity, internal controls, operational continuity, or the custodian's ability to process withdrawals.

Proof of reserves is therefore best treated as one transparency control. Stronger evidence combines reproducible on-chain data, proof of control, a complete and privacy-preserving liability commitment, clear scope and valuation rules, independent verification, frequent snapshots, and conventional financial and legal disclosures.

Relationship to notable addresses

Public reserve disclosures can be an important source for identifying the operational role of a large blockchain address. The attribution must remain dated and scoped. If an exchange listed an address in a reserve report, that supports saying the exchange presented it as an in-scope reserve address at that time; it does not necessarily show that the exchange beneficially owns every coin, because custodial addresses may represent assets owed to customers.

Address rankings should therefore distinguish on-chain balance, technical control, disclosed operational role, and beneficial ownership. See 34xp4vrocgjym3xr7ycvpfhocnxv4twseo-bitcoin for an example of an address included in a Binance reserve disclosure.

See also

• Bitcoin address
• Cold storage
• Cryptocurrency exchange
• Merkle tree