Proof of Reserves

What Is Proof of Reserves?

Proof of reserves is a verification method that allows a cryptocurrency custodian (such as an exchange, lender, or stablecoin issuer) to demonstrate that it controls enough assets to cover the balances it owes to customers. Rather than relying solely on trust or traditional financial audits, PoR uses cryptographic techniques to let individual users independently verify that their balance is included in the custodian's reported liabilities and that corresponding assets exist on-chain.

The concept was first proposed by Greg Maxwell in 2013 as a way for Bitcoin exchanges to prove solvency without exposing individual account data. After the collapse of Mt. Gox in 2014 and FTX in 2022, demand for transparent reserve verification accelerated. Today, PoR has become a baseline transparency expectation for centralized crypto exchanges and stablecoin issuers alike.

How It Works

A proof of reserves system has two sides: proving what the custodian owes (liabilities) and proving what it holds (assets). Each side uses distinct cryptographic and on-chain techniques.

Liability Proof: Merkle Sum Trees

The liability side uses a Merkle tree variant called a Merkle sum tree. Each leaf in the tree represents one customer account, containing a hashed account identifier and the account's balance. Parent nodes store both the combined hash of their children and the sum of their children's balances. The Merkle root at the top commits to both the complete set of accounts and the total liability.

Each customer receives a Merkle proof: the path from their leaf to the root, along with the sibling hashes needed to reconstruct it. By checking this proof, a user can verify that their exact balance was included in the total without seeing any other customer's data.

Merkle Sum Tree Structure:

        Root: hash(H_left || H_right), sum = 150 BTC
       /                                          \
  Node A: hash(...), sum = 90 BTC       Node B: hash(...), sum = 60 BTC
   /              \                       /              \
Leaf 1           Leaf 2              Leaf 3           Leaf 4
user: h(alice)   user: h(bob)       user: h(carol)   user: h(dave)
bal: 50 BTC      bal: 40 BTC        bal: 35 BTC      bal: 25 BTC

Each user verifies their leaf is in the tree.
The root commits to total liabilities: 150 BTC.

Asset Proof: On-Chain Attestation

The asset side requires the custodian to prove control of on-chain addresses holding at least as much value as the Merkle root's total. The most common method is signing a challenge message with the private keys of each reserve address. Since only the key holder can produce a valid digital signature, this proves the custodian controls those funds at the time of signing.

Anyone can then look up those addresses on a block explorer to confirm the balances. If the sum of verified on-chain balances meets or exceeds the Merkle root's total liability, the custodian has demonstrated a reserves ratio of 1:1 or greater.

Zero-Knowledge Enhancements

Maxwell's original Merkle sum tree design can leak balance information through the sibling nodes in each user's proof. Newer implementations address this using zero-knowledge proofs (ZKPs). A ZK-based PoR system can prove that every leaf balance is non-negative and that the sum is correct without revealing any individual balances. This prevents an attacker from inferring other users' holdings by collecting multiple proofs.

Use Cases

Exchange Transparency

Centralized exchanges are the most common adopters of proof of reserves. After the FTX collapse revealed that customer funds had been misappropriated, exchanges including Binance, Kraken, Bitget, and OKX began publishing Merkle-tree-based reserve proofs. Frequencies range from real-time dashboards to monthly or quarterly reports, and some engage independent auditors such as Hacken or Armanino to verify the process.

Stablecoin Reserve Verification

Stablecoin issuers use a related form of reserve verification. Circle (USDC) publishes monthly attestations performed by Deloitte under AICPA attestation standards, covering its reserve portfolio of U.S. Treasury securities and cash deposits. Paxos uses examination-level attestations under AT-C 205 for its stablecoins. Tether (USDT) publishes quarterly attestations through BDO Italia.

These attestations differ from cryptographic PoR: they rely on a trusted accounting firm rather than user-verifiable Merkle proofs. The U.S. GENIUS Act of 2025 codified requirements for permitted payment stablecoin issuers to maintain 1:1 reserve backing in high-quality liquid assets and provide regular attestations.

Lending and Custody Platforms

Crypto custody providers and lending platforms also use PoR to demonstrate that customer assets have not been lent out or rehypothecated without disclosure. For lending platforms specifically, PoR can show the collateral backing outstanding loans remains in custody.

On-Chain Oracle Feeds

Chainlink Proof of Reserve feeds provide automated, on-chain verification of off-chain or cross-chain reserves. Smart contracts can query these feeds to confirm that a wrapped asset or stablecoin is fully backed before processing transactions. This enables programmatic verification rather than relying on periodic manual attestations.

Why It Matters

The history of cryptocurrency is marked by custodial failures where customer funds were misused. Mt. Gox lost 850,000 BTC. Celsius, Voyager, and BlockFi froze withdrawals in 2022 when their assets fell short of liabilities. FTX secretly transferred billions in customer deposits to its trading arm. In each case, customers had no way to verify that their funds were safe until it was too late.

Proof of reserves shifts the verification burden from trust to cryptographic proof. Rather than taking a custodian's word for it, users can independently check that their balance is accounted for. This creates accountability pressure: an exchange that publishes PoR and later fails to cover withdrawals would face immediate, provable evidence of fraud. For a deeper look at how stablecoin attestation practices are evolving, see the research article on stablecoin proof of reserves evolution.

For platforms in the Spark ecosystem, reserve transparency is equally important. Stablecoin issuers building on Bitcoin Layer 2 infrastructure need to demonstrate that tokens in circulation are fully backed, whether through traditional attestations or cryptographic proofs. The stablecoin reserve transparency audit research article explores how these verification standards apply across chains.

Risks and Limitations

Point-in-Time Snapshots

Most PoR implementations produce a snapshot at a single moment. An exchange could temporarily borrow assets to pass the attestation (a practice known as window dressing) and return them afterward. Between snapshots, there is no guarantee that reserves remain intact. Continuous or real-time attestation systems aim to close this gap, but they are not yet widely adopted.

Hidden Liabilities

A Merkle sum tree only covers the liabilities the custodian chooses to include. Off-chain debts, intercompany loans, pending obligations, fee rebates owed, or liabilities held through affiliate entities can be excluded from the tree entirely. An exchange could technically pass PoR while being deeply insolvent if significant liabilities are omitted.

Rehypothecation and Encumbrances

PoR shows that an address holds a certain balance, but it cannot reveal whether those assets are pledged as collateral, lent to a counterparty, or otherwise encumbered. An exchange could show 100,000 BTC in reserve while having pledged 80,000 BTC as collateral for a loan. The on-chain balance looks healthy, but the economic reality does not match.

No Negative Balance Detection (Basic Implementations)

In Maxwell's original Merkle sum tree, a malicious custodian could insert leaves with negative balances to reduce the apparent total liability while keeping the tree structure valid. Modern implementations using zero-knowledge proofs address this by proving every leaf is non-negative, but older or simpler implementations remain vulnerable.

Incomplete Asset Coverage

Some PoR reports cover only certain assets (for example, BTC and ETH) while the exchange also holds customer deposits in other cryptocurrencies or fiat. Partial coverage can create a misleading impression of full backing when significant liabilities in uncovered assets remain unverified.

No Substitute for Full Audit

A PoR attestation is not a full financial audit. It does not examine internal controls, revenue and expense flows, related-party transactions, or the custodian's broader financial health. Even when performed by an independent accounting firm, attestations operate under a narrower scope than a comprehensive audit. Users should treat PoR as one signal among many rather than a guarantee of safety.

Proof of Reserves vs. Proof of Solvency

Proof of reserves demonstrates that a custodian controls sufficient assets. But solvency requires proving both sides of the balance sheet: assets must exceed total liabilities. A complete proof of solvency pairs a reserve proof with a proof of liabilities, which demonstrates that the reported liability set is complete and accurate.

How to Verify a Proof of Reserves

When an exchange publishes a PoR report, users can verify it through several steps:

1. Log in to the exchange and locate the PoR verification page. The exchange provides your leaf data (hashed user ID and balance) and the Merkle proof path.
2. Use the exchange's open-source verification tool or a third-party verifier to reconstruct the path from your leaf to the published Merkle root. Confirm your balance matches.
3. Check the published reserve addresses on a block explorer. Verify the addresses were signed with a valid challenge message and that the total on-chain balance meets or exceeds the Merkle root's total liability.
4. Review the attestation report for scope: which assets and liabilities are covered, whether an independent auditor was involved, and when the snapshot was taken.

# Example: verifying a Merkle proof (pseudocode)
leaf_hash = sha256(user_id_hash || balance)
current = leaf_hash

for sibling, direction in proof_path:
    if direction == "left":
        current = sha256(sibling || current)
    else:
        current = sha256(current || sibling)

assert current == published_merkle_root

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.