eth_getTransactionReceipt: Status, Gas Used and Logs

eth_getTransactionReceiptRead methodEthereum JSON-RPC

eth_getTransactionReceipt is how you find out what a transaction did. It returns null until the transaction is mined, then hands back the execution result: status, gas used, effective gas price, the logs it emitted and, for deployments, the address of the new contract. Every send pipeline ends in a receipt poll.

1 credit
per call on BLAZED.sh
Read
call type
1
parameter
All clients
client support

Try eth_getTransactionReceipt

Request as curl
curl -s https://ethereum-rpc.publicnode.com \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getTransactionReceipt",
  "params": [
    "0x1433cd18789195b1f14d55426174f0981ae3ee4256e30804a6d7e1fd286fe840"
  ]
}'

Runs the example straight from your browser against the endpoint above. The prefilled URL is a third-party public endpoint, not run by BLAZED.sh.

What eth_getTransactionReceipt does

A receipt is produced by consensus, not by the node's opinion, so every honest node returns the same one for the same transaction. It is also the only place the success flag lives: status is 0x1 for a transaction that ran to completion and 0x0 for one that reverted. Reverted transactions are still included in the block and still pay for the gas they burned.

The logs array is the same log shape eth_getLogs returns, scoped to this transaction, with logIndex still counted across the whole block. For a single transaction this is the cheapest way to read its events; for a range of blocks, eth_getLogs is the right tool, and for every receipt in one block at once, eth_getBlockReceipts beats issuing one request per transaction.

Fee accounting comes from two fields: gasUsed times effectiveGasPrice is what the sender paid in wei. cumulativeGasUsed is the running total for the block up to and including this transaction, which is useful for reconstructing block-level gas but is not your transaction's cost. Blob transactions add blobGasUsed and blobGasPrice, a separately burned fee that is not part of the gas price.

Parameters

#NameTypeDescription
1transactionHashstring32-byte hash of a transaction. Returns null while the transaction is pending or unknown to this node.

What it returns

null while pending or unknown; otherwise an object with transactionHash, transactionIndex, blockHash, blockNumber, from, to (null for a contract creation), contractAddress (set only for a creation), cumulativeGasUsed, gasUsed, effectiveGasPrice, logs, logsBloom, status and type, plus blobGasUsed and blobGasPrice for blob transactions.

The receipt does not carry a revert reason. status: 0x0 tells you the transaction failed and nothing about why; recovering the reason means replaying it with debug_traceTransaction, or repeating the call with eth_call pinned to the block it ran in.

Example response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "transactionHash": "0x1433cd18789195b1f14d55426174f0981ae3ee4256e30804a6d7e1fd286fe840",
    "blockNumber": "0x18789ac",
    "transactionIndex": "0x1d",
    "from": "0xdc4239109ce3a991673d29b26d84d487ad2cb19b",
    "to": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
    "contractAddress": null,
    "status": "0x1",
    "gasUsed": "0xf328",
    "cumulativeGasUsed": "0x3db4df",
    "effectiveGasPrice": "0x7a163827",
    "type": "0x2",
    "logs": [
      {
        "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x000000000000000000000000dc4239109ce3a991673d29b26d84d487ad2cb19b",
          "0x0000000000000000000000008d287fb56176cbfdc29a7b2df6186c7901a45f60"
        ],
        "data": "0x000000000000000000000000000000000000000000000000000000001dcd6500",
        "logIndex": "0x64",
        "removed": false
      }
    ]
  }
}

A successful USDC transfer, logsBloom and repeated block fields trimmed. gasUsed 0xf328 is 62,248 gas at an effective price of 0x7a163827 wei, and the single Transfer log carries the 500 USDC amount in data.

eth_getTransactionReceipt with ethers.js

import { JsonRpcProvider, formatEther } from "ethers";

const provider = new JsonRpcProvider("https://ethereum-rpc.publicnode.com");
const hash = "0x1433cd18789195b1f14d55426174f0981ae3ee4256e30804a6d7e1fd286fe840";

const receipt = await provider.getTransactionReceipt(hash);
if (!receipt) throw new Error("still pending, or unknown to this node");

console.log("status:", receipt.status === 1 ? "success" : "reverted");
console.log("fee paid:", formatEther(receipt.gasUsed * receipt.gasPrice), "ETH");
console.log(receipt.logs.length, "logs emitted");

// after sending, tx.wait() polls this method for you
// const receipt = await (await wallet.sendTransaction(tx)).wait();

Gotchas and common errors

null means pending, not failed

The receipt appears only once the transaction is in a block, so null covers "still in the mempool", "dropped" and "this node never saw it". Treat null as "keep waiting" with a deadline of your own, and decide on a fee bump or a rebroadcast when the deadline passes rather than concluding failure.

status 0x0 costs you money and tells you nothing

A reverted transaction is a mined transaction: the nonce is consumed and the gas is paid. The receipt records only that it failed. To recover the reason, replay it with debug_traceTransaction using callTracer, which surfaces revertReason on the failing frame, or re-run the same call with eth_call against the block it was mined in and read the error data.

gasUsed is yours, cumulativeGasUsed is the block's

cumulativeGasUsed is the total gas burned by every transaction up to and including this one, which for a transaction late in a block is a huge number that has nothing to do with your cost. Your cost is gasUsed times effectiveGasPrice. Mixing the two up produces fee reports that are wrong by orders of magnitude.

One receipt per request adds up

Indexers that walk a block by calling this method once per transaction issue hundreds of requests per block. eth_getBlockReceipts returns every receipt in a block in a single call, which is one request instead of hundreds and one shot at consistent data. Where an endpoint does not expose it, batching JSON-RPC requests into one HTTP body is the fallback.

Receipts can be reorged away

A receipt read at the head describes a block that may not survive. If it matters, re-read after a confirmation buffer, or only trust receipts whose block is at or below the finalized tag. The same caution applies to the logs inside the receipt, which is the mirror image of the removed flag on eth_getLogs results.

contractAddress is only for deployments

For a normal call it is null; for a contract creation it holds the deployed address and to is null instead. That address is deterministic from the sender and nonce (or from the salt and init code for CREATE2), so you can compute it before sending; the receipt is simply where you confirm it.

What eth_getTransactionReceipt costs on BLAZED.sh

eth_getTransactionReceipt costs 1 credit per call on BLAZED.sh, and receipts are small enough that the over-100KB surcharge only shows up for transactions that emitted an unusual number of logs. The cost that catches people is repetition: a tight polling loop and a per-transaction receipt fetch across a whole block both turn into request counts far larger than the work suggests. Subscribe to newHeads and fetch once per block, or use eth_getBlockReceipts, and let the co-located node make each of those calls a sub-10ms local round-trip.

See the full credit price list

eth_getTransactionReceipt: frequently asked questions

Why is my transaction receipt null?

The transaction has not been mined yet, or this node does not know it. A receipt exists only after inclusion in a block, so null is the normal state for a freshly broadcast transaction; treat it as pending and keep polling with a deadline.

How do I know if a transaction succeeded?

Read status: 0x1 is success, 0x0 is a revert. Receipts from before the Byzantium fork have a root field instead of status, which only matters when reading very old history.

How do I get the revert reason from a receipt?

You cannot; the receipt does not carry one. Replay the transaction with debug_traceTransaction and the callTracer, which reports error and revertReason on the failing frame, or re-issue the same call with eth_call pinned to the block it ran in and decode the error data.

What did the transaction actually cost?

gasUsed multiplied by effectiveGasPrice, in wei. cumulativeGasUsed is the block's running total and is not your cost. Blob transactions burn an additional blobGasUsed times blobGasPrice on top.

How do I fetch all receipts in a block?

Use eth_getBlockReceipts with a block number or tag; it returns the whole array in one request instead of one call per transaction, which is both faster and cheaper for indexers.

Call eth_getTransactionReceipt from the node itself

Deploy your container or script next to a synced Ethereum node. No rate limits, no compute units, sub-10ms local RPC.