Proof of reserves did not begin as a general badge for trustworthy exchanges. It was a specific response to a narrower accounting problem: customers could see a balance on screen but had no way to know whether the exchange controlled enough bitcoin to honour all of those balances at once.
The Missing Side of the Early Exchange
An early exchange exposed its market and concealed its ledger. Users could watch orders appear, compare bids and asks, and inspect their own account. They could not add every customer balance together, inspect the operator's wallets, or establish whether the two totals matched. A functioning withdrawal proved only that one withdrawal had been paid. It did not show that every other customer could leave at the same time.
Separating hot wallets from cold storage reduced the amount exposed to an online compromise, but it did not answer the accounting question. An exchange might secure the coins it held perfectly and still hold fewer coins than it owed. Security of custody and completeness of reserves are related controls, not substitutes.
The gap became impossible to ignore after exchange failures in 2012 and 2014. The proposed answer borrowed a cryptographic structure already suited to proving that one record belongs inside a much larger set: the Merkle tree.
The March 2014 Kraken Audit
On 24 March 2014 Kraken announced what it called the first cryptographically verifiable proof-of-reserves audit. Stefan Thomas carried out the engagement. According to Kraken's contemporaneous account, he verified that the bitcoin controlled by the exchange exceeded the total required to cover customer balances, using a variation of a Merkle-tree method associated with Greg Maxwell and Zak Wilcox.
The important addition was customer verification. Each customer could check that the balance attributed to that account had been included in the liability total without being shown anybody else's balance. That was more informative than an exchange publishing a wallet address: it connected a public claim about assets with a private but individually checkable claim about what the exchange owed.
Kraken's announcement called the exercise a first step rather than a finished accounting standard. That caution still matters. Kraken's current explanation says there are no universally accepted rules that make every procedure called proof of reserves equivalent.
What the Merkle Tree Contributes
The procedure begins with a snapshot of customer balances. Those records are anonymised and hashed, then combined repeatedly until a single Merkle root represents the set. A customer receives the information needed to reconstruct a path from the account record to that root. If the path resolves correctly, the account was included in the snapshot; changing another record would change the resulting root.
On the asset side, the exchange signs messages or otherwise demonstrates control of blockchain addresses whose balances can be inspected publicly. An independent accountant compares the in-scope assets with the liability total represented by the tree. The comparison is the point. A wallet balance without liabilities is only evidence that someone controls coins. A liability tree without controlled assets is only evidence of what is owed.
This is also why a visible order book with many currency markets was never evidence of solvency. Market data describes offers to trade. Proof of reserves tries to describe whether the custodian can return what customers have already deposited.
A Snapshot Has Edges
A proof is tied to its snapshot time and its stated scope. It does not show what happened immediately before or after, whether assets were temporarily borrowed, whether every legal entity was included, or whether the exchange has obligations that the chosen liability set excludes. It also does not assess security controls, governance, cash liabilities or the quality of internal bookkeeping between reviews.
That does not make the procedure empty. It makes the wording important. A customer-level inclusion check, controlled on-chain assets and an independent comparison answer a real question. A reserves page that omits liabilities answers a different one. The practice that appeared in March 2014 was valuable precisely because it joined the two.