Proof of Liability

What Is Proof of Liability?

Proof of liability (PoL) is a cryptographic method that allows a custodial institution to prove the total value of its obligations to depositors. Where a proof of reserves answers "what assets does this institution hold?", proof of liability answers the complementary question: "what does this institution owe?"

The concept was first proposed by Greg Maxwell in 2013, using a summation Merkle tree where each leaf stores a user's balance and each internal node stores the combined sum of its children. The root of the tree commits to the exact total of all liabilities. Individual users can verify their own balance is included without seeing anyone else's data.

Without proof of liability, a crypto exchange could publish a proof of reserves showing 100,000 BTC in its wallets while actually owing 150,000 BTC to depositors. The proof of reserves alone would look perfectly healthy, masking a 50,000 BTC shortfall. This is precisely the scenario that played out with FTX in November 2022, where an approximately $8 billion gap existed between claimed and actual reserves.

How It Works

The core mechanism behind proof of liability is the Merkle sum tree: a variant of a standard Merkle tree where each node stores both a cryptographic hash and a numeric sum. Building and verifying a proof of liability involves several steps:

1. The institution assigns each user account as a leaf node containing the user's balance and a hash of their account identifier
2. Each internal node computes its value as the sum of its two children's balances, and its hash as the hash of its children's hashes and values combined
3. The root node contains the total liability (sum of all user balances) and a root hash that commits to the entire tree
4. The institution publishes the root hash and total liability
5. Each user receives a Merkle proof: a path from their leaf to the root, allowing them to verify their balance is included in the total

Merkle Sum Tree Structure

A simplified representation of how a Merkle sum tree aggregates user balances into a verifiable total:

                Root
          hash: H(AB || CD)
          sum: 25 BTC
            /            \
        Node AB          Node CD
    hash: H(A||B)    hash: H(C||D)
      sum: 15 BTC      sum: 10 BTC
       /      \          /      \
    Leaf A   Leaf B   Leaf C   Leaf D
    8 BTC    7 BTC    4 BTC    6 BTC
   (Alice)  (Bob)   (Carol)  (Dave)

Each user can verify their inclusion by checking their leaf value, then verifying that each parent node correctly sums its children up to the published root. If the institution excludes any user or understates any balance, the root sum will not match the claimed total.

Preventing Negative Balance Attacks

A naive Merkle sum tree has a critical vulnerability: the institution could insert fake accounts with negative balances to artificially reduce the reported total liability. For example, inserting a fake leaf with -50 BTC would reduce the apparent total by 50 BTC, making the institution look more solvent than it is.

To prevent this, modern implementations attach zero-knowledge range proofs (such as Bulletproofs) to each leaf, proving that every balance is non-negative without revealing the actual amount. This ensures the total liability can only reflect genuine positive balances.

Advanced Approaches

The Provisions protocol, published by Dagher, Bünz, Bonneau, Clark, and Boneh at ACM CCS 2015, extended Maxwell's original design using Pedersen commitments and zero-knowledge proofs. Provisions proves solvency without revealing Bitcoin addresses, total holdings, total liabilities, or individual customer data.

More recently, implementations have adopted zk-SNARKs and zk-STARKs for proof of liability. In November 2022, Vitalik Buterin published a detailed proposal for using zk-SNARKs to build efficient, privacy-preserving proof-of-solvency systems for centralized exchanges. This approach compresses the verification process, allowing users to check proofs without downloading the full tree.

Use Cases

Exchange Solvency Verification

The primary use case for proof of liability is allowing crypto exchange users to verify that the platform is not operating on a fractional reserve basis. When combined with proof of reserves, users gain verifiable evidence that the exchange holds sufficient assets to honor all withdrawals. Several major exchanges adopted these systems after FTX's collapse: Binance implemented zk-SNARK verification atop Merkle sum trees, OKX adopted zk-STARKs, and BitMEX open-sourced its complete proof-of-reserves-and-liabilities implementation on GitHub, publishing proofs twice weekly.

Stablecoin Transparency

Stablecoin attestations typically focus on the reserves side: proving that a stablecoin issuer holds sufficient backing assets. Proof of liability extends this by verifying the total tokens in circulation that the issuer is obligated to redeem. For a deeper analysis of how these attestation standards have evolved, see Stablecoin Proof of Reserves Evolution.

Custodial Services

Any service that holds user funds faces custodial risk: the possibility that the custodian mismanages, loses, or misappropriates deposited assets. Proof of liability provides a cryptographic check against this risk. Lending platforms, Bitcoin banks, and institutional custody providers can use the technique to demonstrate they are not lending out more than they disclose.

Why It Matters

The FTX collapse in November 2022 revealed that billions of dollars in customer deposits had been diverted to the affiliated trading firm Alameda Research. The exchange appeared healthy by superficial metrics, but its actual liabilities far exceeded its assets. This event triggered an industry-wide push for cryptographic proof-of-solvency standards.

The regulatory response has been significant. The GENIUS Act (signed July 2025) established reserve backing and transparency requirements for stablecoin issuers in the United States. The EU's MiCA regulation mandates continuous proof-of-reserve requirements. The AICPA developed criteria for stablecoin proof-of-reserves reporting in 2025. However, no unified proof-of-liability standard exists yet.

For self-custodial systems, proof of liability is less relevant because users hold their own keys and do not depend on a custodian's solvency. Platforms like Spark, which enable self-custody of Bitcoin and stablecoins, reduce counterparty risk by design: if users control their own assets, there is no custodial liability to prove.

Risks and Considerations

Off-Chain Liabilities

The most significant limitation of proof of liability is that it only captures on-chain, recorded obligations. An exchange may owe funds through off-chain mechanisms that never appear in the Merkle sum tree: outstanding loans from institutional lenders, derivatives positions with counterparties, fiat currency obligations, legal claims and settlements, and inter-company transfers to affiliates. A 2026 analysis found that major exchanges still prove assets without fully proving solvency, missing collateral claims, corporate obligations, and lending products.

Point-in-Time Snapshots

Proof of liability captures the state at a single moment. An institution could temporarily restructure its balance sheet for the snapshot: borrowing assets to inflate reserves, settling short-term liabilities before the proof, then resuming risky operations afterward. Without continuous or randomized auditing, point-in-time proofs can be misleading.

Privacy Tradeoffs

Maxwell's original Merkle sum tree design leaks information: users can infer the balances of neighboring accounts in the tree by subtracting known values from parent sums. BitMEX addressed this by splitting user balances into random chunks and shuffling leaves before tree construction. More advanced approaches using zero-knowledge proofs solve the privacy problem at the cost of increased computational complexity.

Collusion Vulnerabilities

If two exchanges collude, they can cover each other's shortfalls: Exchange A temporarily lends assets to Exchange B before B's proof-of-reserves snapshot, then Exchange B returns the favor. The Provisions protocol proposed anti-collusion extensions, and a 2026 paper published at ACM AsiaCCS specifically addressed mitigating collusion in proof-of-liability protocols. Research in this area remains active, with the Summa protocol (by Privacy & Scaling Explorations) iterating through multiple versions using increasingly sophisticated cryptographic techniques.

User Participation Requirements

For proof of liability to be effective, a sufficient number of users must actually verify their inclusion in the Merkle sum tree. If only a small fraction of users check their proofs, the institution could omit accounts belonging to non-verifying users without detection. This creates a collective action problem: the system works best when most users participate, but individual verification requires technical effort.

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.