Transaction receipt

A transaction receipt is the post-execution record of an EVM

transaction. The signed transaction tells the network what the sender

wants to do; the receipt records what actually happened when a validator

executed it. Receipts only exist on EVM and EVM-compatible chains; other

ecosystems have analogous structures with different names.

What a receipt contains

When you look up a transaction on the explorer that tx.taxi routes to for

ethereum or any other EVM chain, the page is mostly

populated from the receipt. Key fields:

• status: 0x1 (success) or 0x0 (reverted). A reverted transaction

is still on-chain, still consumes gas, and still

has a receipt; it just did not have its intended effect.

• gasUsed: the amount of gas actually consumed (the unused portion of

the gas limit is refunded).

• effectiveGasPrice: the gas price the network charged per unit, which

may be lower than the sender's maxFeePerGas after EIP-1559 logic.

• logs: an ordered list of events the

smart contract emitted during execution.

Each log carries an address (the emitter), up to four indexed topics,

and arbitrary data.

• logsBloom: a 256-byte bloom filter that lets clients quickly check

whether a block might contain logs relevant to them.

• contractAddress: present when the transaction deployed a new

contract. This is how tooling discovers the address of a newly deployed

contract.

• blockHash, blockNumber, transactionIndex: the location of

the transaction inside its block.

The receipt also includes the cumulative gas used up to and including

this transaction, which is what lets explorers show "gas used so far in

this block" on the receipt page.

Why receipts only appear after inclusion

A receipt is generated after a validator executes the transaction

inside a block. Until inclusion, only the signed transaction exists, and

that lives in the mempool. Explorers therefore show

a transaction as "pending" with no receipt fields filled in. Once the tx

is mined, the receipt populates the rest of the page.

This is why an explorer's "logs" or "events" tab is empty for pending

transactions. Logs are emitted during execution; without execution,

there is nothing to record.

Receipts on L2s

EVM rollups such as base, arbitrum one,

optimism, and scroll produce

receipts in the same format as Ethereum mainnet, with chain-specific

extensions:

• Optimistic rollups often include an l1GasUsed and an l1Fee field

reflecting the data-availability cost of posting the transaction to

Ethereum L1.

• ZK rollups may include proof-related metadata.

These extensions are added by the rollup's node implementation, so the

explorer surfaces them automatically.

Non-EVM analogues

Other chains record execution outcomes differently.

• solana returns transaction metadata containing

status, compute units consumed, and log messages.

• bitcoin and other UTXO chains have no per-transaction

receipt: outcome is implicit in the new state of the UTXO set.

• aptos and sui return transaction

results with gas used, events, and changed objects.

Common gotchas

• A reverted transaction has a receipt with status = 0x0 and any logs

emitted before the revert are not in the receipt; reverts undo logs.

• The contract address in a receipt is only present for deployments. For

ordinary calls the field is absent or null.

• Bloom filters are an optimisation, not a source of truth. Always verify

by checking the actual log entries.