What Proof of Reserves Actually Proves — and What It Does Not
Proof of reserves (PoR) is a mechanism by which a crypto gateway or custodian demonstrates that it controls on-chain assets sufficient to cover all client balances. It proves two things: that a set of blockchain addresses contains at least the claimed amount of cryptocurrency (demonstrable on-chain), and that individual clients are included in the aggregate balance claim (demonstrable through Merkle proofs). What it does not prove — and this is critical — is that the demonstrated assets are not simultaneously pledged as collateral elsewhere, not subject to security interests from lenders, not controlled by addresses the custodian does not actually control, or sufficient to cover future liabilities not yet reflected in client balances.
FTX's collapse was instructive: FTX could theoretically have produced a proof of reserves showing Bitcoin addresses with sufficient BTC — while simultaneously having pledged those Bitcoin as collateral for loans to Alameda Research, made from customer assets without customer knowledge. A true PoR requires not just asset verification but liability verification — ensuring that the demonstrated assets are unencumbered and available to cover client claims. This combined 'proof of solvency' is more demanding than simple PoR and requires auditor involvement to verify off-chain liability records.
The Merkle Tree Mechanism for Individual Verification
The Merkle tree component of PoR allows individual clients to verify their own inclusion in the aggregate reserve claim without seeing other clients' balances. The process works as follows: the gateway assigns each client's balance as a leaf node in a binary Merkle tree; each node's hash is computed from its two children; the root hash summarises the entire tree. To prove a specific client is included, the gateway provides: the client's leaf value (their balance), and the Merkle proof — the sequence of sibling hashes needed to recompute the path from the client's leaf to the root.
The client can independently verify that their balance is in the tree by recomputing the root hash from the provided values and confirming it matches the published root hash. This verification is cryptographically sound — the client cannot be excluded from the tree while the root hash remains valid. Third-party auditors can also verify that the sum of all leaf balances equals or is less than the on-chain holdings, confirming aggregate solvency at the verification date.
Regulatory Requirements for Reserve Verification
MiCA imposes reserve requirements on EMT and ART issuers: reserves must be invested in high-quality liquid assets, segregated from the issuer's own assets, and managed in the client's interest. These requirements apply to stablecoin issuers, not directly to payment gateways. However, the principles are informing regulatory expectations for custodial crypto service providers more broadly. MiCA CASPs providing custody must segregate client assets and demonstrate that segregation — which is a functional equivalent of reserve verification.
In the US, there is no federal PoR requirement for MSBs or crypto custodians at the federal level, though state-level licensing may impose reserve or capital requirements. The 2023 FDIC guidance on crypto-related activities and the OCC's framework for bank-issued stablecoins both include reserve management expectations. Institutional clients — funds, family offices, corporate treasuries — increasingly require proof of reserves or equivalent attestation as a condition of using a custodian or gateway for significant balances.
Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.