Merkle-tree attestation
A Merkle-tree attestation is a cryptographic technique used in Proof of Reserves programs to commit to a complete list of customer liabilities in a single hash, allowing each individual customer to verify that their balance was included in the audited total without requiring the custodian to publish the full liability list.
The Merkle-tree attestation became the standard mechanism for Proof of Reserves after Kraken's March 2014 implementation, based on a construction proposed by Bitcoin Core developer Greg Maxwell. Before this, reserve attestations relied on either signed messages from the custodian's wallets (which proved control of the assets but not coverage of liabilities) or on the custodian's own published statement of total customer balances (which could not be independently verified by individual customers).
The Merkle-tree solves a specific problem: how can a custodian publish a verifiable commitment to its total customer liabilities without revealing each individual customer's balance to other customers or to the public?
The technique works as follows. The custodian constructs a binary tree where each leaf node represents one customer's balance (or a hash of it, with a salt for privacy). Each internal node of the tree is the hash of its two child nodes. The root of the tree, a single hash known as the Merkle root, commits to the entire set of liabilities. The custodian publishes only the Merkle root.
Each customer is given the path from their leaf node to the root: their own balance, the sibling hashes at each level of the tree, and the Merkle root. The customer can independently verify by computing the hashes along the path and confirming that the result matches the published Merkle root. If it does, the customer's balance is provably included in the audited total without the custodian having to publish anyone else's balance.
The Merkle-tree attestation handles the liability side of Proof of Reserves. It does not address the asset side: the custodian still has to separately demonstrate control of on-chain reserves sufficient to cover the audited liabilities. Modern Proof of Reserves programs combine the Merkle-tree liability attestation with either a wallet-snapshot demonstration or a third-party auditor's verification of the reserves.
Merkle-tree attestations describe customer-balance inclusion at the moment of attestation. They do not describe what happens between attestations, whether the assets backing the liabilities are pledged elsewhere, whether the assets are segregated from platform balances on-chain, or who controls the keys to the wallets holding the reserves. These limitations are properties of what reserve attestations can do by construction, not flaws in the Merkle-tree implementation specifically.
Related Reading
A Merkle-tree attestation is a cryptographic technique in Proof of Reserves programs that commits to a complete customer liability list in a single hash. Each customer independently verifies their balance was included by computing the hash path from their leaf to the published Merkle root. Onramp's research examines what Merkle-tree attestations prove and what they cannot establish about Bitcoin custody safety.
Frequently Asked Questions
What is a Merkle-tree attestation?
A Merkle-tree attestation is a cryptographic technique that commits to a complete list of customer liabilities in a single hash (the Merkle root). Each customer can independently verify their balance was included by computing the hash path from their leaf node to the published root, without the custodian having to reveal anyone else's balance.
What does a Merkle-tree attestation prove?
A Merkle-tree attestation proves that a specific customer balance was included in the audited liability total at the moment of attestation. It does not prove what happens between attestations, whether the backing reserves are segregated or encumbered, or who controls the keys.
Who introduced the Merkle-tree Proof of Reserves construction?
The construction was proposed by Bitcoin Core developer Greg Maxwell and first implemented by Kraken in March 2014, audited by Stefan Thomas. It solved the problem of proving aggregate liabilities while letting each customer verify their individual balance privately.