A Merkle tree is a data structure that hashes pieces of data in pairs, then hashes those results in pairs again, until a single hash remains: the Merkle root. Change any piece of data and the root changes, so one short hash commits to the whole set. Bitcoin's whitepaper uses a Merkle tree so that only the root of a block's transactions goes into the block's hash, per the Bitcoin whitepaper, which credits the idea to R.C. Merkle's 1980 paper "Protocols for public key cryptosystems."
​

Merkle trees let a blockchain prove that a transaction, balance or list entry is part of a larger dataset without handing over the whole dataset. This page explains how the tree is built, what a Merkle root and a Merkle proof are, how Bitcoin and Ethereum use them, and how Solidity contracts verify proofs onchain. Sources were fetched on October 13, 2026.
​

A Merkle tree starts by hashing every data item to make the leaves. It then hashes each pair of neighboring leaves together to make the next level up, and repeats the pairing until one hash is left at the top. That top hash, the Merkle root, depends on every leaf below it.
​

Ethereum.org describes the property this creates: the structure forms "a verifiable relationship between all the individual pieces of data entangled in the tree, resulting in a single root value that can be used to prove things about the data," per its Merkle Patricia trie page. Because each level halves the number of hashes, a tree over n items has about log2(n) levels.
​

A Merkle root is the single hash at the top of a Merkle tree. It acts as a fingerprint of every leaf: two datasets with the same root are, for practical purposes, identical, and any edit to any leaf produces a different root. Blockchains store roots in block headers so the header commits to much larger data.
​

In Bitcoin, transactions are hashed in a Merkle tree "with only the root included in the block's hash," which lets old blocks be compacted by stubbing off branches without breaking the block hash, per section 7 of the Bitcoin whitepaper. The whitepaper estimates a block header with no transactions at about 80 bytes. In Ethereum, every execution-layer block header carries three roots, stateRoot, transactionsRoot and receiptsRoot, per ethereum.org's trie documentation.
​

A Merkle proof is the short list of sibling hashes needed to rebuild the path from one leaf up to the root. A verifier who already trusts the root hashes the leaf, combines it with each sibling in turn, and checks whether the result equals the root. If it does, the leaf is in the tree.
​

Proofs are small. In a tree of 8 leaves, proving one leaf takes 3 sibling hashes, and doubling the leaves adds only one more hash, because proof length grows with the tree's depth. Bitcoin's whitepaper builds simplified payment verification on this: a user keeps only block headers and obtains "the Merkle branch linking the transaction to the block it's timestamped in," per section 8 of the Bitcoin whitepaper. Ethereum.org describes comparing root hashes and the hashes that led to them as "a Merkle proof," per its trie page.
​

Ethereum stores its state in a modified Merkle Patricia trie, which combines a Merkle tree's hashing with a radix trie's key-based lookup. Every account, balance and contract storage slot sits in a trie, and the root of the state trie goes into each block header.
​

Per Ethereum.org trie documentation, there is one global state trie in which the path is keccak256 of an Ethereum address and the value is the RLP-encoded account, a four-item array of nonce, balance, storageRoot and codeHash. The storageRoot is itself the root of a separate storage trie for each account, which holds all contract data. The same page says the structure gives O(log(n)) efficiency for inserts, lookups and deletes, and that Ethereum plans a future migration to a Verkle tree, an item on the ethereum.org roadmap.

Roots in headers are what make light clients possible. Light nodes download only block headers and "verify the data they receive against the state roots in the block headers," per ethereum.org's nodes and clients page. The node types that rely on this are covered in What Is a Blockchain Node?
​

A contract can store only a 32-byte Merkle root instead of a full list, then let each user submit a proof that their entry is in the list. The contract recomputes the root from the leaf and the proof and accepts the call only if the roots match. Storage stays small no matter how long the list is.
​

OpenZeppelin's MerkleProof library provides verify(proof, root, leaf), calldata variants and multiProofVerify for proving several leaves at once, per the OpenZeppelin Contracts 5.x documentation. The library hashes sorted pairs, so it supports trees built with commutative hashing, where H(a, b) equals H(b, a). Trees and proofs can be generated with OpenZeppelin's JavaScript merkle-tree library, which the same page says produces trees safe against the leaf-reinterpretation attack described below. The languages these contracts are written in are covered in What Is Solidity?
​

A Merkle proof shows that a leaf is in a tree with a given root. It says nothing about whether the root itself is honest or whether the leaf data is correct. Implementation details also matter: a careless leaf format can let an attacker pass an internal node off as a leaf.

Merkle proofs prove membership, not computation. Proofs that show a computation was done correctly fall under zero-knowledge and validity proofs, covered in What Is a Cryptographic Proof?
​

R.C. Merkle. The Bitcoin whitepaper cites his paper "Protocols for public key cryptosystems" from the 1980 IEEE Symposium on Security and Privacy.
​

The root is the single top hash; the proof is the list of sibling hashes that links one leaf to that root.
​

It uses a modified Merkle Patricia trie for state, transactions and receipts, per ethereum.org's trie documentation.
​

One hash per level of the tree, so about log2 of the number of leaves; 3 hashes for 8 leaves.
​

Definitions and mechanisms come from the Bitcoin whitepaper, ethereum.org and OpenZeppelin's documentation, fetched October 13, 2026. Proof sizes are computed from tree depth.