Case Study 2: Proof of Reserves — Does Transparency After FTX Actually Work?

The Promise

Within weeks of FTX's collapse, the phrase "proof of reserves" became the crypto industry's rallying cry. If the fundamental problem was that exchanges could secretly misuse customer funds, then the solution — the industry argued — was to prove, cryptographically, that an exchange held assets sufficient to cover all customer deposits.

The concept was straightforward: use the same cryptographic tools that underpin blockchain technology (hash functions, Merkle trees, digital signatures) to allow users to independently verify that an exchange holds what it claims to hold. No more trust. No more opacity. No more FTX.

Binance, the world's largest exchange, published its first proof-of-reserves report in November 2022 — days after FTX's collapse. OKX, Crypto.com, Kraken, BitMEX, and other major exchanges followed. Some used proprietary systems. Others adopted third-party audit firms. A few implemented Merkle tree-based systems that allowed individual users to verify their account's inclusion.

The industry presented proof of reserves as the definitive answer to the trust problem. But the reality, as with most things in crypto, is more complicated. Proof of reserves, as currently implemented, solves some problems, fails to solve others, and introduces new problems of its own.

How Proof of Reserves Works

The Basic Mechanism

A proof-of-reserves system typically involves three components:

1. Asset verification (proof of assets). The exchange identifies the on-chain addresses holding its reserves and proves it controls those addresses — usually by signing a message with the private keys associated with those addresses. Anyone can then look at the blockchain and verify the balances at those addresses.

2. Liability verification (proof of liabilities). The exchange constructs a Merkle tree in which each leaf represents a customer account (containing a hash of the customer's identifier and their balance). The root of the Merkle tree is published. Individual customers can request a "Merkle proof" — a set of intermediate hashes — that demonstrates their specific balance is included in the tree.

3. Comparison. If the total assets (verified on-chain) equal or exceed the total liabilities (the sum of all balances in the Merkle tree, which equals the value that the Merkle root commits to), then the exchange has "proven" it holds sufficient reserves.

A Concrete Example

Suppose an exchange has four customers:

Customer Balance
Alice 5 BTC
Bob 3 BTC
Carol 7 BTC
Dave 2 BTC

The exchange constructs a Merkle tree:

        Root Hash
       /         \
    H(AB)       H(CD)
   /     \     /     \
H(A)   H(B) H(C)   H(D)

Each leaf is a hash of the customer's identifier and balance: H(A) = hash("Alice" || "5 BTC"), etc. The exchange publishes the root hash and the total claimed liabilities (17 BTC). It also publishes the Bitcoin address(es) holding its reserves and signs a message proving it controls those addresses.

Alice can verify her inclusion by requesting a Merkle proof from the exchange. The proof consists of H(B) and H(CD) — the sibling hashes she needs to recompute the root. She computes:

  1. H(A) = hash("Alice" || "5 BTC") — she knows her own data
  2. H(AB) = hash(H(A) || H(B)) — using the sibling hash H(B) provided by the exchange
  3. Root = hash(H(AB) || H(CD)) — using the sibling hash H(CD) provided by the exchange

If her computed root matches the published root, she has cryptographic assurance that her 5 BTC balance is included in the exchange's claimed liabilities. She can independently check the on-chain addresses to verify that the exchange holds at least 17 BTC.

Improvements: Sumtree and Liability Proofs

The basic Merkle tree approach has been refined. A Merkle sum tree (sometimes called a "sumtree") extends the standard Merkle tree by including balance totals at each internal node. This allows the total liabilities to be computed directly from the tree structure, rather than relying on the exchange's separate claim. It also allows each user to verify not only their own inclusion but that the subtree balances sum correctly — making it harder for the exchange to under-report total liabilities.

More advanced approaches use zero-knowledge proofs to allow verification without revealing individual account balances to anyone except the account holder. This addresses a significant privacy concern with the basic approach (anyone with a Merkle proof can learn the balances of sibling accounts in certain tree structures).

What Proof of Reserves Proves

When properly implemented, proof of reserves demonstrates the following:

1. The exchange controls specific on-chain assets at a point in time. The signed message proves key control; the blockchain shows the balance. This is verifiable by anyone.

2. A specific user's balance is included in the claimed liabilities. The Merkle proof provides this assurance to individual users.

3. The total claimed assets meet or exceed total claimed liabilities. If the on-chain balances are greater than or equal to the Merkle tree's total, the exchange is (at that instant, for those specific assets) fully reserved.

These are meaningful guarantees. In a world where Mt. Gox and FTX operated with no reserve verification whatsoever, even a snapshot proof is a substantial improvement.

What Proof of Reserves Does NOT Prove

This is where the analysis becomes critical. The limitations of proof of reserves are significant, and understanding them is essential for evaluating whether the post-FTX transparency movement actually addresses the root causes of the failures described in this chapter.

Limitation 1: Point-in-Time Only

A proof of reserves is a snapshot. It shows that the exchange held sufficient reserves at the moment the proof was generated. It says nothing about what happened five minutes before or five minutes after.

An exchange could borrow assets for the snapshot — obtaining a short-term loan from another exchange, a market maker, or an OTC desk — and return them immediately afterward. This is not a hypothetical risk; it is the most frequently cited criticism of snapshot-based proofs. Some exchanges attempt to mitigate this by publishing proofs at unannounced times or with increased frequency (weekly rather than monthly), but the fundamental limitation remains: a snapshot is not a continuous guarantee.

Limitation 2: Hidden Liabilities

A proof of reserves shows on-chain assets and Merkle-verified customer liabilities. But an exchange's total liabilities include far more than customer deposits:

  • Loans: The exchange may have borrowed money from lenders, banks, or counterparties. These liabilities are not in the Merkle tree.
  • Legal obligations: Pending lawsuits, regulatory fines, or contractual commitments are liabilities that do not appear in a Merkle tree of customer balances.
  • Operational costs: Rent, salaries, vendor contracts, and other ongoing expenses are claims on the exchange's assets.
  • Off-chain obligations: The exchange may have obligations denominated in fiat currency or other off-chain assets that are invisible to on-chain verification.

FTX's core fraud was not simply that it had fewer on-chain assets than customer deposits — it was that it had lent customer deposits to Alameda Research. A proof-of-reserves system would have shown that FTX's on-chain wallets were depleted. But a clever fraudster could structure the depletion to look like normal operational activity, and the proof of reserves would not reveal where the assets had gone.

Limitation 3: No Encumbrance Check

Even if the exchange's on-chain wallets hold sufficient assets, those assets may be encumbered — pledged as collateral for loans, committed to other obligations, or otherwise not freely available to satisfy customer claims. A proof of reserves shows that the exchange controls certain addresses. It does not show whether the assets at those addresses are free and clear.

In traditional finance, this is the problem that asset segregation requirements, custodial audits, and regulatory capital rules are designed to address. A bank cannot count a loan it has made as an "asset" in the same way it counts cash — regulatory frameworks distinguish between liquid, unencumbered assets and those committed to other purposes. Proof of reserves, in its current form, does not make this distinction.

Limitation 4: Exclusion Attacks

A dishonest exchange could construct the Merkle tree while deliberately excluding certain accounts. If Alice checks her Merkle proof and it verifies, she knows she is included. But she has no way to verify that Bob is included — unless Bob checks independently. If the exchange excludes accounts that belong to users unlikely to check (dormant accounts, large institutional accounts whose operators trust the exchange), the total reported liabilities will be understated, and the proof will show a healthier picture than reality warrants.

This is a fundamental limitation of individual verification: each user can only verify themselves. The aggregate integrity of the proof depends on a sufficient number of users actually checking. If most users do not check (and in practice, most users do not), the exchange has latitude to under-report liabilities.

Limitation 5: Multi-Asset Complexity

Crypto exchanges hold dozens or hundreds of different assets: Bitcoin, Ethereum, USDT, USDC, SOL, and many more. A proof that an exchange holds 100,000 BTC does not help if the exchange also owes customers 500,000 ETH and has no Ethereum reserves. Comprehensive proof of reserves must cover every asset the exchange holds, and the verification must ensure that each asset's reserves match that asset's liabilities — not just in aggregate but for each specific asset.

Some proof-of-reserves implementations have been criticized for proving reserves in a single asset (usually Bitcoin, which is the easiest to verify on-chain) while ignoring others. A partial proof is worse than useless if it creates a false sense of security about the exchange's overall solvency.

The Industry Response

Binance

Binance was the first major exchange to publish a proof of reserves after FTX's collapse, releasing a report in November 2022. The initial report was criticized on multiple grounds: it was a snapshot, it covered only Bitcoin holdings, and it was performed by the accounting firm Mazars — which subsequently withdrew from crypto-related work, citing concerns about how its reports were being interpreted by the public. Binance later expanded its proof of reserves to cover multiple assets and engaged other verification providers.

Kraken

Kraken implemented a Merkle tree-based proof of reserves and engaged independent auditing firms to verify the process. Kraken's approach was considered among the more rigorous in the industry, covering multiple assets and publishing attestations with greater frequency. However, Kraken's proof was still a point-in-time attestation, subject to the snapshot limitation.

Industry Standardization Efforts

Several projects attempted to standardize proof-of-reserves approaches. Chainlink, the oracle network, launched a "Proof of Reserve" product that provides automated, on-chain verification of asset backing — initially focused on wrapped tokens and stablecoins rather than exchange reserves. Nic Carter and other researchers proposed standards for Merkle tree-based proofs that addressed some of the privacy and exclusion concerns.

The most significant development was the push for regulatory integration — proof of reserves not as a voluntary industry practice but as a regulatory requirement. Several jurisdictions, including the EU under MiCA and certain U.S. state-level regulators, began incorporating reserve transparency requirements into exchange licensing frameworks.

The Gap Between Proof of Reserves and Proof of Solvency

The fundamental problem with proof of reserves is that reserves are not solvency. An exchange can have 100% reserves — on-chain assets matching customer liabilities exactly — and still be insolvent if it has off-chain debts, legal liabilities, or operational losses that its reserves cannot cover.

True proof of solvency would require:

  1. A complete accounting of all liabilities — not just customer deposits, but all debts, obligations, and contingent liabilities.
  2. A complete accounting of all assets — not just on-chain crypto, but fiat bank balances, receivables, investments, and other holdings.
  3. Independent verification by a qualified auditor with access to all financial records, bank statements, and counterparty confirmations.
  4. Continuous or near-continuous monitoring, not just point-in-time snapshots.

This is, of course, a description of a traditional financial audit combined with ongoing regulatory supervision — exactly the system that traditional finance uses and that the crypto industry has been reluctant to adopt.

💡 Key Insight: There is an irony here. The crypto industry's response to FTX — proof of reserves — uses cryptographic tools to provide partial, point-in-time transparency. The traditional finance response to equivalent frauds — mandatory audits, regulatory capital requirements, and continuous supervision — provides more comprehensive, ongoing assurance. The two approaches are not mutually exclusive. The optimal system would combine cryptographic verification of on-chain reserves with traditional audit verification of off-chain liabilities. Some exchanges are moving in this direction, but the industry is far from universal adoption.

The Broader Question: Can Technology Replace Trust?

The proof-of-reserves debate touches the deepest question in blockchain: can technology replace trust?

The maximalist answer is yes — given sufficient technological sophistication, you can build systems where trust in humans is unnecessary. Self-custody, decentralized exchanges, and on-chain lending protocols are examples of this philosophy in action. If you hold your own keys and trade on Uniswap, you do not need to trust any exchange, and proof of reserves is irrelevant.

But most crypto users — especially new users, institutional investors, and anyone who needs fiat on-ramps — interact with centralized exchanges. For these users, some degree of trust is unavoidable. Proof of reserves is an attempt to minimize that trust by replacing opacity with cryptographic verification. It is a partial solution — better than nothing, worse than comprehensive auditing, and insufficient by itself to prevent the kinds of fraud this chapter has examined.

The honest assessment is that proof of reserves is a necessary component of exchange transparency, but it is not sufficient. It must be combined with:

  • Regular, independent audits by qualified accounting firms (not metaverse-based startups).
  • Asset segregation requirements that legally separate customer funds from the exchange's operating capital.
  • Capital adequacy standards that require exchanges to maintain buffers above their liabilities.
  • Regulatory oversight that includes the power to examine books, inspect operations, and shut down non-compliant entities.
  • User education that helps customers understand what proof of reserves does and does not prove.

Discussion Questions

  1. The verification paradox. Proof of reserves works best when most users check their Merkle proofs. But in practice, the vast majority of users never check. How could the industry increase verification rates? Should exchanges be required to provide automated verification tools in their apps? Should third-party monitoring services check on behalf of users?

  2. The traditional finance comparison. Traditional banking does not use proof of reserves — it uses FDIC insurance, regulatory capital requirements, and periodic audits. Is the crypto industry's proof-of-reserves approach more or less trustworthy than the traditional banking model? What are the trade-offs?

  3. The privacy tension. Comprehensive proof of reserves requires disclosing wallet addresses, which can be linked to transaction histories. This conflicts with the privacy goals of many crypto users. How should this tension be resolved? Can zero-knowledge proofs address it adequately?

  4. The self-custody alternative. The most secure "proof of reserves" is self-custody — holding your own keys and never depositing assets on an exchange. If self-custody is the safer alternative, should regulators encourage or require exchanges to promote self-custody? What are the practical barriers to mass adoption of self-custody?

  5. The audit question. Several traditional accounting firms (including some Big Four firms) initially entered the crypto auditing space and then withdrew after FTX's collapse, citing reputational risk. What would it take to bring reputable auditors back to crypto? Should auditing standards be modified for crypto-native businesses, or should crypto businesses be required to meet the same standards as traditional financial institutions?

  6. Design exercise. Propose a "proof of reserves v2.0" system that addresses at least three of the five limitations identified in this case study. For each limitation you address, describe the mechanism, the trade-offs, and any new problems your solution introduces. Be specific about what remains unresolved.