Skip to content

Ethereum method

eth_getTransactionReceipt

Returns the receipt for a mined transaction, including its logs and status.

cheapCheap for a provider to serve — no state is read, or one key is.Primary specification (opens in a new tab)

How each provider handles it

9 providers

Provider support for eth_getTransactionReceipt on Ethereum
ProviderStatusSuccessMedian
TenderlySupported100.0%25 ms
PublicNodeSupported99.9%23 ms
NodeRealSupported100.0%89 ms
MEV BlockerSupported99.8%84 ms
MerkleFailing10.7%104 ms
dRPCSupported99.6%48 ms
CloudflareFailing0.0%—
Blast APIDegraded98.6%105 ms
1RPConerpcFailing1.8%2957 ms

Success excludes calls the provider does not implement — an optional method a provider declines to offer is a capability fact, not a failure, and is never scored as one.

Over time

Median latency per day. Gaps are periods with no measurement, drawn as gaps rather than joined across — a line through missing data invents a measurement that was never taken.

Logarithmic scale — each gridline is ten times the one below it. Click a provider in the legend to hide it. 1 provider is not plotted: they returned no successful response in this window, so they have no latency.

When it degraded

A degradation is a bucket where a provider fell away from ITS OWN median for this method over the window, not from the cohort's. A provider that is consistently slower than its peers is not degraded — it is slower, which the ranking already says. Buckets with fewer than 20 samples are skipped, because a claim about a provider cannot rest on a handful of calls, and adjacent bad buckets are merged so one outage reads as one incident.

dRPC

  • median rose to 112ms from a typical 45ms

    latency · 2026-10-01 00:00Z

MEV Blocker

  • median rose to 136ms from a typical 49ms

    latency · 2026-09-09 00:00Z → 2026-09-21 00:00Z

Merkle

  • success fell to 11.1% from a typical 19.1%

    availability · 2026-09-22 00:00Z → 2026-10-08 00:00Z

1RPC

  • median rose to 7338ms from a typical 3237ms

    latency · 2026-09-10 00:00Z

What it does

The receipt is how you learn what a transaction did: whether it succeeded, how much gas it used, and which events it emitted. It exists only once the transaction is mined.

Polling this endpoint is how nearly every application waits for a confirmation, which makes it one of the most frequently called methods in production.

Parameters

transactionHashDATA, 32 bytesrequired
The transaction hash.

Returns

Object — the receipt, or null if the transaction is unknown or still pending.

Try it

Runnable as written, against a keyless public endpoint. Nothing here needs an API key.

Request

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'

As JSON-RPC

{
  "jsonrpc": "2.0",
  "method": "eth_getTransactionReceipt",
  "params": ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],
  "id": 1
}

Response

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "transactionHash": "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
    "blockNumber": "0x14a2f3b",
    "status": "0x1",
    "gasUsed": "0x5208",
    "logs": []
  }
}

Things that bite

  • status is 0x1 for success and 0x0 for a reverted transaction. A reverted transaction still has a receipt and still consumed gas.
  • null means unknown to this node — pending, dropped, or simply not indexed here. It does not mean the transaction failed.

Why it is measured

The hash is discovered from a block observed moments earlier rather than hard-coded, so the parameter is always a real, recent transaction and never a stale constant that some providers have pruned.

Called every 300 seconds per endpoint, with jitter so the fleet does not hit a provider in lockstep.

30d window · generated 2026-10-08 20:30:04 UTC · 9 providers