What Is a Merkle Tree in Bitcoin? Merkle Root and Proofs Explained
A Merkle tree condenses every transaction in a Bitcoin block into one Merkle root stored in the block header. How the tree is built, what a Merkle proof is, why SPV wallets depend on it, and where the pattern shows up in proof of reserves.
By the BitcoinDatabase team
July 2026 · 8 min read
The short answer
A Merkle tree in Bitcoin is a hash tree that condenses every transaction in a block into a single 32-byte value called the Merkle root, which is stored in the block header. Because changing any transaction changes the root, the root is a tamper-evident fingerprint of the whole block, and it lets a lightweight client prove one transaction is in a block by checking a handful of hashes instead of downloading it.
The Merkle tree is one of those pieces of Bitcoin that sounds academic until you notice how much depends on it: block headers, SPV wallets, proof of reserves at exchanges, and the reason an 80-byte header can commit to a block holding thousands of transactions. Ralph Merkle patented the idea in 1979, decades before Bitcoin, and Satoshi used it more or less unchanged.
What is a Merkle tree in Bitcoin?
Take every transaction in a block and hash each one. Pair the hashes up and hash each pair together. Pair those results and hash again. Keep going until only one hash remains: that is the Merkle root, and it goes into the block header alongside the previous block hash, timestamp, difficulty target and nonce. Bitcoin uses double SHA-256 at each step, and when a level has an odd number of hashes the last one is duplicated so it can be paired with itself. The tree structure means a block with 4,096 transactions needs only 12 levels.
How does the Merkle root work?
The root is a commitment. Flip one satoshi in one output of one transaction and that transaction's hash changes, which changes its parent, which changes every hash on the path up to the root. Since the root sits in the header, and the header is what miners hash to find a valid block, a changed root means the block's proof of work no longer holds. That is the whole security argument in one sentence: you cannot alter a confirmed transaction without redoing the work for that block and every block after it.
| Transactions in block | Tree levels | Hashes in a Merkle proof | Proof size |
|---|---|---|---|
| 16 | 4 | 4 | 128 bytes |
| 1,024 | 10 | 10 | 320 bytes |
| 4,096 | 12 | 12 | 384 bytes |
Proof size grows with the logarithm of block size, so even a full block needs only a few hundred bytes to prove inclusion.
What is a Merkle proof?
A Merkle proof, sometimes called a Merkle path or branch, is the set of sibling hashes needed to recompute the root starting from one transaction. Give a verifier the transaction hash plus those siblings, and they hash their way up the tree. If they land on the root that appears in the block header, the transaction is provably in that block. They never see the other transactions, and they never download the block. That combination of small size and no trust is why the structure keeps getting reused far outside Bitcoin.
Why does Bitcoin use a Merkle tree?
Two reasons. First, it lets a fixed 80-byte header commit to an arbitrarily large block, which keeps the header chain small enough that a phone can hold all of it. Second, it makes inclusion provable cheaply, which is what simplified payment verification depends on. Satoshi described SPV in the original white paper: a client keeps only headers, asks a peer for the Merkle branch of a transaction it cares about, and verifies it against the header chain. Without the tree, a light client would have to trust its peer or download everything.
How do SPV wallets use Merkle trees?
An SPV or light wallet downloads block headers rather than full blocks, then requests Merkle proofs for the transactions paying its addresses. It verifies each proof against the header, and counts the blocks mined on top to gauge how settled the payment is. The tradeoff is that SPV proves inclusion, not validity: it shows a transaction is in a block that has work behind it, but the client is trusting that miners enforced consensus rules rather than checking them itself. For most wallets that is an acceptable trade, and it is closely related to how many confirmations you should wait for.
Where else are Merkle trees used in crypto?
The most visible use outside blocks is proof of reserves. An exchange hashes every customer balance into a leaf, builds the tree, and publishes only the root, so each customer can verify their own balance was counted in the total without seeing anyone else's. Several large exchanges now wrap that in a zero-knowledge proof as well, which additionally shows no leaf held a negative balance. The mechanics of that are covered in what is proof of reserves, and the on-chain side sits behind the Bitcoin proof of reserves API. The same pattern turns up in software supply chains and certificate transparency logs, and in any system that needs to catch a record changing after the fact, which is the same instinct behind monitoring a data pipeline for silent changes it never announced.
What is the Merkle root in a block header?
It is a 32-byte field, one of six in the 80-byte header, holding the double SHA-256 root of that block's transaction tree. The coinbase transaction is always the first leaf, which matters because segwit commits the witness Merkle root inside a coinbase output rather than in the header itself, keeping the header format unchanged since 2009. You can read the Merkle root of any block directly from its header, and recompute it from the block's transaction list to confirm it matches.
Reading Merkle data from the chain
Every header since the genesis block carries its Merkle root, and every block carries the transaction ordering the root was built from, so this is all verifiable from indexed chain data rather than taken on faith. BitcoinDatabase parses every block since 2009 and exposes headers, Merkle roots, transaction lists and per-transaction detail over REST, SQL and dashboards, so you can pull a block header, list its transactions in order, or rebuild a proof. Start with the Bitcoin block explorer API, or read how to query the Bitcoin blockchain. Informational on-chain data only, not investment advice.
Hit Run to query the fully-indexed Bitcoin blockchain.
BTC
30-day trend
informational on-chain data · not financial advice
Query the Bitcoin blockchain yourself
Pull balances, UTXOs, transactions, on-chain metrics and fund flows from the fully indexed Bitcoin blockchain by REST API, SQL and dashboards. Indexed since 2009, new blocks within seconds, no node to run.