A Merkle tree proves that a transaction is included by letting a verifier recompute a published root hash from that transaction and a short set of sibling hashes.
When checking one transaction, there are two choices: download and inspect the entire block, or ask for a compact proof. The proof is the useful choice when bandwidth, storage, or computation is limited.
- 1 leaf: the transaction, represented by its hash.
- log₂(n) sibling hashes: the neighboring hashes needed in a balanced binary tree containing n transactions.
- 1 root hash: the compact summary committed to by the block.
- 1 verification: recompute the path and compare the result with the trusted root.
For example, a block with 1,048,576 transactions needs about 20 sibling hashes for one inclusion proof because 2²⁰ equals 1,048,576. In Bitcoin, each hash is 32 bytes, so the hash portion of that idealized proof is roughly 640 bytes, before encoding and other metadata.
What the verifier actually checks
The verifier checks that a particular transaction was one of the leaves used to create the block’s root hash.
A cryptographic hash is a fixed-length fingerprint calculated from data. Changing the transaction changes its hash, and changing any hash higher in the tree changes the root. That makes the root a compact commitment to the complete set of leaves.
- The verifier hashes the transaction using the chain’s prescribed hashing and serialization rules.
- The proof supplies the neighboring hash at the transaction’s level, plus the information needed to determine whether the transaction hash belongs on the left or right.
- The verifier hashes those two values together to produce the parent hash.
- The process repeats until one value remains: the calculated root.
- The calculated root is compared with the root committed to by the block.
If the values match, the transaction is included in that committed tree. A dishonest node cannot replace the transaction without changing the path and eventually producing a different root, assuming the hash function and tree construction are secure.
The proof is therefore not a second copy of the block. It is the minimum path information required to connect one leaf to the root. The transaction itself is necessary because the verifier must know what data was supposedly included; the sibling hashes supply the missing branches.
Bitcoin and Ethereum use different trees
Bitcoin uses the familiar binary Merkle tree, while Ethereum uses Merkle-Patricia tries for its transaction and receipt commitments.
Bitcoin places transaction identifiers into a binary tree, hashes pairs of neighboring values, and repeats the process until it reaches the Merkle root in the block header. If a level has an odd number of values, the final value is paired with a copy of itself. A Simplified Payment Verification client can then download block headers and request only the intermediate hashes needed to check one transaction.
Ethereum’s transaction commitment is more structured. Each block has a transaction trie whose key is the transaction’s position in the block, and the block header records the resulting transactionsRoot. Ethereum also records a separate receiptsRoot. A transaction proof answers “was this transaction included?” A receipt proof can answer questions about its execution result and emitted logs, subject to the format and proof system being used.
That distinction matters because inclusion is not the same as success. A transaction may be included even when its execution reverted. To prove that an application event occurred, a verifier normally needs the receipt rather than only the original transaction.
What the proof makes possible
Merkle proofs make lightweight verification practical: a small client can check selected blockchain data without storing every transaction or the entire current state.
Consider a cross-chain deposit. A destination system may receive a claim that a source-chain transaction emitted a particular deposit event. Instead of trusting the node that reports the event, the verifier can check the event-bearing receipt against the source block’s receipt root. A system involving Manta Atlantic and the Polkadot Network still needs its own rules for headers, finality, and message validity, but the Merkle path supplies the compact inclusion check.
This is also why a proof around a Manta Bridge transaction cannot be treated as the whole bridge protocol. The proof establishes a fact about committed source-chain data; the surrounding system decides which block is authoritative, how much finality is required, whether the message has already been processed, and what action follows.
The same boundary applies to a liquidity protocol such as Meson Finance. A Merkle proof can authenticate a recorded transaction or event, but it does not itself move funds, prevent replay, or establish that a remote chain has accepted the corresponding action.
What a Merkle proof does not prove
A valid inclusion proof proves membership in a particular committed tree, not the entire meaning or safety of the transaction.
- It does not prove that the block is final unless the verifier also checks the chain’s consensus or finality evidence.
- It does not prove that the transaction succeeded; that may require a receipt or state proof.
- It does not prove that a reported transaction is the only matching transaction.
- It does not prove that a destination application should release assets or accept a message.
Takeaways
- A Merkle root is a compact commitment to many transactions.
- An inclusion proof contains one transaction and the neighboring hashes along its path.
- Verification costs roughly logarithmic space in a binary tree, rather than the size of the whole block.
- Bitcoin uses a binary transaction Merkle tree; Ethereum uses structured tries for transactions and receipts.
- Inclusion, execution success, finality, and cross-chain authorization are separate claims.