What is a Receipt Root?

definition

BLOCKCHAIN DATA STRUCTURE

A cryptographic fingerprint summarizing all transaction outcomes within a block.

A Receipt Root (or receiptsRoot) is a Merkle root hash stored in a blockchain block's header, serving as a cryptographic commitment to the set of all transaction receipts generated by that block. Each receipt contains crucial post-execution data from a transaction, such as its status (success/failure), cumulative gas used, and logs emitted by smart contracts. By hashing these receipts into a single, compact 32-byte value, the Receipt Root provides a tamper-evident summary, allowing network participants to efficiently verify that the reported outcomes of a block's transactions are authentic and have not been altered.

The primary function of the Receipt Root is to enable light clients and external systems to perform state verification without downloading the entire blockchain. For example, a decentralized application (dApp) can use a Merkle proof to cryptographically demonstrate that a specific transaction log—proving an NFT mint or token transfer—is legitimately included in a block whose header is confirmed by the network's consensus. This mechanism is fundamental to trust-minimized bridges and oracles, which rely on verified on-chain events. In the Ethereum protocol, this structure is a core component of the block's triple-Merkle architecture alongside the stateRoot and transactionsRoot.

From a technical perspective, the Receipt Root is computed by arranging all block receipts in a Merkle Patricia Trie (MPT). Each receipt is serialized using Recursive Length Prefix (RLP) encoding and stored as a leaf node in the trie. The final root hash is derived from this structured data. Any change to a single receipt's data—like altering a log—would produce a completely different root, immediately signaling inconsistency with the value committed in the block header. This property is essential for ensuring the integrity and finality of execution results across the decentralized network.

The concept of a receipt root is not exclusive to Ethereum; it is a common pattern in EVM-compatible chains and other smart contract platforms that require verifiable execution traces. Its existence is a key differentiator from simpler blockchain designs like Bitcoin, which primarily track asset transfers. For developers, interacting with receipt data via roots is central to event indexing, analytics, and building layer 2 solutions. Understanding this component is critical for auditing transaction outcomes and designing systems that depend on proven, on-chain state transitions.

how-it-works

BLOCKCHAIN DATA STRUCTURE

How the Receipt Root is Constructed

A technical breakdown of the cryptographic process that creates a compact, tamper-proof summary of all transaction outcomes in a block.

The receipt root is a Merkle root hash that cryptographically commits to the set of all transaction receipts generated by the execution of a block's transactions. Each transaction receipt is a structured data object containing key execution results, such as the status (success/failure), cumulative gas used, and logs emitted by smart contracts. To construct the root, the protocol first serializes each receipt into a byte array using a Recursive Length Prefix (RLP) encoding scheme, which ensures a deterministic and compact representation.

These serialized receipts are then organized into a Merkle Patricia Trie (MPT), a specialized data structure combining a Merkle tree and a Patricia trie. In this trie, each receipt is stored as a key-value pair, where the key is the index of the transaction within the block. The MPT is hashed recursively: leaf nodes contain the hashed receipt data, branch nodes combine the hashes of their children, and the final, top-level hash of the trie's root node becomes the receiptsRoot field in the block header. This process ensures that any alteration to a single receipt would invalidate the root.

The construction is integral to Ethereum's consensus and light client verification. By including the receiptsRoot in the cryptographically signed block header, the network achieves state consistency—any node can independently execute the block's transactions, generate the receipts, construct the trie, and verify that the computed root matches the one in the header. This allows light clients to efficiently verify the existence and content of specific transaction outcomes by requesting a Merkle proof (a path of hashes) from a full node, without needing to download all receipt data.

key-features

BLOCKCHAIN DATA INTEGRITY

Key Features of the Receipt Root

The Receipt Root is a cryptographic commitment to all transaction outcomes within an Ethereum block, enabling efficient and trustless verification of state changes.

01

Cryptographic Commitment

The Receipt Root is a Merkle Patricia Trie root hash that cryptographically commits to all transaction receipts in a block. This single 32-byte hash serves as a tamper-proof summary, allowing any node to verify that a specific receipt is part of the block without needing the entire dataset. It is derived by hashing the root of the trie where each leaf node is a RLP-encoded transaction receipt.

02

Verification of State Changes

Receipts contain logs emitted by smart contracts and a status code indicating success (1) or failure (0). The Receipt Root enables light clients and Layer 2 networks to efficiently prove that a specific state-changing event (like a token transfer) occurred. By providing a Merkle proof from a receipt's data to the root, one can cryptographically verify the event's inclusion and outcome without executing the transaction.

03

Core Component of Block Header

The Receipt Root is one of three critical trie roots in an Ethereum block header, alongside the State Root and Transaction Root. This structure, known as the Ethereum Merkle Patricia Trie, allows the header (just the roots) to act as a secure commitment to the entire block's state, transactions, and outcomes. Any alteration to a receipt would invalidate the Receipt Root, breaking consensus.

04

Enabler for Light Clients & L2s

The existence of the Receipt Root is fundamental for light client protocols (like Ethereum's light sync) and Layer 2 scaling solutions. Rollups, for example, post transaction data and the resulting Receipt Root to Ethereum as a calldata commitment. This allows anyone to verify the correctness of off-chain execution by challenging the posted root if it doesn't match locally computed outcomes.

05

Post-Execution Artifact

Unlike the Transaction Root, which commits to the inputs of execution, the Receipt Root commits to the outputs. It is calculated after all transactions in the block have been executed. This makes it a verifiable record of the block's effects, including:

Cumulative gas used per transaction.
Bloom filters for efficient log searching.
Contract event logs (indexed and non-indexed data).

06

Integrity for Data Availability

In data availability sampling and fraud-proof systems, the Receipt Root is a key data point. Protocols can require that the full set of receipts corresponding to a published root is available for sampling. If the data is withheld, the root cannot be verified, signaling a fault. This mechanism protects against data withholding attacks where a node publishes a valid root but hides the data needed to prove fraud.

COMPARISON

Receipt Root vs. Other Block Header Roots

A comparison of the cryptographic roots within a block header, detailing their purpose and the data they commit to.

Root	Purpose	Data Committed	Verifies	Ethereum Example
Receipt Root	Commit to transaction outcomes	All transaction receipts in the block	Post-execution state changes, logs, gas used, success status	0x... (Keccak-256 hash of receipts trie root)
State Root	Commit to global state	The entire world state (account balances, code, storage, nonce) after applying the block	The canonical state at a specific block height	0x... (Keccak-256 hash of state trie root)
Transactions Root	Commit to ordered transactions	All transactions in the block	The exact list and order of transactions to be executed	0x... (Keccak-256 hash of transactions trie root)
Parent Hash	Establish chain lineage	The hash of the previous block's header	The previous block's integrity and the chain's continuity	0x... (Keccak-256 hash of parent header)
Uncle Hash	Commit to uncle blocks	Headers of uncle (ommer) blocks included in the current block	The validity of included uncle blocks for PoW security	0x... (Keccak-256 hash of uncle headers list)

ecosystem-usage

RECEIPT ROOT

Ecosystem Usage and Importance

The Receipt Root is a critical cryptographic commitment within a blockchain block header, serving as a verifiable summary of all transaction outcomes.

The Receipt Root (or receiptsRoot) is a 256-bit hash stored in a block header that cryptographically commits to the set of all transaction receipts generated by executing the block's transactions. It is a core component of execution layer integrity, allowing any node to efficiently verify that the outcomes of a block's state transitions—such as gas used, success status, and emitted logs—are consistent and have not been altered after the fact. This creates a tamper-evident record of what happened as a result of the transactions, separate from the resulting state itself.

Its primary importance lies in enabling light clients and external systems to trustlessly verify specific transaction outcomes without downloading the entire blockchain or executing all transactions themselves. By providing a Merkle proof linking a single transaction receipt to the Receipt Root in a validated block header, one can cryptographically prove the exact result of that transaction. This capability is foundational for bridges, oracles, and indexers that need reliable, on-chain proof of events like token transfers or smart contract executions to trigger actions on other chains or in off-chain databases.

In the Ethereum ecosystem, the Receipt Root is part of a triad of roots in the block header, alongside the stateRoot and transactionsRoot. While the transactionsRoot proves the transactions included, and the stateRoot proves the resulting world state, the receiptsRoot specifically proves the log of execution. This structure is essential for Ethereum's fraud proofs in rollups and for the Ethereum JSON-RPC method eth_getTransactionReceipt, which clients rely on to query transaction outcomes. Changes to receipt structure, like those proposed in EIPs, directly affect this root.

For developers and analysts, the Receipt Root enables powerful on-chain data verification. A common pattern involves storing the root of a Merkle tree of off-chain data (like airdrop allowances or survey results) within a log in a transaction receipt. The subsequent Receipt Root then becomes an immutable, on-chain anchor for that entire dataset. Anyone can then prove their specific piece of data is part of the original set by providing a Merkle path to this anchored root, a technique widely used for merkle drops and proof-of-inclusion systems without bloating the blockchain state.

technical-components

RECEIPT ROOT

Technical Components of a Transaction Receipt

The receipt root is a cryptographic fingerprint within a block header that commits to the state of all transaction outcomes, enabling efficient and secure verification of execution results.

01

Core Definition

The receipt root is a Merkle-Patricia Trie root hash stored in a block header, cryptographically committing to the entire set of transaction receipts for that block. It serves as a tamper-proof summary of all execution outcomes, including logs, gas used, and status (success/failure).

02

Structure of a Receipt

Each individual transaction receipt contains data generated during execution:

Status: A boolean (1 for success, 0 for failure).
Cumulative Gas Used: Total gas consumed up to and including this transaction.
Logs Bloom: A compressed, filterable data structure of event logs.
Logs: An array of event logs emitted by smart contracts during execution.

03

Merkle Proofs & Light Clients

The receipt root enables light clients to verify specific transaction outcomes without downloading the entire chain. By providing a Merkle proof—a path from a specific receipt to the root—a client can cryptographically prove that a receipt with certain logs and status is legitimately included in the block.

04

Relationship to State & Transaction Roots

A block header contains three critical roots:

State Root: Hash of the world state (accounts, balances).
Transaction Root: Hash of the transactions list.
Receipt Root: Hash of the execution results. Together, they allow anyone to verify the block's integrity, from its proposed actions to their final outcomes.

05

EVM-Specific Implementation

In Ethereum, receipts are encoded as RLP (Recursive Length Prefix) serialized data and organized into a Merkle-Patricia Trie. The specific implementation is defined in the Ethereum Yellow Paper. The receipt root is a core component for log filtering in JSON-RPC APIs like eth_getLogs.

06

Verification & Bridge Security

Cross-chain bridges and layer-2 validity proofs heavily rely on the receipt root. Optimistic rollups publish transaction data and receipt roots on-chain, allowing for fraud proofs. Zero-knowledge rollups provide a validity proof that includes the correct computation of the new state and receipt roots.

RECEIPT ROOT

Technical Deep Dive

The receipt root is a cryptographic commitment to the outcomes of a block's transactions, serving as a core component of Ethereum's state verification. This section explores its structure, purpose, and role in light clients and cross-chain communication.

A receipt root is the Merkle-Patricia Trie root hash of all transaction receipts generated within a specific block. It is a cryptographic commitment that allows anyone to cryptographically verify the outcomes—such as success status, gas used, and emitted logs—of a block's transactions without needing the full dataset. This root is stored in the block header, providing a compact, tamper-proof summary of execution results.

Key components of a receipt include:

Status Code: A 0 (failure) or 1 (success) indicating if the transaction executed successfully.
Cumulative Gas Used: The total gas consumed by the transaction and all preceding ones in the block.
Logs Bloom: A space-efficient Bloom filter containing indexed topics and addresses from LOG opcodes.
Logs: An array of event logs emitted by smart contracts during execution.

RECEIPT ROOT

Common Misconceptions

The receipt root is a core component of Ethereum's block structure, but its purpose and relationship to transaction execution are often misunderstood. This section clarifies key technical details.

The receipt root is a Merkle Patricia Trie root hash stored in an Ethereum block header that cryptographically commits to the outcomes of all transactions in that block. It works by creating a receipt for each transaction, containing data like the cumulative gas used, logs, and status code (success/failure). These receipts are organized into a Merkle tree, and the root of that tree is the receipt root. This allows any node to efficiently and trustlessly verify that a specific transaction outcome is part of the canonical chain without needing the full block data.

RECEIPT ROOT

Frequently Asked Questions

The receipt root is a core component of a block header, providing cryptographic proof of the outcomes of all transactions within that block. These FAQs cover its function, importance, and relationship to other blockchain data structures.

A receipt root is a cryptographic hash stored in a block's header that serves as a compact, verifiable commitment to all the transaction receipts generated in that block. Each transaction receipt contains key outcome data like execution status, gas used, and logs emitted. The receipts are organized into a Merkle Patricia Trie, and the root hash of this trie is the receipt root. This allows any node to cryptographically prove that a specific transaction receipt, with its logs and results, is part of the canonical block without needing the entire dataset.

Receipt Root