Block Receipt Root
Pronunciation: BLOK ruh-SEET root
Also known as: Receipts Root
Definition
A block receipt root is a cryptographic root that commits to the ordered set of transaction receipts produced by executing a block. Receipts can contain status, cumulative resource use, logs, and other protocol-defined results. The root lets verifiers check inclusion proofs against the block header.
Overview
Meaning and scope
A block receipt root is a cryptographic root that commits to the ordered set of transaction receipts produced by executing a block. Receipts can contain status, cumulative resource use, logs, and other protocol-defined results. The root lets verifiers check inclusion proofs against the block header.
Mechanism and operation
After transactions execute, many smart-contract blockchains create one receipt per transaction. Ethereum receipts include execution status or historical post-state information, cumulative gas used, logs bloom, and event logs. The receipts are encoded and placed into a commitment structure whose root is recorded in the block header. Changing a receipt, its encoding, or its position changes the resulting root. The receipt root supports efficient verification that a particular receipt belongs to a block without downloading every receipt. This is useful for light clients, bridges, and indexers that need evidence of an event or execution result.
Practical payment example
An Ethereum auditor checks that the receipts trie commitment matches the header before relying on transaction execution outcomes.
Operational checks
A receipt is not a complete description of all state changes. Event logs are produced by contract code and can be missing, misleading, or differently structured across versions. Internal balance changes may require tracing or direct state queries. The Block State Root commits to resulting state, while the Block Transaction Root commits to submitted transactions.
Distinctions and limits
The proof is only meaningful when anchored to the correct Block ID and when that block is canonical and sufficiently finalized for the application’s risk. These roots answer different verification questions and cannot be substituted for one another. Payment systems that rely on token-transfer events should verify the emitting contract, topics, data encoding, transaction status, amount, recipient, and chain.
Related reading
Related definitions: Block ID, Block State Root.
Example
An Ethereum auditor checks that the receipts trie commitment matches the header before relying on transaction execution outcomes.
Comparison
The proof is only meaningful when anchored to the correct Block ID and when that block is canonical and sufficiently finalized for the application’s risk. Event logs are produced by contract code and can be missing, misleading, or differently structured across versions.
Key Takeaway
The block receipt root authenticates ordered execution receipts, but settlement still requires correct decoding and a canonical, finalized block.
Sources
- Ethereum Execution Specifications: Block and Header Fields — Ethereum Foundation (2026-08-02)
- Ethereum JSON-RPC API — Ethereum Foundation (2026-08-02)
- Ethereum Transactions — Ethereum Foundation (2026-08-02)