Skip to content
Financial Context Wiki

Proof of Reserves

Proof of Reserves can show that a custodian controlled specified assets at a stated time and, in stronger designs, committed to a defined set of customer liabilities. It does not by itself prove solvency, liquidity, legal ownership or future withdrawal capacity.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Proof of Reserves (PoR) is evidence about a custodian’s reserves under a stated scope and at a stated time. A basic asset-only exercise may show that the custodian controlled particular blockchain addresses. A stronger construction combines proof of assets with a cryptographic commitment to in-scope customer liabilities, allowing each participating customer to verify that their balance was included. The phrase has no single universal procedure, assurance standard or legal effect, so the report itself must define what was tested.

PoR is not automatically proof of solvency. Solvency requires eligible assets to cover all relevant liabilities, not merely the liabilities selected for a tree or report:

Coverage ratio = eligible reserve assets / in-scope customer liabilities

Surplus = eligible reserve assets - in-scope customer liabilities

A ratio at or above 100% is meaningful only if the asset and liability populations are complete, measured at the same cutoff, valued consistently and attributable to the same legal entity. It can still omit corporate debt, pending withdrawals, fiat obligations, affiliate balances, derivatives, assets outside the named products or liabilities outside the named tokens.

PoR also differs from liquidity and customer asset protection. Solvency asks whether asset value covers liabilities; liquidity asks whether usable assets can meet withdrawals when due. Control of a private key does not prove that an asset is unborrowed, unpledged, free of liens, segregated for customers or legally available to them in insolvency. A point-in-time snapshot does not prove that the same condition existed before the cutoff or continued afterward.

Proof of Reserves
0 / 5
0 items reviewed; 5 items still unresolved

Completing this review does not prove an asset, transaction, or system is safe.

How it works

A robust review connects an internal accounting population to externally verifiable assets. Cryptography can make commitments tamper-evident and preserve customer privacy, but it cannot determine which entities, accounts and obligations management should have included. The process should make these seven steps explicit:

  1. Define the reporting boundary. Name the legal entity, products, customer classes, assets, networks, valuation rules, snapshot time and block heights. State whether the exercise covers spot, margin, derivatives, staking, lending, fiat and off-platform custodians.
  2. Reconcile the liability population. Tie the customer ledger to books and records at the cutoff. Address pending deposits and withdrawals, fees, loans, collateral, negative balances, duplicate accounts and balances held through affiliates or sub-custodians.
  3. Commit to customer liabilities. Encode the in-scope balances in a Merkle tree, zero-knowledge circuit or other commitment. Publish the root and total, prevent negative balances from reducing the claimed liability, and give customers enough data and software to verify inclusion without revealing other customers.
  4. Establish asset existence and control. Identify in-scope on-chain addresses and obtain signatures or transactions that demonstrate control at the stated block height. Reconcile custodial, bank and fiat balances through evidence appropriate to those systems.
  5. Test ownership, availability and quality. Determine whether assets are borrowed, pledged, encumbered, held for another entity, restricted, illiquid or dependent on an affiliate. Define which tokens and valuation sources qualify and how wrapped, bridged or staked positions are treated.
  6. Calculate coverage consistently. Compare eligible assets and liabilities by asset before aggregating unlike tokens. Apply the same timestamp, units and conservative valuation rules; report exclusions, shortfalls and sensitivity to price or haircut assumptions.
  7. Read the engagement and monitor continuity. Identify whether the work is an audit, assurance engagement or agreed-upon procedures report; read the exact procedures, findings, exceptions and management responsibilities. Then monitor report frequency, withdrawals, address movements, governance and internal controls rather than treating one snapshot as permanent.

A Merkle inclusion proof answers a narrow question: a leaf and its authentication path reproduce a published root. It shows that this leaf was in the committed dataset. It does not show that every real customer was included, that the balances were correct, or that another undisclosed tree does not exist. Zero-knowledge constraints can prove properties such as nonnegative balances and correct summation without revealing every leaf, but the proof is only as complete as its circuit, inputs and reporting boundary.

Asset evidence has a similarly narrow scope. A valid signed challenge can show control of a key, while an on-chain balance can show coins at an address and block height. Neither fact alone establishes beneficial ownership, absence of liens, the completeness of all wallets, or the custodian’s ability to move funds promptly without another signer, lender, court or sub-custodian.

Worked examples

Hidden liabilities reverse apparent coverage

An exchange demonstrates control of 1,050 BTC and publishes a liability tree totaling 1,000 BTC. The reported coverage ratio is 1,050 / 1,000 = 105%, with a 50 BTC surplus. If the reporting boundary omits a 120 BTC borrowing obligation, relevant liabilities are actually 1,120 BTC. Coverage falls to 1,050 / 1,120 = 93.75%, producing a 70 BTC shortfall. The arithmetic was correct for the published inputs; the population was incomplete.

Inclusion is not completeness

Suppose a toy Merkle tree contains customer balances of 2, 3, 5 and 10 BTC, totaling 20 BTC. The customer with 3 BTC can hash their leaf with the supplied sibling hashes and reproduce the published root. That verifies inclusion of the 3 BTC balance in this tree. It does not prove that an omitted customer with 4 BTC does not exist, that no account has an artificial negative balance, or that 20 BTC equals the custodian’s complete liability.

Encumbrances change usable reserves

A custodian reports $100 million of reserve assets against $95 million of in-scope customer liabilities, so reported coverage is 100 / 95 = 105.26%. If $30 million of those assets secure a separate loan and cannot be used for customer withdrawals, unencumbered reserves are $70 million. Usable coverage is then 70 / 95 = 73.68%, even though the assets remain visible at the snapshot.

A borrowed snapshot can window-dress reserves

Before a scheduled snapshot, a platform with 900 BTC against 1,000 BTC of customer liabilities borrows 200 BTC. The snapshot shows 1,100 / 1,000 = 110% coverage. After the platform returns the 200 BTC, it again holds 900 BTC and coverage is 90%. A signed address balance at the cutoff was genuine, but it did not reveal the borrowing or establish continuing solvency.

Risks and controls

Liability population and completeness

  • Omitted products or entities: a tree may cover only selected tokens, spot accounts or one subsidiary. Match the report’s legal entity and scope to the entity that owes the customer.
  • Off-ledger obligations: pending withdrawals, fiat balances, loans, derivatives, fees and corporate debt may sit outside the committed customer balances. Reconcile the tree total to complete books and records.
  • Negative-balance manipulation: artificial or misclassified negative accounts can reduce net liabilities. Require nonnegative constraints where appropriate and separately explain legitimate debt or margin accounts.
  • Customer nonparticipation: only some customers may verify their leaves, allowing omission errors to go unnoticed. Provide accessible verification tools and independent population testing.

Asset ownership, quality and encumbrance

  • Borrowed or temporarily transferred assets: a platform can control funds only around the snapshot. Use unannounced or frequent tests, transaction review and evidence of obligations, not a known-date balance alone.
  • Pledges, liens and set-off rights: visible assets may secure another claim or be subject to a custodian’s rights. Examine contracts, account titles and confirmations in addition to blockchain balances.
  • Low-quality or related-party assets: self-issued, thinly traded, bridged or affiliate-issued tokens may lose value under stress. Disclose eligibility rules, concentration and conservative haircuts.
  • Custody-chain dependence: multisignature, bank and sub-custody arrangements may limit timely access. Map every controller, approval condition and failure point.

Cryptographic and accounting implementation

  • Incorrect leaf construction: wrong customer identifiers, asset units, salts or cutoff data can produce a valid proof over bad records. Publish specifications and independently test source-to-leaf reconciliation.
  • Incomplete proof constraints: a zero-knowledge circuit proves only its encoded statement. Audit the circuit, setup assumptions, public inputs and source code; do not infer unproved accounting properties.
  • Privacy leakage: unsalted or predictable leaves can expose balances through guessing, while public customer lists reveal sensitive data. Use appropriate commitments and threat-model auxiliary information.
  • Inconsistent roots or datasets: different users can be shown different commitments, or a website can replace a root. Timestamp and sign roots, archive reports and compare views through independent monitors.

Timing, assurance and governance

  • Snapshot decay: trading, lending, hacks or transfers after the cutoff can make a report stale immediately. Prefer frequent reporting and continuous controls while recognizing that monitoring also has limits.
  • Engagement-label confusion: an agreed-upon procedures report presents specified factual findings and is not automatically an audit opinion. Read the standard, responsible party, procedures and assurance conclusion.
  • Management-selected procedures: narrow tests can omit the issues users care about. Compare the engagement scope with a complete solvency, liquidity and custody risk model.
  • Control and governance failures: PoR does not test every authorization, reconciliation, cybersecurity or related-party control. Evaluate governance and audited financial information separately where available.

User interpretation and operational response

  • Ratio aggregation: converting unlike assets and liabilities into one headline ratio can hide token-specific shortfalls and valuation risk. Review coverage by asset and under stress haircuts.
  • Liquidity mismatch: long-dated, locked or slow-to-transfer assets may cover book liabilities but not immediate withdrawals. Examine maturity, settlement and liquidation capacity.
  • Legal-rights gap: cryptographic control does not determine whether customers retain beneficial ownership or priority in insolvency. Read custody terms, segregation disclosures and applicable law.
  • False finality: a passing report can delay prudent action when withdrawals fail or scope worsens. Treat PoR as one evidence stream, not a guarantee or substitute for exposure limits and operational monitoring.

Common misconceptions

“Proof of Reserves proves the exchange is solvent”

Only a sufficiently complete proof of eligible assets and relevant liabilities can support a scoped solvency conclusion. Many reports verify selected assets at a point in time, and even a strong customer-liability commitment can omit other obligations or legal restrictions.

“My Merkle proof shows that every customer was included”

It shows that your leaf belongs to the dataset represented by one root. Completeness requires separate controls over the source population, reconciliation and the absence of omitted or manipulated accounts.

“An on-chain wallet balance proves the platform owns free assets”

The chain shows that assets existed at an address. A signature or transaction can add evidence of key control. Ownership, borrowing, pledges, liens, segregation and legal availability require evidence beyond the ledger.

“An accountant’s name means the report is a full audit”

The engagement may instead use agreed-upon procedures chosen with management and report factual findings without an opinion on reserve adequacy or financial stability. The title of the provider does not determine the scope or assurance level.

“Coverage above 100% guarantees withdrawals and bankruptcy protection”

A custodian can be balance-sheet solvent yet illiquid, operationally unable to transfer assets or subject to competing legal claims. Withdrawal capacity and customer property rights must be assessed separately.

Sources

Navigation

Search the wiki...