What is a Merkle tree? How Exchanges Prove They Hold Your Funds

In November 2022, a crypto exchange with roughly a billion dollars in daily volume collapsed. Auditors later put the liabilities at around 9 billion dollars. Nobody outside the company had a way to check the balance sheet before it was too late. But what the industry reached for afterward wasn’t a new regulation. It was a data structure a cryptographer named Ralph Merkle patented in 1979.

A Merkle tree is a hash-based structure that compresses an entire dataset, thousands of transactions, into a single fingerprint called the Merkle root. 

In this piece, we’ll get through how that fingerprint gets built, why it makes tampering nearly impossible to hide, and how it became the tool exchanges now use to show they actually hold your money.

Key Takeaways

• A Merkle tree hashes data in pairs, bottom to top, until one hash remains: the Merkle root.
• Changing a single leaf, like one transaction or one account balance, changes the root completely.
• Exchanges use this property for proof of reserves. They hash every user balance into the tree and let each user confirm their own balance was counted.
• Proof of reserves shows assets. It doesn’t automatically show liabilities, and that gap matters more than most explainers admit.

What Is a Merkle Tree, and Why Does It Exist?

A Merkle tree, also called a hash tree, is a binary tree built entirely from cryptographic hashes. Every leaf holds the hash of one piece of data. Every node above that holds the hash of its two children. Follow that pattern to the top, and you land on one hash, the Merkle root, which mathematically represents everything beneath it.

Imagine a network with thousands of nodes, each one needing to confirm a single transaction is real. And without a Merkle tree, that means downloading and comparing the entire ledger, over and over, across every node. That’s a huge amount of data movement for one yes-or-no answer. A Merkle tree turns that into checking one small trail of hashes against a root.

From leaf nodes to the Merkle root

Building the tree is mechanical once you see it once. Say a block holds four transactions: T1 through T4.

1. Hash each transaction individually. These four hashes, H1 through H4, become the leaf nodes.
2. Pair the leaves and hash each pair together. H1 and H2 combine into H12; H3 and H4 combine into H34.
3. Hash the two remaining values, H12 and H34, together to get H1234.
4. H1234 is the last hash standing. That’s your Merkle root.

If there’s an odd number of items at any level, the last hash gets duplicated so the pairing still works, a rule Bitcoin itself follows. Nothing above this level cares what the original transaction data actually said. It only cares about the hash. That distinction is the entire reason the next section matters.

How Cryptographic Hash Functions Anchor the Structure

None of this works without the hash function doing its job correctly. A cryptographic hash takes an input of any size and returns a fixed-length output. Feed it a word or a whole database, and the output is always the same length. Bitcoin and most blockchain implementations use SHA-256, which always produces a 256-bit result regardless of input size.

Three properties matter here:

• Deterministic: The same input always produces the same hash. Run it a thousand times, get the same answer.
• One-way: You can’t work backward from a hash to reconstruct the original data. That’s what makes it a fingerprint rather than a container.
• Collision-resistant: Finding two different inputs that produce the same hash is computationally infeasible with a well-designed function like SHA-256.

That last property is what makes the Merkle root trustworthy. Because every level of the tree is just a hash of the level below it, changing a single character in one original transaction produces a completely different leaf hash. That different leaf hash produces a different parent hash. That cascades all the way to the top, and the Merkle root comes out looking nothing like it did before.

This is why I’d describe the Merkle root as a fingerprint rather than a summary. A summary can approximate. A fingerprint either matches exactly or it doesn’t, and cryptographic hashing is what guarantees there’s no in-between.

This behavior is called the avalanche effect. A tiny input change should flip roughly half the output bits, so the two hashes look statistically unrelated even though only a character was changed. And it’s what stops someone from tweaking a transaction.

How Merkle Proofs Verify Data Integrity

A Merkle proof lets anyone confirm that one specific piece of data, one transaction, one account balance, belongs to the tree without downloading everything else in it. 

Say you want to prove transaction T1 is part of the four-transaction tree from earlier. You’d need:

1. H1, the hash of your own transaction.
2. H2, the sibling leaf, so the two can be combined into H12.
3. H34, the sibling branch, so H12 and H34 can be combined into H1234.
4. Compare your computed H1234 against the published Merkle root. Match means verified.

You never had to see T2, T3, or T4. That’s the point. In a tree with thousands of entries, proving inclusion needs roughly a dozen hash comparisons, not thousands. Because the number of hashes required grows with the number of tree levels (logarithmically), not the number of items in the tree. 

That efficiency is what makes data integrity checking practical at scale. Any tampering with the underlying data shows up as a Merkle root mismatch, and the mismatch is detectable without anyone having to inspect the raw dataset directly.

This same idea powers Simple Payment Verification (SPV). It’s the method lightweight Bitcoin wallets use to confirm a payment without storing the full blockchain. An SPV wallet keeps only block headers and requests a Merkle proof from a full node whenever it needs to check a transaction. That proof confirms the transaction was included in a block.

Proof of Reserves: How Exchanges Use Merkle Trees to Prove They Hold Your Funds

This is the part that actually affects your money. After the November 2022 collapse referenced at the top of this article, exchanges came under pressure to prove, cryptographically rather than verbally, that customer funds were actually sitting in their wallets. Merkle trees became the mechanism of choice.

Here’s roughly how an exchange builds a proof of reserves:

1. Every user’s account ID and balance gets hashed together, usually with a random salt added first so individual balances stay private.
2. Those hashes become the leaves of a Merkle tree covering every customer on the platform.
3. The exchange computes and publishes the Merkle root, along with proof that it controls on-chain wallets holding at least that much in assets.
4. Each user gets their own “Merkle path,” the specific chain of sibling hashes connecting their leaf to the published root, so they can verify their own balance was counted without seeing anyone else’s.

Binance rolled this out within weeks of the FTX collapse, pairing the Merkle tree with zk-SNARKs so individual balances stay hidden even from someone examining the tree structure. 

Kraken had actually been doing something similar since 2014, and its process shows what the output looks like in practice: its March 2025 proof of reserves confirmed 192,091.25 BTC held against customer balances of 167,188.68 BTC, a reserve ratio of 114.9%, meaning Kraken held nearly 15% more Bitcoin than it owed users at that snapshot.

What proof of reserves doesn’t prove

This is the part most people skip. Proof of reserves confirms assets. It doesn’t automatically confirm liabilities, and the two are not the same question.

An exchange could show a Merkle root full of real on-chain Bitcoin and still be technically insolvent if it borrowed those coins the day before the snapshot and has to return them the day after. 

A proof of reserves audit is a point-in-time attestation, not continuous solvency monitoring. Kraken’s own team has been explicit that a proof missing the liabilities side of the ledger isn’t a full proof of reserves at all, just a partial one that only shows the flattering half.

None of that makes the technology worthless. It makes it one input, not a guarantee.

Merkle Tree vs. Binary Hash Tree vs. Verkle Tree

Merkle trees aren’t the only hash-based verification structure, and the newer alternative is worth knowing about if you’re going to understand where this technology is headed.

The difference is proof size. A Verkle tree can generate a proof under 150 bytes for a structure holding over a billion data points. Because it uses vector commitments and polynomial math instead of stacking hash after hash. A Merkle tree covering that same billion entries would need a proof with dozens of hashes stacked up, still fast, but measurably bigger. 

For a proof of reserves system with a few million users, that difference barely matters. But for a blockchain trying to let lightweight clients verify state without storing GBs of data, it matters a lot.

A Worked Example: Detecting a Single Tampered Transaction

The clearest way to see why this matters is to watch the root actually change. Take four sample transactions:

• T1: Alice pays Bob 5 BTC
• T2: Bob pays Charlie 2 BTC
• T3: Charlie pays Dave 1 BTC
• T4: Dave pays Alice 3 BTC

Hash each one, pair them, hash the pairs, and you land on a Merkle root. Call it Root A.

Change T1 so Alice pays Bob 6 BTC instead of 5, leaving every other field untouched. Recomputing the tree produces a completely different root, Root B, even though only one number changed. Root B shares none of Root A’s structure. 

That’s collision resistance in action. A small change in the underlying data creates a different hash output. A verifier holding Root A can detect the mismatch immediately when submitted data produces Root B. There is no need to compare all four transactions line by line. One hash comparison at the top shows that something changed somewhere below. Bitcoin nodes use this same process to reject a block when its transactions don’t reproduce the Merkle root stored in the block header. Exchanges also rely on Merkle proofs to show that a user’s balance matches data committed to a published root.

Final Thoughts

The interesting part of this technology, to me, isn’t the crypto use case specifically. It’s how old and how portable the idea is. Merkle trees show up in Git’s version history, in Certificate Transparency logs that keep browsers honest about which SSL certificates are real. And in distributed file systems that need to detect corruption without re-checking every byte. The exchange proof-of-reserves use case is just the most visible one right now because it’s tied to a very expensive lesson the industry learned in 2022.

Verkle trees are the next step for systems that need this at a much bigger scale, and Ethereum’s roadmap toward stateless clients is worth watching if you want to see where that goes next.

If you use a centralized exchange, the practical takeaway is smaller: check whether your exchange publishes proof of reserves, verify your own balance is included when it does, and remember that the assets side of the ledger is only half the picture.

For more info on crypto and all things Web3, visit Blockverse.

FAQs