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%27 ms
PublicNodeSupported100.0%27 ms
NodeRealSupported100.0%87 ms
Blast APISupported100.0%120 ms
MEV BlockerSupported100.0%139 ms
CloudflareFailing0.0%—
dRPCDegraded94.1%82 ms
MerkleRate limited6.3%58 ms
1RPConerpcFailing2.1%662 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. 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 124ms from a typical 61ms

    latency · 2026-10-08 15:00Z

Merkle

  • success fell to 0.0% from a typical 12.5%

    availability · 2026-10-08 13:00Z → 2026-10-08 14:00Z

  • median rose to 109ms from a typical 38ms

    latency · 2026-10-08 16:00Z

1RPC

  • success fell to 0.0% from a typical 10.3%

    availability · 2026-10-08 13:00Z → 2026-10-08 14:00Z

  • success fell to 0.0% from a typical 10.3%

    availability · 2026-10-08 16:00Z → 2026-10-08 17: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.

6h window · generated 2026-10-08 18:20:02 UTC · 9 providers