Proof of Solvency

What Is Proof of Solvency?

Proof of solvency is a cryptographic protocol that allows a cryptocurrency exchange or custodian to demonstrate that it holds enough assets to cover all customer deposits. Unlike a simple balance check, a proper solvency proof requires showing both sides of the ledger: the assets under the institution's control and the total liabilities owed to its users.

The concept traces back to a 2014 proposal by Bitcoin Core developer Greg Maxwell, who described a Merkle tree-based scheme for proving exchange liabilities. Kraken became one of the first exchanges to implement this approach in early 2014. The idea gained urgent relevance after the collapse of FTX in November 2022, when it was revealed that the exchange had been insolvent for months while publicly claiming otherwise. Vitalik Buterin subsequently published a detailed proposal for improving solvency proofs using zero-knowledge cryptography.

A proof of solvency is not a full financial audit. It is a narrowly scoped cryptographic claim: at a specific moment in time, the proven on-chain assets met or exceeded the committed customer liabilities. Understanding what it proves and what it does not is critical for evaluating exchange transparency.

How It Works

A complete proof of solvency has two halves, each addressing one side of the balance sheet. Both must be verified for the proof to be meaningful.

Proof of Reserves (Asset Side)

The exchange proves it controls on-chain wallets holding a specific quantity of assets. The standard technique is cryptographic signing: the exchange signs a challenge message using the private keys associated with its known wallet addresses. Anyone can verify the signature against the public address and check the balance on a block explorer.

For a proof of reserves to be credible, the exchange must prove control of all significant wallets, not just a curated subset. Some exchanges publish signed attestations for every supported asset, while others cover only major holdings like BTC, ETH, and USDT.

Proof of Liabilities (Liability Side)

Proving liabilities is the harder half, and the part that weak implementations often skip. The exchange must commit to the total amount it owes to all customers without exposing individual account balances.

The standard approach uses a Merkle sum tree. Each leaf node represents a customer's account with a hashed identifier and their balance. Parent nodes contain the sum of their children's balances plus a hash linking them. The root node holds the aggregate liability total.

Merkle Sum Tree Structure:

         Root: hash(A|B), balance=1000
          /                     \
    Node A: hash(C|D),       Node B: hash(E|F),
    balance=600              balance=400
      /        \               /        \
  Leaf C:   Leaf D:       Leaf E:   Leaf F:
  user_1    user_2        user_3    user_4
  bal=350   bal=250       bal=150   bal=250

Any customer can request a Merkle proof: the branch of hashes from their leaf to the root. They verify that their balance appears correctly in the tree and that the sums add up along the path. If every customer checks their own proof, collective verification ensures the total liability figure is accurate.

The Solvency Check

With both halves in place, the solvency check is straightforward: if the total proven reserves equal or exceed the total committed liabilities (the Merkle root balance), the exchange passes. The attestation can be expressed as:

Solvency condition:
  Total Proven Reserves >= Merkle Root Liability Total

Example:
  Reserves: 10,250 BTC (verified via signed wallet proofs)
  Liabilities: 10,100 BTC (Merkle sum tree root)
  Reserve ratio: 101.5% — exchange is solvent for this asset

Zero-Knowledge Enhancements

Plain Merkle sum trees leak information. Each user who verifies their proof sees sibling hashes and partial balance sums along their branch. With enough colluding verifiers, it becomes possible to reconstruct large portions of the liability distribution.

Modern implementations wrap the Merkle sum tree inside a zero-knowledge proof (typically a zk-SNARK) that proves:

• The tree was constructed correctly from valid leaf data
• No leaf contains a negative balance (preventing hidden liabilities)
• The root balance equals the sum of all leaves
• A specific user's balance is included in the tree

The zero-knowledge property ensures that none of the above reveals any other user's balance or the overall distribution of funds. Binance's implementation, for instance, uses zk-SNARKs for its monthly proof-of-reserves reports.

Who Publishes Solvency Reports?

Following the FTX collapse, most major exchanges began publishing regular proof-of-reserves reports. However, the rigor and scope vary significantly. As of 2026, industry trackers monitor approximately $192 billion in exchange proof-of-reserves assets.

You can track live reserve ratios across major exchanges using the Crypto Exchange Proof of Reserves Tracker.

Self-Reported vs. Independently Verified

A critical distinction exists between self-reported attestations and independently verified proofs. In a self-reported model, the exchange generates and publishes its own proofs. Users must trust that the exchange did not manipulate the Merkle tree or selectively prove wallets. Independent verification by a third-party auditor adds accountability, but even these reports are limited in scope compared to a traditional financial audit.

The U.S. Public Company Accounting Oversight Board (PCAOB) has warned investors that proof-of-reserves reports "verify assets only for a specific moment and are subject to significant limitations based on the procedures performed." They are not equivalent to a full audit opinion on an exchange's financial health.

Use Cases

Exchange Transparency

The primary use case is demonstrating that a centralized exchange has not lent out, lost, or misappropriated customer funds. Regular solvency reports build user confidence and differentiate transparent platforms from opaque ones.

Stablecoin Reserve Verification

Stablecoin issuers use similar attestation frameworks to prove that circulating tokens are backed by real reserves. The evolution of stablecoin proof-of-reserves has driven innovations in attestation standards and real-time verification. The GENIUS Act, signed into U.S. law in July 2025, requires permitted stablecoin issuers to publish monthly reserve reports examined by registered public accounting firms.

Institutional Due Diligence

Institutional investors and fund managers increasingly require proof-of-reserves data as part of their due diligence process before depositing assets on an exchange. A strong solvency track record can be a competitive advantage for custodians seeking institutional clients.

Risks and Limitations

Point-in-Time Snapshots

Solvency proofs capture a single moment. An exchange can borrow assets shortly before a scheduled attestation to appear fully backed, then resume risky activity afterward. This "window dressing" attack is well documented and represents a fundamental weakness of periodic proofs. Even monthly reporting does not transform point-in-time evidence into continuous proof, as snapshots cannot show the reserve relationship held between publication dates.

Incomplete Liability Coverage

Most proof-of-reserves reports cover only customer crypto balances. They exclude:

• Corporate borrowing and outstanding loans
• Vendor obligations and operational debts
• Derivatives exposures and margin positions
• Pending litigation or regulatory fines
• Off-chain liabilities to counterparties

An exchange could show full backing for customer crypto while being deeply insolvent due to hidden off-chain obligations. This is precisely what happened with FTX, where customer deposits were used to cover losses at the affiliated trading firm Alameda Research.

Security of the Merkle Construction

A 2018 academic paper by Hu, Zhang, and Guo demonstrated that the original Maxwell Merkle sum tree protocol contains vulnerabilities that could allow an exchange to understate its proven liabilities. Modern implementations using zk-SNARKs or zk-STARKs address these weaknesses by enforcing correct tree construction within the proof circuit, but the cryptographic complexity increases the barrier to independent review.

No Guarantee Against Future Insolvency

A passing solvency proof today does not guarantee solvency tomorrow. Exchanges can become insolvent between reports through trading losses, hacks, or mismanagement. Without continuous or randomized auditing, solvency proofs provide a false sense of security if users treat them as ongoing guarantees rather than periodic checkpoints.

Why Self-Custody Eliminates the Problem

Proof of solvency exists because custodial risk exists. When users deposit funds with a third party, they need assurance that their assets are safe. But the fundamental question: "does this entity have my money?" only arises because users gave up control in the first place.

Self-custodial protocols like Spark remove this trust requirement entirely. When users hold their own keys, there is no counterparty whose solvency needs proving. The assets are verifiably under the user's control at all times, secured by cryptography rather than attestations.

This is the core argument for self-custody in the post-FTX era: the most robust proof of solvency is not needing one at all.

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.