What is Merkle tree?

A structure that hashes transactions in pairs, then hashes those hashes, until a single root hash summarizes the whole block.

The structure predates Bitcoin and appears wherever a large set of data needs a short fingerprint that can be checked in pieces. In crypto you meet it in three places: inside every block header, inside proof-of-reserves reports where an exchange publishes a root and lets each customer check their own balance, and inside airdrop claim contracts that verify eligibility without storing a list of addresses on chain.

The property that does all the work is that you do not need the whole set to check one member. That is what makes lightweight verification possible on a phone (source: the Bitcoin white paper, section 7).

How it works

1. Hash each item, giving one leaf per transaction.
2. Hash each adjacent pair of leaves together, producing the next layer up. Where a layer has an odd count, the last entry is duplicated or carried, depending on the specification.
3. Repeat until one hash remains. That is the Merkle root.
4. The block header stores only the root, not the transactions.

To prove one transaction is included, you supply the transaction plus the sibling hash at each layer, which is roughly the base-2 logarithm of the number of transactions. A block with 4,096 transactions needs about 12 hashes rather than all 4,096.

Because every layer feeds the one above, changing any single transaction changes its leaf, then every hash on the path, then the root, then the block header, and therefore invalidates the block. That is the tamper-evidence property.

The same structure has a limit worth stating: it proves inclusion, not exclusion or completeness. A Merkle proof shows that your item is in the set. It does not show that the set contains nothing else, which is why proof-of-reserves needs a separate liabilities construction to be meaningful.

Example

Illustrative arithmetic. A block holds 1,024 transactions. Verifying that yours is one of them by downloading everything means fetching all 1,024 records. Verifying by Merkle proof means fetching your transaction plus 10 sibling hashes, because 2 to the power of 10 is 1,024.

At 32 bytes per hash, that path is 320 bytes. The saving is what lets a light client confirm a payment against block headers alone rather than storing the chain.

Why it matters when you buy

This is the machinery behind the proof-of-reserves attestations exchanges publish, and it is why you can personally check that your balance was included in one rather than taking the total on trust. Whether a venue publishes such a proof is one of the security facts recorded on the profiles at the exchange directory, and our guide at Proof of reserves explains what such a report does and does not show.

Related terms

• hash — the one-way function underneath
• proof of reserves — an exchange publishing a root
• proof of liabilities — the half that completes it
• light client — verification without the full chain
• block — where the root is stored
• attestation — the auditor's statement around it

Questions

Do I need to understand this to buy crypto?

No, but it is the reason a proof-of-reserves page invites you to check your own balance. If you ever use that feature, this is what it is doing.

Does the Merkle root prove the transactions are valid?

No. It proves they have not been altered since the block was built. Validity is checked separately by the rules each node applies.

Is the same structure used outside blockchains?

Yes. Version control systems, file distribution protocols, and certificate transparency logs all use Merkle trees for the same reason: verifying a piece without downloading the whole.