The idea is older than FTX. As early as 2013, the Bitcoin developer Greg Maxwell sketched how an exchange could prove its reserves using an on-chain transaction to show its assets and a Merkle proof to show what it owed customers. The concept took shape in the wake of the 2014 Mt. Gox collapse, in which roughly 850,000 bitcoin went missing, about 750,000 of it belonging to customers. The first article in this series explained why most published reports fall short of real proof. This article walks through the machinery that a strong proof actually uses, in terms a reader who has never touched a hash function can follow.
Two Halves of One Claim
Solvency is a claim about two numbers: what a custodian holds, and what it owes. A real proof of reserves therefore has two halves, and both are needed. The first half is proof of assets: a demonstration that the custodian controls the on-chain funds it says it does. The second half is proof of liabilities: a demonstration of the total it owes customers. Only when assets are shown to be at least as large as liabilities does the pair amount to a proof of solvency. A report that delivers only the first half, which is the common case, proves that assets exist but says nothing about whether they are enough.
Proof of Assets
The asset side is the more intuitive half. Because public blockchains are transparent, anyone can see the balance held at a given address. To show that it controls an address, a custodian signs a specific message with the private key for that address. A valid signature demonstrates that whoever produced it could sign with that key at that moment, and the on-chain balance is visible to all.
This is powerful but limited, and the limits matter. A signature does not prove that the custodian is the sole controller of the key, that the key was not borrowed for the exercise, or that two different entities are not pointing at the same address. It also captures a single instant. These are not reasons to discard proof of assets; they are reasons to understand exactly what it does and does not establish, and to pair it with the liability side and with continuous monitoring.
Proof of Liabilities and the Merkle Tree
The harder half is proving what a custodian owes without publishing every customer's private balance. The standard tool is a Merkle tree, the structure Maxwell pointed to over a decade ago.
Picture it from the bottom up. The auditor takes each customer account and creates a leaf: the customer's identifier and balance, scrambled through a hash function, a one-way operation that turns any input into a fixed-length string that cannot be reversed. Each balance is also combined with a unique random value, called a salt, so that two identical balances do not produce identical leaves. The auditor then pairs leaves together and hashes each pair into a new node, then pairs those nodes and hashes again, and so on up the tree until a single value remains at the top. That value is the Merkle root: one short fingerprint that uniquely summarizes every balance in the tree at the moment of the snapshot. Change any customer's balance by a single unit and the root changes completely.
The elegance is in what each customer can then check. The exchange gives each customer a Merkle proof: the small set of neighboring hashes needed to recompute the path from that customer's own leaf up to the published root. The customer hashes their own balance, combines it step by step with the supplied neighbor hashes, and confirms the result matches the root the exchange published. If it matches, their balance was included in the total the exchange claims to back, and they learned nothing about anyone else's account. The sum of all the leaves is the exchange's stated total liability to customers, and the asset proof must cover it.
Closing the Holes With Zero Knowledge
The basic Merkle scheme has a known weakness. A dishonest exchange could insert fake accounts with negative balances to make its total liabilities look smaller than they are, and a customer checking only their own path would not notice. To close this and related gaps, exchanges have adopted zero-knowledge proofs, specifically zk-SNARKs.
A zero-knowledge proof lets one party prove that a computation was performed correctly without revealing the inputs. Applied to reserves, an exchange can prove, for example through the system Binance built and open-sourced, that every leaf in the tree contributed to the claimed total and that no account carries a negative net balance, all without exposing any individual customer's balance. The privacy of the basic Merkle approach is preserved, and the obvious manipulation is ruled out by mathematics rather than by trust in the operator.
From Snapshots to Continuous Verification
Even a complete two-sided proof shares one limitation with the attestations described in the first article: it describes a single moment. The day after the snapshot, the picture can change. Two developments address this.
The first is cadence and consistency. Exchanges such as Kraken have committed to recurring proof-of-reserves engagements on a regular schedule, historically working with the accounting firm Armanino and continuing to publish reserve reports through 2025. Frequency does not make a snapshot continuous, but a steady series is harder to game than a single staged photograph.
The second is continuous on-chain attestation. Services such as Chainlink Proof of Reserve use decentralized oracle networks to monitor reserve balances and publish verified data on-chain in near real time, rather than at intervals. Some implementations connect that data directly to a token contract so that new units cannot be minted unless reserves back them, a control sometimes called secure minting. This moves verification from a periodic event toward a property that holds, and can be checked, at any time.
What Proof Can and Cannot Do
Put together, these techniques are a real advance over a signed PDF. A well-built proof shows that assets exist and are controlled, that liabilities are fully counted, that no negative balances are hidden, and increasingly that all of this holds continuously rather than once a quarter. That is far more than the reports most depositors saw after FTX.
It is still not everything. A proof cannot establish sole and exclusive control of a key, cannot see off-chain debts that never touch the blockchain, and cannot stop a custodian from genuinely losing assets after the proof is produced. And every proof rests on a deeper assumption that is easy to overlook: that the ledger the proof commits to is itself durable and cannot be quietly rewritten. The final article in this series turns to that assumption, and to why the chain underneath a proof of reserves is as important as the proof itself.
This article is for informational purposes only and does not constitute investment advice.
Mintlayer Web Services provides Bitcoin-native issuance and settlement infrastructure where on-chain supply is auditable by design. Learn more →
