What Is a Merkle Tree? How Blockchains Prove Data Without Handing Over All of It

Every Bitcoin block commits to every transaction inside it with a single 32-byte number. That number — the Merkle root — sits in the block header, and it exists because of a data structure Ralph Merkle patented in 1979, years before anyone needed a word for a blockchain. Understanding the Merkle tree explains something most crypto introductions skip: how a wallet that holds no copy of the blockchain can still prove your transaction was included in a block.

What a Merkle tree actually is

A Merkle tree, also called a hash tree, is a way of summarising a list of data with one hash while keeping every item independently verifiable. Start with the data items — in Bitcoin's case, transactions. Each item is hashed, and those hashes become the leaves of a binary tree. Two leaves are concatenated and hashed together to form a parent; pairs of parents are hashed to form grandparents; and so on until exactly one hash remains at the top. That final hash is the Merkle root.

The structure matters more than the name. Every hash above a leaf depends on the leaf below it, so changing a single byte in a single transaction changes the leaf, then the parent, then the grandparent, and eventually the root. Nothing else in the tree has to be recomputed. That is the property blockchains lean on constantly: a fixed-size commitment to an arbitrarily large data set, cheap to update and verifiable one item at a time.

Why you cannot simply hash the whole list

You could concatenate every transaction in a block and hash the result. That also produces a single digest. What you lose is granularity: to prove that one transaction was included, you would have to hand over the entire list, and the verifier would have to hash all of it. With roughly a thousand transactions per block, that is tens of kilobytes per proof, repeated across every light wallet, bridge message and exchange deposit check. A Merkle tree keeps the same single commitment while making the proof proportional to the logarithm of the item count instead of the count itself.

For a sense of how much data sits behind one of these commitments, our guide to what a block explorer shows walks through a block page field by field.

How the tree is built, step by step

Bitcoin's construction is specific enough to reproduce by hand:

• Hash each transaction separately. Bitcoin uses double SHA-256: the transaction bytes are hashed twice.
• Pair adjacent hashes. Concatenate two 32-byte hashes and hash the resulting 64 bytes.
• When a level holds an odd number of hashes, the last one is paired with itself. Bitcoin duplicates the final hash rather than carrying it upward unchanged.
• Repeat until one hash is left. That is the Merkle root.

The root goes into the block header: an 80-byte structure holding the protocol version, the previous block's hash, the Merkle root, a timestamp, the difficulty target and the nonce. Because the header is what miners hash and what each new block points back to, the root indirectly commits to every transaction in the block — and, through the chain of headers, to every block before it.

A live example: block 973,156

Bitcoin block 973,156, mined on 26 October 2026 at 01:14 UTC, contained 759 transactions. Its header carries the Merkle root 1857e339fbd8f0db386de1322652e8980bdf53faea100a2f6547c7067bc0458d. To confirm that is not a decorative number, we pulled all 759 transaction IDs from a public node API, applied Bitcoin's pairing rules including the duplicate-last-hash step, and hashed upward. The computed root came out byte-for-byte identical. Anyone with a short script and an internet connection can repeat that check in seconds; no private data is involved.

What a Merkle root proves, and what it does not

A Merkle root is a commitment, not a certificate. It proves that a specific set of transactions existed, in that order, when the block was assembled — any change to the set produces a different root. It does not prove the transactions were valid; that requires checking signatures, inputs and consensus rules. It does not prove the block is on the heaviest chain; that comes from accumulated proof of work above it, which is what proof of work and proof of stake are competing designs for. And it does not prove the underlying data is still available to anyone.

The commitment does make ordering auditable. Because the root fixes the exact sequence, a miner cannot quietly reorder or insert transactions after the fact without producing a different header, and therefore a different block hash. Ordering has economic value, which is the premise behind MEV and transaction ordering.

Merkle proofs: how a wallet checks a block it never downloaded

Suppose you want to prove that transaction number 400 of 759 is inside that block. Instead of sending 759 transaction IDs, a node sends the sibling hash at each level on the path from your leaf to the root: ten hashes for this block, roughly 320 bytes. The verifier hashes your transaction, combines it with the first sibling, hashes again, and repeats up the path until it produces a candidate root. If the candidate matches the header's Merkle root, inclusion is established.

That is the mechanism behind simplified payment verification, described in section 8 of the original Bitcoin paper: a wallet storing only block headers can verify that a transaction belongs to a block without downloading the block. It is also why the proof is cheap to check and effectively impossible to forge, short of finding a SHA-256 collision. The security caveat is inherited rather than created: a light client is trusting that the header it holds sits on the heaviest chain, and most real light-client risk lives there.

An inclusion proof also says nothing about how many blocks have been built on top of that one. Confirmation depth is a separate question, which is why exchanges wait for several blocks rather than one, and why a transaction can sit in the mempool for hours before it appears in any block at all.

The duplicate-hash quirk that became CVE-2012-2459

Bitcoin's duplicate-the-last-hash rule produces a structural oddity: the transaction lists [a, b, c] and [a, b, c, c] hash to the same Merkle root. In a conventional binary hash tree that cannot happen, because every level would hold a power-of-two number of nodes.

In 2012 that oddity became a network-level problem. An attacker could take a valid block, duplicate a transaction in a way that preserved the Merkle root, and relay the modified version: same block hash, invalid transactions. A node that received the mutated block first could store it as the block at that height, reject it as invalid, and then decline to re-request the genuine block — stalling at the chain tip. The flaw was publicly disclosed in August 2012 and closed by a patch that rejects blocks containing duplicate transactions. The lesson outlived the bug: padding choices are security decisions, and a commitment scheme has to be designed against an adversary, not just the happy path.

Custom designs run into a cousin of the same issue. If leaves and internal nodes are hashed in exactly the same way, an attacker can present an internal node as though it were a leaf. Airdrop and allowlist contracts handle this by hashing each leaf twice, or by prefixing leaf and node hashes differently. If you ever build one, copy a reviewed library instead of writing the tree yourself.

Ethereum's version: three roots, not one

Ethereum uses the same idea in a different shape. A block header carries three commitments: the transactions root, the receipts root (status, logs and gas used for each transaction) and the state root (the whole account and storage state after execution). Since the Merge, validators attest to an execution payload header containing those values, so one commitment scheme spans consensus and execution.

The structure beneath them is a Merkle Patricia Trie rather than a plain binary tree: a hexary, path-compressed key-value trie keyed by account address or storage slot. That makes a proof of "this account holds this balance" possible without shipping the entire state, which is what archive-free RPC providers depend on. Ethereum researchers have long proposed replacing it with Verkle trees (EIP-6800) to shrink proofs further; that remains research and is not live on mainnet.

The state root is also why smart contracts cannot quietly change what they store. Every write moves the root, and the root is part of what the network agreed on.

Where else the same structure shows up

• Git. Each commit object points to a tree object, which points to blobs and subtrees. The commit hash covers all history beneath it, which is why rewriting history changes every downstream hash.
• Certificate Transparency. RFC 6962, revised as RFC 9162, specifies Merkle hash trees for append-only logs of TLS certificates, so a browser can verify that a certificate was logged without downloading the log.
• Airdrops. Uniswap's 17 September 2020 distribution of 400 UNI to more than 250,000 addresses used a distributor contract holding one Merkle root; each claimant submits a proof for their own address and amount. A single 32-byte storage slot replaced a list of a quarter of a million entries.
• Zero-knowledge proofs. Membership checks inside a circuit are usually Merkle proofs, which is how a proof can attest to holding something without revealing which leaf is yours — the idea behind zero-knowledge proofs.
• Bridges and rollups. Cross-chain messages and withdrawal claims are committed with roots so a verifier on the destination chain can check inclusion with a short proof, a design our crypto bridge explainer covers.

What Merkle trees do not solve

Three limits are worth stating plainly, because they get confused with the structure itself.

• Truth. A root commits to whatever data was placed in the tree. If the data is wrong, the root is a perfectly valid commitment to something wrong. Getting correct external data on-chain is the oracle problem, covered in our Chainlink explainer.
• Availability. A root can be published for data nobody else holds. The commitment verifies and the underlying data is still missing — the data-availability problem that modular rollups spend much of their design budget on.
• Privacy. A proof reveals which leaf is being proved. Merkle trees hide the rest of the set, not your position in it.

How to see it for yourself

The quickest walkthrough: open any block in a block explorer, find the Merkle root in the header, then pull that block's transaction IDs from a public API and recompute the root with a dozen lines of Python. Bitcoin needs double SHA-256 and the duplicate-last-hash rule; Ethereum exposes its three roots directly through eth_getBlockByNumber. If your computed value matches, you have verified a commitment scheme most users rely on without ever seeing it. If it does not match, check byte order first — Bitcoin displays hashes reversed relative to the bytes it hashes, which is the most common reason a correct computation looks wrong.

The bottom line

A Merkle tree turns a list into one commitment while keeping every item provable on its own. Bitcoin uses it to fit an entire block's transactions into 32 bytes of header. Ethereum uses three Patricia-trie roots to commit to transactions, receipts and state. Git, Certificate Transparency, airdrops and zero-knowledge systems use the same trick for the same reason. The Merkle root is not proof that anything is true or available — it is a compact, tamper-evident claim about what a set contains, and nearly every light-client design in crypto is built on that narrow, extremely useful guarantee.