Merkle tree — a binary tree where each leaf is a piece of data, each non-leaf node is the cryptographic hash of its two children, and the single root hash commits to the entire tree — is one of the foundational data structures of Bitcoin and the basis of Proof of Reserves. Named after Ralph Merkle, who patented the structure in 1979. Used in Bitcoin since the genesis block in 2009.
What the structure achieves
Two properties matter for crypto applications:
Compact commitment. The single 32-byte root hash represents arbitrary amounts of data. A Merkle tree over 1 million transactions still produces one 32-byte root.
Efficient membership proof. To prove that a specific transaction is included in the tree, you need only the path from the leaf to the root — typically 20-32 hashes for trees with millions of leaves. The verifier hashes their own data alongside the provided path; if the recomputed root matches the published root, membership is proven.
Where Merkle trees show up in your custody plan
Three concrete examples:
Proof of Reserves at CEXes. Binance, OKX, Bybit, Bitget, Kraken all publish Merkle-tree PoR. Each user's balance is a leaf in a tree; the published root commits to the total. The user can independently verify their balance is included by walking the path from their leaf to the published root. Without Merkle trees, this kind of verifiable disclosure would not be feasible at exchange scale.
Bitcoin block construction. Each block contains a Merkle root of all transactions in the block. SPV (simple payment verification) clients use this to prove that a specific transaction is in a confirmed block without downloading the entire block. The Bitcoin whitepaper devotes a full section to this construction.
Airdrop distribution. Many airdrops use Merkle trees to publish the eligibility list. Each eligible address and amount is a leaf; the root is committed to the airdrop smart contract. To claim, a user provides the Merkle path proving their address is in the tree. This pattern enables airdrops to millions of addresses without onchain storage costs scaling proportionally.
How to verify your own balance in a CEX PoR
The procedure on Binance:
- Log into Binance, navigate to Account → Proof of Reserves.
- The page shows your account ID, your Merkle leaf hash, and the path of hash siblings from your leaf to the root.
- Compare the displayed root hash with the root hash on Binance's public PoR page (binance.com/en/proof-of-reserves).
- If they match, your balance is verifiably included in the published total.
The math: your leaf hash combined with the first sibling produces the next-level hash. That hash combined with the next sibling produces the level after. Continuing up the tree, the final result should equal the published root. Modern PoR tools do this verification automatically; for a US-resident holder past the five-figure threshold, running it once per quarter is the meaningful operational habit.
What a Merkle root does not prove
The Merkle tree commits to the data at the moment of construction. It does not prove the data is correct (the exchange could include incorrect balances), does not prove the corresponding assets actually exist (separate Proof of Liabilities and Proof of Reserves are both needed), and does not prove the tree's leaf set is complete (the exchange could omit some accounts entirely).
This is why a credible PoR combines a Merkle tree of liabilities with a separate cryptographic attestation of reserve addresses and an independent audit. The Merkle tree is necessary but not sufficient.
Further reading: Proof of Reserves, CEX.