Transaction Receipt

A transaction receipt is the definitive, immutable record of a transaction's execution on a blockchain, generated by a network node after a transaction has been included in a block and processed by the Ethereum Virtual Machine (EVM) or equivalent execution layer. Unlike the transaction itself, which contains the intent (e.g., sender, recipient, value, data), the receipt provides the outcome, including its success or failure status, the amount of gas used, and the logs generated by any smart contracts it interacted with. This data is crucial for applications to verify the results of on-chain operations.

The receipt contains several key fields essential for developers and network analysis. The status field (a 0 for failure or 1 for success) indicates whether the transaction's execution was reverted. The cumulativeGasUsed and gasUsed fields detail the computational resources consumed, which directly determines the transaction fee. Most importantly, the receipt contains logs, which are structured events emitted by smart contracts; these logs are the primary mechanism for decentralized applications (dApps) to track state changes and trigger off-chain actions via indexers or listeners.

From a technical perspective, transaction receipts are stored in a Merkle Patricia Trie alongside the block header, with the root hash of this receipts trie being included in the block header as the receiptsRoot. This cryptographic commitment allows for efficient and secure light client verification: one can prove that a specific transaction receipt is valid for a given block without needing to download the entire blockchain. This property is fundamental for scalability solutions, cross-chain bridges, and wallet balance checks that rely on Simplified Payment Verification (SPV).

For developers, accessing a transaction receipt is a fundamental API call. Using libraries like web3.js or ethers.js, one typically calls a method such as getTransactionReceipt after a transaction hash is known. The receipt's logs are parsed using the Application Binary Interface (ABI) of the relevant smart contract to decode the emitted event data into human-readable information. This process is the backbone of front-end updates, database indexing, and automated business logic in the Web3 stack.

Understanding the difference between a transaction and its receipt is critical. A pending transaction only has a hash; a confirmed transaction is included in a block; but only with the receipt can you definitively know its effect. Failed transactions still produce a receipt, which logs the revert reason and consumed gas (which is not refunded). This makes receipts indispensable for debugging, auditing, accounting, and building resilient applications that react accurately to on-chain state changes.

A transaction receipt is generated by an Ethereum Virtual Machine (EVM) node immediately after a transaction is executed within a block. This process begins once the block's transactions are sequentially processed. For each transaction, the EVM computes the new world state, consumes gas, and produces execution logs. The receipt is the formal record of this execution, containing critical data such as the cumulative gas used, the success status, and the bloom filter derived from any emitted event logs.

The generation process is deterministic and integral to consensus. Every validator node on the network independently executes the transaction and generates an identical receipt. This receipt is then hashed and included in the block's receipts root, which is part of the block header. This cryptographic commitment allows light clients to efficiently verify that a specific transaction was executed and its outcome, without needing the full transaction history or state data.

Key components stored in a standard receipt include the status code (1 for success, 0 for failure), the total gasUsed, the logsBloom filter for efficient log queries, and an array of logs themselves. For example, a failed transaction due to an out-of-gas error will have a status of 0 and a gasUsed value equal to the transaction's gas limit, permanently recorded on-chain. This immutable record is essential for dApps, indexers, and wallets to reliably determine finality and react to on-chain events.

A transaction receipt is a cryptographically verifiable data structure generated by a blockchain node after a transaction has been executed and included in a block. It serves as the authoritative proof of the transaction's outcome, detailing not just the event but its effects on the network's state. Unlike the transaction itself, which is a request, the receipt is the result, containing critical post-execution information such as the cumulative gas used, the set of logs emitted by smart contracts, and the final status (success or failure). This makes it an indispensable tool for developers and applications to verify and react to on-chain events.

The receipt's structure is standardized within protocols like Ethereum. Key fields include the status code (1 for success, 0 for failure), the cumulativeGasUsed, the contractAddress (for contract creation transactions), and a Bloom filter—a space-efficient data structure that allows for efficient filtering of the logs contained within. These logs are indexed events emitted by smart contracts using the LOG opcodes, which applications can later query to track specific occurrences like token transfers or governance votes without scanning the entire blockchain history.

For developers, the receipt is the primary interface for confirming transaction success and processing its side effects. Wallets and explorers use the status and gas fields to display transaction outcomes to users. More importantly, decentralized applications (dApps) rely on parsing the logs within a receipt to trigger off-chain logic, update user interfaces, or maintain indexed databases. The receipt's cryptographic link to the block header, via the transaction hash and Merkle proofs, allows any party to independently and trustlessly verify that a specific event occurred and was finalized on the chain.

Understanding the distinction between a transaction and its receipt is crucial. A transaction is a signed message proposing a state change, broadcast to the network. The receipt is the network's answer to that proposal. It is generated deterministically by every validating node during block processing, ensuring consensus on the outcome. This mechanism is fundamental to the blockchain's ability to provide a verifiable and tamper-proof history of execution, forming the bedrock for reliable smart contract interactions and audit trails.