Proof of Reserves

A proof of reserves claims that the assets the exchange controls equal or exceed the customer balances it owes at one moment. The asset half is the easy part: the exchange names the addresses it controls and proves control by signing a message with the keys. Anyone can read the balances of those addresses on the chain.

Three things are left out. The proof covers one moment, so it says nothing about the day before or the day after. It says nothing about debts the exchange owes to anyone other than customers, such as a lender whose claim ranks ahead. And unless the liability half is proven too, nothing stops the exchange from understating what it owes.

The liability half uses a Merkle tree. Each customer account becomes a leaf, built by hashing an account identifier together with the balance and a unique random value so nobody can read a balance out of the hash. Leaves are hashed in pairs, the results are hashed in pairs again, and the process repeats until one hash remains at the top: the Merkle root. Change any single balance and the root changes, so the root commits the exchange to the entire set of liabilities it published.

A customer verifies inclusion with a Merkle path, the short list of sibling hashes needed to rebuild the root from their own leaf. The customer hashes their own account data, combines it with each hash in the path in turn, and checks whether the result equals the published root. A walkthrough of the construction shows the path step by step. A match proves that the customer's balance was counted in the total.

An inclusion proof tells one customer their balance was counted. It does not tell them that everyone else's was. An exchange can leave accounts out of the tree, and only the omitted customers would notice, or insert fake accounts with negative balances to reduce the apparent total. Neither manipulation is visible to a customer checking their own path.

Closing that hole needs either an auditor who confirms the tree was built from the complete account ledger, or a cryptographic scheme that proves no balance in the tree is negative. The second route uses zero-knowledge proofs, where the exchange proves the sum is correct and no entry is negative without revealing any individual balance. It is more complex to implement, which is why most published proofs still rely on an auditor for this step. Merkle Science frames the full version as proof of solvency: proof of reserves plus proof of liabilities.

Most of what the industry calls a proof of reserves is an attestation, not an audit. An accounting firm performs agreed-upon procedures at a point in time and reports what it found, without expressing an opinion on the financial statements or testing the internal controls behind them. A financial statement audit covers a whole period, tests the controls, and carries an opinion the auditor is liable for.

Some exchanges have published reserve figures with no independent party at all, which is a self-declaration. Reading the document for the name of the firm, the words describing the engagement and the date is how a customer tells these apart. The procedures a financial statement auditor actually performs on crypto are set out on crypto audit.

European regulation takes a different route to the same concern. A licensed crypto-asset service provider holding client assets has to keep them segregated from its own, hold assets matching its clients' claims in type and quantity, and answer for loss from an incident unless it proves the loss happened without its fault. A custodian also owes its clients a statement of their positions and has to keep a register of positions per client.

That is a continuous obligation enforced by a supervisor, where a proof of reserves is a voluntary snapshot. The two are not substitutes: a MiCA-licensed venue need not publish a Merkle root, and a published Merkle root is no evidence of a license. What a German customer should check first is the authorization, which is the subject of CASP license.

FTX held customer balances that funded an affiliated trading firm, and nobody outside could see it because no independent verification of reserves existed. After the collapse in November 2022, most large exchanges published some form of reserve attestation within months. The practice answered a real question, and it also became a marketing claim, which is why the method matters more than the existence of a page.

For stablecoin issuers a rule handles the same concern instead of a custom. MiCA sets what the reserve of an e-money token has to consist of, where it is held and how it is reported, which the stablecoin reserves answer covers.

No. It is evidence about one moment and, in most published forms, about one half of the balance sheet. An exchange can publish a valid proof on Monday and move the assets on Tuesday, and the proof says nothing about debts owed to lenders ranking ahead of customers. It is a useful signal, and it carries no claim on anybody if the exchange fails. A claim comes from a license, from segregated custody at a regulated entity, or from an insurance policy, and the last of those is covered on crypto insurance.

Monthly is the common cadence, and more frequent is better precisely because the proof covers one moment. A snapshot once a quarter leaves a long window in which nothing is evidenced, and an exchange that can borrow assets for the day of the snapshot can satisfy a predictable schedule without holding the assets the rest of the time. Unannounced timing and continuous address disclosure address that, and neither is standard.

The inclusion of your own balance, yes, when the exchange publishes your Merkle path and the root. Hashing your own leaf and walking the path is arithmetic a browser can do, and most exchanges that publish proofs provide a tool for it. What you cannot verify alone is completeness, whether every other account was counted, and the asset side beyond reading the addresses the exchange chose to disclose. Those two parts need the auditor or the zero-knowledge scheme.