Skip to content

Ethereum method

eth_getLogs

Returns event logs matching a filter over a block range.

expensiveExpensive: scans a range or a large account set. Frequently restricted.Primary specification (opens in a new tab)

How each provider handles it

9 providers

Provider support for eth_getLogs on Ethereum
ProviderStatusSuccessMedian
MerkleFailing0.0%—
CloudflareFailing0.0%—
TenderlySupported100.0%65 ms
NodeRealSupported99.9%120 ms
MEV BlockerSupported99.8%111 ms
dRPCSupported99.2%161 ms
PublicNodeSupported99.9%65 ms
Blast APIDegraded98.7%117 ms
1RPConerpcFailing0.4%8877 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. 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.

MEV Blocker

  • median rose to 168ms from a typical 76ms

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

1RPC

  • median rose to 19923ms from a typical 8275ms

    latency · 2026-09-12 00:00Z

  • median rose to 17501ms from a typical 8275ms

    latency · 2026-09-25 00:00Z

  • median rose to 19297ms from a typical 8275ms

    latency · 2026-09-29 00:00Z → 2026-09-30 00:00Z

What it does

Contracts emit events; this is how you read them. The filter selects by block range, by contract address, and by indexed topics — topic 0 being the event signature hash, and topics 1 to 3 the indexed arguments.

It is also the method providers disagree about most. The specification places no limit on the range, but serving an unbounded query means scanning the receipt index for every block in it, so almost every provider imposes a ceiling: a maximum block span, a maximum result count, or a timeout. Those limits are not in any standard, and they differ by an order of magnitude between providers.

Parameters

filterObjectrequired
fromBlock, toBlock, address (one or many), topics, or blockHash.Default: fromBlock and toBlock both default to latest, which returns only the newest block's logs — rarely what the caller intended

Returns

Array — log objects, each with address, topics, data, blockNumber, transactionHash and logIndex.

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_getLogs","params":[{"fromBlock":"latest","toBlock":"latest","address":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}],"id":1}'

As JSON-RPC

{
  "jsonrpc": "2.0",
  "method": "eth_getLogs",
  "params": [
    {
      "fromBlock": "latest",
      "toBlock": "latest",
      "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
      "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
    }
  ],
  "id": 1
}

Response

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    {
      "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
      "topics": [
        "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
        "0x000000000000000000000000...",
        "0x000000000000000000000000..."
      ],
      "data": "0x0000000000000000000000000000000000000000000000000000000005f5e100",
      "blockNumber": "0x14a2f3b",
      "transactionHash": "0x...",
      "logIndex": "0x2f"
    }
  ]
}

Things that bite

  • The topic above is keccak256("Transfer(address,address,uint256)"), the ERC-20 transfer event. Combined with the USDC address it selects USDC transfers only.
  • If blockHash is given, fromBlock and toBlock are not allowed. The specification is explicit about this and providers enforce it.
  • Providers that refuse a range answer in several different ways: a JSON-RPC error, an HTTP 413, or a truncated array with no indication it was truncated. The last is the dangerous one, because it looks like a successful answer.

Why it is measured

It is the sharpest capability difference on the platform. Measured over a deliberately small range with a real address and topic filter, some providers return hundreds of logs in a few hundred milliseconds, and others return `-32601 Method not found` — for a method that is not optional in any specification.

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

30d window · generated 2026-10-08 17:45:13 UTC · 9 providers