Ethereum method
eth_getTransactionReceipt
Returns the receipt for a mined transaction, including its logs and status.
How each provider handles it
| Provider | Status | Success | Median |
|---|---|---|---|
| Merkle | Failing | 0.0% | — |
| Cloudflare | Failing | 0.0% | — |
| 1RPConerpc | Failing | 5.6% | 3098 ms |
| dRPC | Degraded | 97.9% | 77 ms |
| Tenderly | Supported | 100.0% | 28 ms |
| PublicNode | Supported | 100.0% | 30 ms |
| MEV Blocker | Supported | 100.0% | 47 ms |
| NodeReal | Supported | 100.0% | 89 ms |
| Blast API | Supported | 100.0% | 110 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 hour. 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. 2 providers are 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
success fell to 93.8% from a typical 100.0%
availability · 2026-10-08 15:00Z
median rose to 125ms from a typical 56ms
latency · 2026-10-08 16:00Z
1RPC
success fell to 0.0% from a typical 23.1%
availability · 2026-10-08 16:00Z → 2026-10-08 20: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
statusis0x1for success and0x0for a reverted transaction. A reverted transaction still has a receipt and still consumed gas.nullmeans 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.
6h window · generated 2026-10-08 20:58:49 UTC · 9 providers