Skip to content

Ethereum method

eth_getTransactionCount

Returns how many transactions an address has sent — its nonce.

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_getTransactionCount on Ethereum
ProviderStatusSuccessMedian
TenderlySupported100.0%24 ms
NodeRealSupported99.9%88 ms
PublicNodeSupported99.9%22 ms
MEV BlockerSupported99.8%135 ms
dRPCSupported99.4%53 ms
Blast APIDegraded98.7%115 ms
MerkleRate limited13.8%107 ms
1RPConerpcRate limited1.5%2513 ms
CloudflareFailing0.0%—

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 104ms from a typical 48ms

    latency · 2026-09-23 00:00Z

  • median rose to 112ms from a typical 48ms

    latency · 2026-10-01 00:00Z

  • median rose to 106ms from a typical 48ms

    latency · 2026-10-07 00:00Z

1RPC

  • median rose to 5954ms from a typical 2478ms

    latency · 2026-09-10 00:00Z

What it does

The nonce. Every transaction from an account must carry the next one in sequence, so anything that sends a transaction reads this first.

The block parameter is unusually consequential here. At `latest` it counts mined transactions only; at `pending` it includes ones sitting in that node's mempool. Using `latest` while a transaction is still pending produces a nonce that is already taken, and the replacement is rejected.

Parameters

addressDATA, 20 bytesrequired
The account.
blockQUANTITY | TAGrequired
A block number in hex, or one of latest, earliest, pending, safe, finalized.Default: none — most clients accept latest, but the parameter is not optional in the specification and some providers reject the call without it

Returns

QUANTITY — the transaction count in hex.

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_getTransactionCount","params":["0x28C6c06298d514Db089934071355E5743bf21d60","latest"],"id":1}'

As JSON-RPC

{
  "jsonrpc": "2.0",
  "method": "eth_getTransactionCount",
  "params": ["0x28C6c06298d514Db089934071355E5743bf21d60", "latest"],
  "id": 1
}

Response

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": "0x1f4a2"
}

Things that bite

  • Mempools are per-node. Two providers will legitimately return different pending nonces for the same address at the same moment.

Why it is measured

It sits directly on the transaction-sending path, so its latency is felt by every user who presses confirm.

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

30d window · generated 2026-10-08 18:33:19 UTC · 9 providers