Proof of reserves and proof of liabilities: how a crypto exchange proves what it owes
Proof of liabilities puts every customer balance in a Merkle sum tree with one published root and total; proof of reserves shows the assets held against it. Each half proves less than it seems.
A crypto exchange proves what it owes by publishing proof of liabilities: every customer balance goes into a Merkle sum tree, the exchange publishes the tree's root and total, and each customer can check that their own balance is counted in it. Proof of reserves is the other half, showing the wallets and accounts that hold assets against that total. Together they show, at one moment, that what is held covers what is owed, and each half on its own proves less than it seems.
Why customers and regulators ask
A balance on an exchange is not coins in the customer's own wallet. It is a claim on the exchange, a line in its books, and the coins behind it sit in wallets the exchange controls or with a custodian it appoints. When an exchange fails, the gap between those lines and those coins is what customers lose.
So customers ask for evidence, and the law asks for the controls behind it. In the EU, the Markets in Crypto-Assets Regulation (MiCA) requires a provider holding clients' crypto-assets to make "adequate arrangements to safeguard the ownership rights of clients" and to prevent their use for its own account (Article 70). A provider offering custody keeps a register of positions in each client's name, sends each client a statement of position at least once every three months and on request, and segregates clients' holdings from its own, on the distributed ledger too (Article 75). This is general information, not legal advice.
Those statements are private, one per customer. Proof of reserves and proof of liabilities go further: anyone can check the published figures, and each customer can check their own place in them.
Two halves: what is owed and what is held
Proof of liabilities | Proof of reserves | |
|---|---|---|
The question | How much does the exchange owe its customers? | How much does the exchange hold? |
The evidence | A Merkle sum tree of every customer balance, with a published root and total | Wallet balances on chain, signed messages, custodian and bank confirmations |
Who can check | Each customer, for their own balance | Anyone, for on-chain wallets |
What it is measured in | Each asset on its own | The same assets, at the same moment |
The comparison is made per asset. A surplus of ether does not cover a shortfall of bitcoin that customers are owed.
Proof of liabilities: a Merkle sum tree
The exchange takes a snapshot of its ledger at one moment and builds a tree from it, one asset at a time.
Leaves. Each customer's balance becomes a leaf. The leaf's hash is made from the balance, an identifier for the customer and a salt: a random value that only that customer is given. The balance is carried beside the hash.
Nodes. Leaves are paired. Each node's hash is made from both children's hashes and sums, and the node's sum is the two sums added.
The root. Pairing continues until one node is left. Its hash and its sum, the total owed to customers in that asset, are published.
The salt is what keeps the tree private. Without it, anyone could hash a guessed identifier and balance and see whether it appears. With it, a leaf reveals nothing to someone who does not hold the salt, and a careful design also shuffles the leaves and adds empty ones, so the tree's shape gives little away.
A worked example with four customers
With illustrative numbers, four customers hold bitcoin on an exchange.
Customer A holds 1.50 BTC, customer B 0.50, customer C 2.00 and customer D 1.00.
Leaves A and B pair into a node with a sum of 2.00. Leaves C and D pair into a node with a sum of 3.00.
The root's sum is 5.00 BTC. The exchange publishes the root's hash and that total.
Every hash depends on everything beneath it. Change one balance, drop one leaf or move a customer to another branch, and the root's hash changes.
How a customer checks their own entry
Each customer receives their own leaf data and a path: the hashes and sums of the nodes beside their own, one per level of the tree. For customer B, that is leaf A (1.50) and the node holding C and D (3.00).
Rebuild the leaf. B's balance, identifier and salt give leaf hash 5d42… with 0.50.
Climb one level. With leaf A's hash and 1.50, B computes the node above: hash 7c58…, sum 2.00.
Climb to the root. With the C and D node's hash and 3.00, B computes the root: hash f0be…, sum 5.00.
Compare. If the result matches the published root, B's 0.50 is counted in the 5.00.
The check usually runs on a public verifier page, or in an open-source tool the customer runs themselves, so they do not have to trust the exchange's own arithmetic. B learns two partial sums, but not who holds them or what any other single customer holds.
Two weaknesses need a design answer. A negative balance hidden in a leaf would shrink the total, so a sound tree and verifier reject any sum below zero, and stronger schemes add cryptographic proofs that every leaf is non-negative. And a customer left out of the tree only finds out if they check, so the exchange cannot know who will look: the more customers check, the harder it is to leave anyone out unnoticed.
Proof of reserves: showing the assets
The other half shows what the exchange holds at the same snapshot. The evidence depends on where the assets sit.
On-chain wallets. Anyone can read an address's balance on the blockchain at a given block. To show the exchange controls the address, it signs a message with that address's key, using a standard such as BIP-322 for Bitcoin, which defines signed messages "for proving availability of funds", or the EIP-191 signed-data format on Ethereum.
Assets with a custodian. Where coins sit with a licensed custodian, as the guide to hot wallets, cold wallets and custodians explains, the evidence is the custodian's own attestation of what it holds for the exchange.
Fiat. Euros owed to customers are shown by confirmations from the banks where they are held.
In the example, wallet 1 holds 3.20 BTC and wallet 2 holds 2.00 BTC, each with a signed message. The reserves are 5.20 BTC against 5.00 BTC owed: covered, at 104%, at that moment.
What each half proves, and what neither proves
Proof of liabilities proves that a customer who checks is counted in the published total. It does not prove that every account is in the tree; only customers who check can catch a gap.
Proof of reserves proves that someone could sign for those addresses and that they held a balance at the snapshot. BIP-322 itself is plain about the limit: no message signing protocol "can actually prove control of funds", because a signature is out of date as soon as it is made and a key holder may sign on someone else's behalf. Coins can be borrowed for the day, pledged elsewhere or moved the next morning.
Neither half sees:
Debts kept off the ledger. A loan to the exchange, or any creditor who is not a customer, appears in neither tree nor wallets, yet ranks against the same assets.
Anything after the snapshot. Both halves describe one moment. They are a snapshot, not a guarantee.
The full test of solvency is all assets against all liabilities, and that is what audited accounts address. Proof of reserves and proof of liabilities answer a narrower, still useful question: at this moment, were customers' balances covered?
How often it runs
The value of a snapshot falls with the time since it was taken. A statement published once a quarter leaves a long window in which assets could leave and come back; a daily one leaves very little room. Frequent runs also make window dressing, such as borrowing coins for the snapshot, costly to keep up.
The liabilities half is cheap to repeat once it is automated, because the balances already sit in the exchange's double-entry ledger and its reconciliation against wallets runs anyway. You can see this in Marengo, our exchange: it produces a Merkle sum statement of customer liabilities every day, with a public verifier page where each customer can check their own entry. Independent review, by an auditor who checks the tree's construction and the reserves evidence, adds trust that a self-published statement cannot.
For a buyer comparing platforms, the questions to ask are how often the statement runs, whether customers can check their own entry without trusting the exchange, and which half is covered. The guide to choosing a white-label crypto exchange lists the other questions, and the MiCA checklist covers the licence around it.
Frequently asked questions
Is proof of reserves the same as an audit? No. Proof of reserves shows assets at one moment, and proof of liabilities shows what customers are owed at the same moment. An audit of financial statements looks at all assets and all liabilities, including debts that neither proof can see.
Can other customers see my balance? Not from the tree. Leaves are hashed with a salt only you receive, and your path shows only the sums of the nodes beside yours, not who holds them.
Why do I need to check my own entry? Because the tree only proves anything for the customers who check. An exchange could leave an account out, and only that customer would notice.
Does proof of reserves cover fiat? It can. Euros are shown with confirmations from the banks that hold them, compared with the euro balances in the liabilities tree.
See it working
Proof of liabilities is easiest to judge on a working exchange. Open Marengo at marengo.paynoramic.com, or read how our white-label crypto exchange is built and handed over to the licensed operator who runs it.
