What is proof of liabilities?

The half of a solvency claim that shows what a custodian owes customers, without which a proof of reserves shows only that an entity controls some assets.

Credible implementations commit every customer balance into a cryptographic tree, publish the root, and give each customer a way to verify their own balance is included, so the platform cannot omit accounts to look solvent. Most published reserve reports do not include a verifiable liabilities side.

Solvency is a comparison, not a quantity. Showing $2,000,000,000 of assets means nothing until you know whether the platform owes $1,000,000,000 or $4,000,000,000. Reserve reports get published far more often than liability proofs because the asset side is easy to demonstrate and the liability side requires the platform to commit to a number it cannot quietly revise.

How it works

The standard construction uses a merkle tree.

1. Every customer account is turned into a leaf containing the balance and a per-user salt, so one customer cannot learn another's holdings from the published data.
2. Leaves are hashed together in pairs, repeatedly, until a single root hash remains. The root commits to the entire set: change any balance or drop any account, and the root changes.
3. The platform publishes the root and the total liability it represents.
4. Each customer is given the small set of sibling hashes needed to recompute the root from their own leaf. If it matches the published root, their balance was included in the total.

An attestation by an auditor can then compare that committed liability figure against verified control of on-chain assets. See proof of reserves.

The construction has known limits. It proves inclusion, not exclusion of fabricated negative balances unless the scheme is designed to prevent them, it is a snapshot rather than a continuous state, and it says nothing about off-chain debts, loans, or obligations that never appear as customer balances.

Example

Illustratively, a platform publishes a root committing to $2,000,000,000 of customer liabilities and an attestation showing control of $2,100,000,000 of on-chain assets at the same moment. You are told your $5,000 balance is leaf number 40,318 and are given twenty sibling hashes.

You hash your balance and salt, combine it with each sibling in order, and arrive at a root. If it equals the published one, your $5,000 was counted in the $2,000,000,000. If the platform had excluded your account to make the totals look better, your recomputed root would not match, and any excluded customer checking would notice.

Only a fraction of customers ever check, which is enough: the platform cannot know in advance who will.

Why it matters when you buy

If you leave a balance on an exchange, this is the difference between a claim of solvency and evidence of it. Ask whether the venue publishes a liabilities commitment you can verify against your own balance, not just a wallet address list. The proof of reserves guide explains what each report does and does not cover, and the exchange directory records what each venue publishes.

Related terms

proof of reserves — the asset half of the claim; merkle tree — the commitment structure used; attestation — the auditor's limited statement; custodian — who holds the assets; rehypothecation — obligations that never show as balances; segregated accounts — how client assets are meant to be held.

Questions

Why do so few exchanges publish this?

Committing to a liability figure is a harder promise than showing wallet control, and it constrains what the platform can say later. It also requires per-customer verification tooling that must be maintained.

Does verifying my own balance prove the exchange is solvent?

No. It proves your balance was included in the total the platform committed to. Solvency also depends on that total being complete, the assets being real and unencumbered, and there being no off-balance-sheet debts.

How current is a proof like this?

It is a snapshot at a single moment. Assets can move the next day, so frequency and independent verification of the asset side matter as much as the construction itself.