What is a Transaction Receipt?

definition

BLOCKCHAIN DATA STRUCTURE

A transaction receipt is an immutable, cryptographically verifiable record generated by a blockchain network to confirm the final outcome of a submitted transaction.

A transaction receipt is a data object generated by an Ethereum Virtual Machine (EVM)-compatible blockchain after a transaction has been executed and included in a block. It serves as the definitive proof of the transaction's outcome, containing critical metadata not found in the transaction itself, such as the cumulative gas used, the success or failure status (represented by a status field of 1 or 0), and the logs emitted by any smart contracts involved. This receipt is cryptographically linked to the transaction via its hash, ensuring its data is tamper-proof and permanently recorded on the ledger.

The primary components of a standard receipt include the transaction hash, the block number where it was mined, the gas used (and the effective gas price), the originating from and destination to addresses, and any logs. These logs are particularly important for decentralized applications (dApps), as they are the primary mechanism for smart contracts to communicate state changes or events—like a token transfer or a governance vote—back to off-chain applications. Developers query these logs to update user interfaces and backend databases.

For developers, the receipt is essential for debugging and user feedback. A failed transaction, indicated by a status: 0, will still generate a receipt, allowing analysis of the revert reason or the point of failure via the gas used. Furthermore, the receipt enables the calculation of the total transaction fee (gas used * gas price). Unlike the pending transaction, the receipt provides finality, confirming that the network has reached consensus on the operation's result and its side effects on the blockchain's global state.

key-features

BLOCKCHAIN DATA STRUCTURE

Key Features of a Transaction Receipt

A transaction receipt is an immutable data structure generated by an Ethereum Virtual Machine (EVM) client after a transaction is executed and included in a block. It provides cryptographic proof of the transaction's outcome and contains essential state changes.

Transaction Status

The status field is a single bit (0 or 1) that indicates whether the transaction execution succeeded (1) or failed (0) at the EVM level. A status of 0 means the transaction was reverted, often due to an error like insufficient gas or a failed condition check, but gas was still consumed for the work performed up to the point of failure.

Cumulative Gas Used

This field shows the total amount of gas consumed by all transactions in the block up to and including this specific transaction. It is used to calculate the actual gas used for this transaction alone: gasUsed = cumulativeGasUsed[current] - cumulativeGasUsed[previous]. This value, multiplied by the effective gas price, determines the total transaction fee paid to the miner/validator.

Contract Address (for Creations)

For transactions that deploy a new smart contract (where to is null), this field contains the newly created contract's 20-byte address. The address is deterministically derived from the sender's address and their nonce (Keccak256(RLP_encode(sender, nonce))[12:]). For all other transaction types, this field is null.

Logs Bloom Filter

A 256-byte Bloom filter that provides a space-efficient, probabilistic data structure for quickly checking if a specific log topic or address was emitted by this transaction. It allows light clients and indexers to efficiently filter for relevant events without downloading all log data. A match in the Bloom filter suggests the log may be present; a non-match guarantees it is not.

Event Logs

An array of log entries emitted by the transaction's execution, primarily from the LOG opcodes within smart contracts. Each log contains:

The address of the contract that emitted it.
An array of topics (indexed event parameters).
Additional non-indexed data (the data field). These logs are the foundation for off-chain event listening and indexing by dApp frontends and blockchain explorers.

Post-Transaction State Root

The stateRoot is the root hash of the Merkle Patricia Trie representing the entire world state (account balances, storage, code, nonces) after this transaction was executed. This field was used in pre-Byzantium Ethereum but is now largely deprecated in favor of the simpler status field. It remains a critical part of the receipt's cryptographic commitment within the block header.

how-it-works

BLOCKCHAIN MECHANICS

How a Transaction Receipt is Generated

A transaction receipt is a cryptographically verifiable record generated by a blockchain node to confirm the final outcome of a submitted transaction.

A transaction receipt is generated by an Ethereum Virtual Machine (EVM)-compatible blockchain node immediately after a transaction is executed within a block. It is a structured data object containing critical post-execution state, including the transaction's success or failure status (indicated by a status field of 1 or 0), the total amount of gas used, the cumulative gas used up to that point in the block, the logs emitted by any smart contracts, and the contract address for newly deployed contracts. This receipt is stored in a Merkle Patricia Trie alongside the block header, with its root hash (receiptsRoot) serving as a compact cryptographic commitment to all receipts in that block.

The generation process is deterministic and integral to state transition. When a validator node processes a block, it sequentially executes each transaction. For each one, the EVM tracks gas consumption, execution output, and any events logged via the LOG opcodes. Upon completion, the node packages this data into the receipt's fields. The logsBloom filter, a space-efficient data structure, is also created by combining all log entries from the receipt; it allows for efficient filtering of events across the blockchain without needing to inspect every individual log.

From a developer's perspective, the receipt is the primary source of truth for an application after submitting a transaction. Tools like web3.js or ethers.js query a node's RPC endpoint (e.g., eth_getTransactionReceipt) to retrieve this data. Analysing the receipt is essential for confirming a token transfer succeeded, a smart contract function call behaved as expected, or a new contract was deployed. The immutable linkage of the receipt to the block via the Merkle root enables light clients to efficiently and trustlessly verify specific transaction outcomes without downloading the entire blockchain.

core-components

TRANSACTION RECEIPT

Core Components & Data Fields

A transaction receipt is a cryptographically verifiable record generated by an Ethereum Virtual Machine (EVM) blockchain after a transaction is executed and included in a block. It contains the final outcome and cumulative effects of the transaction.

Status & Outcome

The status field is a boolean (0 or 1) indicating if the transaction was successful (1) or reverted (0). The cumulativeGasUsed shows the total gas consumed, while gasUsed for the specific transaction is calculated from this and the previous receipt. This is the definitive proof of execution.

Logs & Event Emissions

The logs array contains all the event logs emitted by smart contracts during the transaction. Each log includes:

The contract address that emitted it.
Topics: Indexed event parameters and the event signature hash.
Data: Non-indexed event parameters. This is the primary way for dApps to query and react to on-chain state changes.

Bloom Filter

A logsBloom is a 256-byte data structure that acts as a probabilistic filter for the transaction's logs. It enables light clients and network nodes to efficiently check for the possible presence of specific logs without downloading the full log data, optimizing data retrieval.

Block & Transaction Identifiers

The receipt ties the transaction result to its place in the blockchain. Key identifiers include:

blockHash & blockNumber: The block containing the transaction.
transactionHash: A unique identifier for the transaction itself.
transactionIndex: The position of the transaction within the block.

Contract Creation Receipt

For transactions that create a new smart contract (with a to address of null or 0x0), the receipt contains a critical field: contractAddress. This field holds the address of the newly deployed contract, which is deterministically calculated from the sender's address and their nonce.

Root Hashes (Pre-Byzantium)

In Ethereum's history (before the Byzantium upgrade), receipts used a rootHash (or postTransactionState). This was a Merkle-Patricia Trie root representing the global state after the transaction. Post-Byzantium, the status field replaced this for simpler and more explicit success/failure signaling.

event-logs-deep-dive

GLOSSARY SECTION

Event Logs: The Application Layer Interface

This section details the Transaction Receipt, the cryptographically signed data structure that provides the authoritative record of a transaction's execution outcome on the Ethereum Virtual Machine (EVM).

A Transaction Receipt is a data structure generated by an Ethereum client after a transaction has been executed and included in a block, serving as the definitive, machine-readable proof of the transaction's outcome. It contains critical post-execution state, including the status (success or failure), the total gasUsed, a cumulative logsBloom filter for efficient log queries, and an array of logs emitted by smart contracts during execution. This receipt is stored on-chain and is essential for applications to verify the effects of a transaction beyond its mere inclusion.

The receipt's logs are its most application-critical component, acting as the primary interface for decentralized applications (dApps). When a smart contract executes its emit statement, it creates a log entry containing the emitter's address, up to four topics (indexed parameters for efficient filtering), and arbitrary data. These logs are written into the receipt and are the only way for off-chain systems—like front-ends, indexers, and oracles—to reliably observe and react to on-chain state changes in a decentralized manner.

For developers, interacting with receipts and logs is fundamental. Tools like web3.js and ethers.js provide methods (e.g., getTransactionReceipt) to fetch this data. The logsBloom filter enables light clients and indexers to quickly check for the potential presence of specific logs without scanning all data. Furthermore, standardized patterns like EIP-712 for typed structured data hashing and the widespread use of event signatures (the hash of the event name and parameter types) ensure that applications can consistently decode and interpret log data across the ecosystem.

KEY DIFFERENCES

Transaction vs. Transaction Receipt

A comparison of the core data objects representing a blockchain transaction request and its on-chain execution result.

Feature	Transaction	Transaction Receipt
Core Purpose	A request to execute a state-changing operation	A record of the execution result of a transaction
Created By	User or smart contract (externally owned account)	The blockchain network (validator/miner)
Data Structure	Signed message with 'to', 'value', 'data', 'gas'	Logs and metadata like 'status', 'gasUsed', 'blockHash'
Contains Execution Result
Contains Event Logs
State Before Inclusion	Pending / in mempool	Confirmed / in a block
Primary Use Case	Broadcasting an operation to the network	Verifying the outcome and state changes of an operation
Unique Identifier	Transaction Hash (txHash)	Derived from the transaction hash; often the same identifier

developer-use-cases

TRANSACTION RECEIPT

Developer Use Cases & Applications

A transaction receipt is a cryptographically verifiable record of the final outcome of a blockchain transaction. It is generated after a transaction is executed and included in a block, providing developers with essential data for building reliable applications.

Event Logging & DApp State

Receipts contain event logs emitted by smart contracts, which are the primary mechanism for decentralized applications (DApps) to track state changes. Frontends and indexers subscribe to these logs to update user interfaces, trigger notifications, and synchronize off-chain databases.

Example: An NFT marketplace DApp listens for a Transfer event log to update ownership records and UI elements in real-time when a sale occurs.

Transaction Verification & Confirmation

Developers use the receipt's status flag (success 1 or failure 0) and block number to definitively confirm a transaction's outcome. This is critical for building reliable payment processors, escrow services, and any application requiring guaranteed execution.

Key Fields: The status field indicates if the transaction succeeded (e.g., a token transfer completed). The blockHash and blockNumber provide immutable proof of inclusion in the canonical chain.

Gas Usage Analysis & Optimization

The receipt provides detailed gas consumption metrics, including gasUsed and the effectiveGasPrice. Developers analyze this data to:

Profile contract efficiency and identify costly functions.
Estimate real user costs more accurately than pre-execution estimates.
Set optimal gas limits in transaction builders to prevent out-of-gas errors while minimizing fees.

Building Indexers & Explorers

Blockchain explorers and custom indexers are built by systematically querying and parsing transaction receipts. They aggregate data from the logsBloom filter, contract addresses, and event topics to create searchable databases of transaction history, token transfers, and smart contract interactions.

Cross-Chain & Layer 2 Bridging

In bridging protocols, transaction receipts from one chain serve as cryptographic proof for actions on another. Light clients and relayers verify the Merkle-Patricia proof included in a receipt (via transactionIndex, logsBloom, and root) to validate that an event occurred on the source chain before minting assets or executing commands on the destination chain.

Debugging Failed Transactions

When a transaction fails (status 0), the receipt is the first point of investigation. While it doesn't contain revert reasons directly, the gasUsed and event logs up to the point of failure provide clues. Developers often cross-reference this with the transaction's input data and contract state to diagnose issues like failed assertions, insufficient funds, or violated access controls.

TRANSACTION RECEIPTS

Common Misconceptions

Transaction receipts are fundamental data structures in blockchain systems, yet their purpose and contents are often misunderstood. This section clarifies frequent points of confusion regarding what receipts confirm, what they contain, and their role in application development.

No, a transaction receipt does not guarantee the logical success of the transaction's intended operation. A receipt is generated for every transaction that is included in a block, regardless of its outcome. The key indicator is the status field: a value of 1 indicates the EVM execution completed without a revert, while 0 indicates it failed. A receipt confirms inclusion and provides execution metadata, but developers must check the status and potentially parse revert reason data from the transaction trace to determine functional success.

ecosystem-usage

IMPLEMENTATION DETAILS

Ecosystem Usage & Chain Variations

While the core concept of a transaction receipt is universal, its structure, data fields, and accessibility methods vary significantly between different blockchain networks and clients.

Ethereum (EVM) Standard

The Ethereum Yellow Paper formally defines the receipt structure. Key fields include:

status: A 0 (failure) or 1 (success) code indicating if the transaction's top-level execution succeeded.
cumulativeGasUsed: Total gas used in the block up to and including this transaction.
logsBloom: A 256-byte Bloom filter for efficiently querying logs from this transaction.
logs: An array of log objects emitted by smart contracts during execution, containing the contract address, topics, and data.

Access via eth_getTransactionReceipt JSON-RPC call.

Receipts vs. Transaction Objects

It is critical to distinguish a transaction receipt from the transaction itself.

Transaction Object: Contains the data sent to the network (from, to, value, data, gasPrice, etc.). It represents the intent.

Transaction Receipt: Contains the data generated by the network as a result of execution. It represents the outcome.

A receipt is only generated after a transaction is mined into a block. Key outcome data like gasUsed, status, and contract logs are only found in the receipt.

Layer 2 & Rollup Variations

Optimistic and Zero-Knowledge Rollups modify receipt handling for data efficiency and finality.

Optimistic Rollups (e.g., Arbitrum, Optimism): Provide interim receipts upon submission to the sequencer, but finality depends on the challenge period. Receipts may reference L1 block numbers for verification.
ZK-Rollups (e.g., zkSync, StarkNet): Provide near-instant finality. Receipts are generated after a validity proof is submitted to L1. The receipt may include a proof of inclusion in a ZK-proof batch.
Data Availability: Receipt logs may be stored on the L1 for verifiability, affecting query patterns.

Non-EVM Chains (Solana, Cosmos)

Non-EVM ecosystems use different terminology and structures for execution results.

Solana: Uses transaction metadata or the result from getTransaction. Key fields include meta object containing err (null if successful), fee, preBalances, postBalances, and an array of innerInstructions.
Cosmos SDK: Uses TxResponse. It includes code (0 for success), gas_used, gas_wanted, logs (containing message type and events), and the raw tx bytes.
Events vs. Logs: Cosmos uses events with typed attributes, analogous to Ethereum's logs but with a different query API.

Indexing & Querying Receipts

Raw receipts from RPC nodes are ephemeral and inefficient for historical queries. Dedicated indexing solutions are standard.

The Graph: Subgraphs index transaction receipts, specifically their event logs, into queryable entities based on defined schemas.
Alchemy Enhanced APIs: Provide methods like alchemy_getTransactionReceipts that return enriched data and internal transactions.
Block Explorers (Etherscan): Parse and display receipt data (status, gas, events) via their databases, not live RPC calls.
Self-Hosted Indexers: Tools like TrueBlocks or custom Ethereum ETL pipelines extract and store receipt data for analytical queries.

Gas Calculation & Optimization

The receipt is the definitive source for analyzing transaction cost efficiency.

Actual Cost: gasUsed * effectiveGasPrice = total fee paid (in wei). The receipt provides the final gasUsed.
Gas Estimation Accuracy: Comparing gasUsed to the gasLimit (from the transaction) shows estimation efficiency. A large gap indicates wasted gas or risk of out-of-gas errors.
Revert Analysis: A status: 0 receipt with high gasUsed often indicates a complex transaction that reverted late in execution, a key data point for debugging.
Optimization Target: Developers analyze receipts from mainnet deployments to fine-tune gas costs by reviewing opcode execution patterns reflected in the final gas used.

TRANSACTION RECEIPT

Frequently Asked Questions (FAQ)

Transaction receipts are the definitive proof of a transaction's execution on a blockchain. This FAQ addresses common questions about their structure, purpose, and how to interpret their data.

A transaction receipt is a cryptographically verifiable data structure generated by an Ethereum Virtual Machine (EVM) blockchain after a transaction is executed and included in a block. It contains the final outcome of the transaction, distinct from the transaction's input data. Key fields include:

status: A boolean (1 for success, 0 for failure) indicating if the transaction executed without reverting.
cumulativeGasUsed: The total gas used by all transactions in the block up to and including this one.
logsBloom: A space-efficient data structure (Bloom filter) for quickly checking if specific log events were emitted.
logs: An array of event logs generated by smart contracts during execution, which are crucial for off-chain applications.
transactionHash: A reference to the original transaction that spawned this receipt.

Transaction Receipt