Crypto Gloss

Merkle Proof

A Merkle proof is a compact set of sibling hashes, plus the directions needed to combine them, that lets a verifier check whether a particular leaf is committed to by a known Merkle root. The verifier hashes the item, works up the path, and compares the result with the root. The proof can establish inclusion without downloading every other item, but only if the root itself is authentic and the verifier follows the data structure’s exact encoding rules.

How verification works

For a binary tree, a proof supplies the sibling hash at each level. The verifier hashes the leaf with its sibling in the correct left-right order, repeats this up the path, and checks whether the computed value equals the trusted root. A tree with roughly one million leaves needs about 20 sibling hashes for a simple balanced-tree proof; actual formats can add metadata or use different branching rules.

The root is a commitment, not a signature or an independent source of truth. A valid path proves that bytes are included under that root. It does not show that the bytes are accurate, that a publisher selected a fair list, or that a transaction obeys a blockchain’s consensus rules.

Where it is used

Bitcoin’s Simplified Payment Verification (SPV) model uses a transaction’s Merkle branch and the root in a block header to show inclusion. The client also needs to assess the header chain and accumulated proof of work. Inclusion alone does not prove that every transaction in the block is valid; Bitcoin’s developer guide explicitly distinguishes these claims.

Airdrop contracts can store a root for an eligibility list and ask each claimant to submit a proof. Bridges and rollups can also use proofs, but their security depends on how the destination accepts the root, verifies finality, handles challenges, and encodes the message. The phrase “Merkle proof” by itself does not make a bridge trustless.

Limits and common mistakes

A proof can be valid for the wrong root, the wrong leaf encoding, or a different tree specification. Implementations must agree on hashing, leaf and internal-node encodings, ordering, and odd-leaf handling. Membership proofs are also different from non-membership proofs, which need additional structure or rules.

Do not confuse proof of inclusion with proof of transaction validity or finality. For an SPV client, the proof is one input alongside the chain of headers; a full node independently validates blocks and transactions.

Social Media Sentiment

A Reddit question about Ethereum light clients asks how proof branches connect to a trusted state root. It illustrates why people often mix up receiving a proof, verifying inclusion, and validating the underlying chain; the technical claims here follow the protocol documentation. Reddit discussion. This is one public thread, not a representative survey.

Last updated: 2026-10

Related Terms

See Also

Sources