What an Ethereum RPC endpoint cannot answer

You put an RPC URL in a config file, and within an hour you can read blocks, balances, receipts and logs. That is enough to make it look like the endpoint is Ethereum.

Then somebody asks what a validator earned last month, or why an address gained ETH with no transaction against it, or where the swap that moved the price was sitting before it landed. Every one of those questions is outside the box you plugged into, and nothing in the response tells you so. The endpoint answers what it can and is silent about the rest, which is the worst available failure mode: you get a number instead of an error.

This page is what the eth_ namespace covers, what sits next to it, and which of the gaps has a product in this catalogue behind it. It is about the plumbing rather than about any one vendor — for what happens to chain data after somebody has indexed it, the companion page is where an on-chain number comes from.

How it works

One endpoint, two nodes

Since the move to proof-of-stake, a node is not one program. ethereum.org's node architecture page, last updated 25 March 2026, is explicit: "An Ethereum node is composed of two clients: an execution client and a consensus client", and the execution client "must be used alongside another piece of software called a consensus client". The execution client handles "transaction validation, handling, and gossip, along with state management and supporting the Ethereum Virtual Machine (EVM)" and is "not responsible for block building, block gossiping or handling consensus logic". The consensus client "deals with all the logic that enables a node to stay in sync with the Ethereum network". They talk to each other locally over the Engine API.

Two clients means two interfaces, specified in two places by two repositories. execution-apis describes itself as a "Collection of APIs provided by Ethereum execution layer clients" and its JSON-RPC as "a standard collection of methods that all execution clients implement" — "the canonical interface between users and the network". That is eth_getBlockByNumber, eth_getLogs, eth_call, eth_getBalance: the ones every tutorial uses. The repository does not mention consensus-layer data, because that is not its subject.

The other half is beacon-APIs, a "Collection of RESTful APIs provided by Ethereum Beacon nodes", exposed by "a beacon node implementation of the Ethereum consensus layer specifications". Different protocol shape — REST rather than JSON-RPC — different port, different client, usually a separate product line from a provider that sells both.

So the first question to ask about any Ethereum data problem is not which provider but which of the two nodes the answer lives on. Validator balances, attestations, sync committees, slot and epoch structure, the beacon state: consensus side. Everything a block explorer shows you: execution side.

What this catalogue sells is the execution half. Of the 92 cards here, none serves beacon state, validator duties or attestation data. Kaiko is the closest — its blockchain monitoring covers Ethereum staking deposits and withdrawals back to genesis, which is the execution-layer view of staking rather than the consensus layer itself. If your question is about validators, this is not a shortlist problem; it is a beacon node or a specialist outside this catalogue.

ETH that arrives without a transaction

This is the one that quietly corrupts accounting, and it is a documented property of the protocol rather than anybody's implementation detail.

EIP-4895, Final, introduces "a new type of object – the 'withdrawal operation'" for moving staked ETH back to the execution layer. The specification is plain about what it is not: withdrawals are "syntactically similar to a user-level transaction but live in a different domain than user-level transactions", they are not signed, and "this operation has no associated gas costs". They are carried in a field of their own — "the execution payload gains a new field for the withdrawals which is an RLP list of Withdrawal data" — and the EIP notes that "an entirely new type of object firewalls off generic EVM execution from this type of processing".

Read that as a data engineer and it says: an address balance can increase with no transaction, no internal call and no log. Every pipeline built on the sentence "all ETH movement is a transaction or a trace" is wrong for every withdrawal address on the network, and wrong silently, because there is no row missing — there was never a row.

The cards that carry raw chain tables are where this becomes a checkable claim rather than a worry. Allium's Ethereum coverage lists raw blocks, transactions, logs, traces, contracts, block rewards, per-standard token tables and state diffs, plus balance tables — state diffs and balances are the two shapes that survive this problem, because they record the result rather than inferring it from the inputs. Where a vendor's Ethereum offering is transfers and transactions only, ask what it does with withdrawals before you reconcile anything against it.

The fee you can read is not money anyone received

EIP-1559, Final, split what a sender pays into two parts that go to different places. "The base fee is always burned (i.e. it is destroyed by the protocol)", and the block proposer "only receives the priority fee; note that the base fee is not given to anyone (it is burned)". A type-2 transaction carries max_fee_per_gas and max_priority_fee_per_gas rather than one price, and what is actually paid comes out as priority_fee_per_gas + block.base_fee_per_gas, with the priority component capped because "the base fee is filled first".

Three consequences for anything that reports fees:

• Gas used times effective gas price is what users spent, not what the network earned. Most of it was destroyed. The two are different numbers and a chart labelled "fees" can mean either.
• The split is not stable over time, because the base fee floats with demand. A ratio measured in one week does not let you convert one series into the other in another week.
• Neither number is the proposer's income, which is the next section.

This is also where a definitional gap shows up between products that look comparable. Where one platform reports fees paid and another reports fees received, the same chain on the same day gives two figures, both correct, and usually neither states which it is.

Most of the proposer's pay is arranged somewhere you cannot query

A block proposer does not have to build its own block. mev-boost, in its own description, is "open source middleware run by validators to access a competitive block-building market", and the market has three roles: "Block builders prepare full blocks, optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays"; relays "aggregate blocks from multiple builders in order to select the block with the highest fees"; and the validator's consensus client "proposes the most profitable block received from MEV-boost to the Ethereum network".

The mechanism that matters for data work is the blinded step. The proposer signs a block header and submits it back — submitBlindedBlock in the API — before it has the body. The bid it chose on, the identity of the builder and the competing bids were all carried by a relay, which is an off-protocol service run by a third party with an API of its own. None of it is in the chain.

So "what did this validator earn" is not an on-chain question. What lands on-chain is a payment whose arrangement happened elsewhere, and reconstructing the arrangement means reading relay data that no consensus rule obliges anyone to publish or retain. Any figure for proposer revenue is a figure with an off-chain dependency inside it, and the honest version of it says whose relay data it used.

The public mempool is a sample, not the queue

The textbook picture has a transaction broadcast to a peer-to-peer mempool, sit there, and get picked up. Subscribe to pending transactions and you see the future.

Private order flow breaks that picture by design. Flashbots Protect describes exactly what it does: "Transactions are sent to a private Flashbots mempool where they will be hidden from frontrunning and sandwich bots", and "transactions are only included in the block if they do not revert". A user sends to an endpoint instead of broadcasting; the transaction reaches a builder directly; it appears publicly for the first time when the block does.

Two things follow, and the second is the one that gets written into reports:

1. A pending-transaction subscription is a measurement of publicly broadcast flow. That is a real thing to measure and it is not the same thing as what is about to execute.
2. Latency measured as "time from first seen in mempool to inclusion" is undefined for anything that never appeared. Dropping those rows biases the sample toward exactly the transactions that had no reason to hide.

Only two cards here name the mempool at all — Dune and CryptoQuant — which is a reasonable signal of how much of this catalogue is built on confirmed data. Confirmed data is the right choice for most questions. It is the wrong input for any claim about what was coming.

An address stopped being one kind of thing

Two Final specifications broke two heuristics that most Ethereum analysis still runs on.

ERC-4337. The specification defines a UserOperation as "a structure that describes a transaction to be sent on behalf of a user", an EntryPoint as "a singleton contract to execute bundles of UserOperations", and a bundler as "a node (block builder) that can handle UserOperations, create a valid entryPoint.handleOps() transaction, and add it to the block while it is still valid". UserOperations travel through "a separate mempool", not Ethereum's.

The data consequence is a misattribution, not a gap. When a smart account acts, the transaction's from is the bundler. Count distinct tx.from values and every user of that bundler collapses into one address; count transactions and a bundle of forty user actions counts as one. A chain where account abstraction is in use will under-report active addresses and over-concentrate them, and the only fix is to decode handleOps calldata and count UserOperation senders — which is a decoding step your vendor has either done or not.

EIP-7702. The specification lets an externally owned account point at contract code: "Set the code of authority to be 0xef0100 || address. This is a delegation indicator", using "the banned opcode 0xef, defined in EIP-3541, to indicate that the code must be handled differently than regular code". The classic test — call eth_getCode, and if the answer is not 0x it is a contract — now returns a non-empty answer for ordinary wallets. Any classification, label set or filter built on code length has a false-positive class it did not have before, and the correct test is the three-byte prefix.

"Ethereum" now names a set of chains

The last gap is the one the coverage tables hide. A card that claims Ethereum coverage is almost always claiming layer one, while a growing share of the activity a reader wants to measure settles on rollups whose own data reaches Ethereum in blobs rather than in transactions. The retention question that creates — what the network is actually specified to keep, and for how long — is covered on where an on-chain number comes from, and it is the reason an L2 series can depend on somebody having archived a disappearing input.

growthepie is the card where this is most visible: it says it indexes most of its own data via RPCs, one per chain, which is what "multi-chain coverage" costs at the infrastructure layer. It is not one endpoint with a parameter. It is N pipelines.

What it costs

Two clients, two disks. Running your own is not a matter of adding a consensus client if you want staking data — per ethereum.org the execution client "must be used alongside" one to function at all. The consensus side is not an optional extra you buy when the question arrives; it is part of the floor.

Hosted RPC is metered by method weight, not by call. Alchemy publishes the table, read on 21 September 2026: eth_blockNumber costs 10 compute units, eth_getBalance, eth_getBlockByNumber and eth_getTransactionReceipt 20 each, eth_call 26, and eth_getLogs 60. The methods that do data work are the expensive ones, which means a quota estimated from a call count is out by a factor of several before you start.

The free tier's log query is ten blocks wide. The same provider's eth_getLogs reference, read the same day, gives the supported block range on Ethereum as 10 on the free plan against unlimited on paid, with all responses "capped at 150MB". Ethereum's slots are 12 seconds, so ten blocks is about two minutes of chain: a one-year log backfill on a free key is on the order of 260,000 calls in a loop, before retries. This is the single most common reason a working prototype cannot be pointed at history — and it is a plan property, not a protocol limit, because the JSON-RPC specification defines no pagination for eth_getLogs at all and every provider therefore sets its own cap.

The explorer API is the cheap path and it is genuinely cheap. Etherscan's published rate limits, read on 21 September 2026, put the free plan at 3 calls per second and up to 100,000 calls per day on selected chains, with paid plans running from 5 calls per second to 30 and from 100,000 calls per day to 1,500,000. Its V2 API puts "All 60+ EVM chains under one key", selected with a chainid parameter — one key and one integration where the RPC route is one endpoint per chain. For account history, token transfers and verified-contract lookups this is often the whole answer, and it costs nothing.

Indexed rows are what you buy when the loop above stops being worth writing. Bitquery is the clearest illustration of where that line is priced: its self-service plans keep a rolling window of raw on-chain data measured in hours, with complete history sold as a per-chain add-on rather than included in any published plan. You are not buying data nobody has. You are buying the archive and the decoding.

What you can do about it

Decide which node your question lives on before you shop. Write the question down and sort it: execution layer, consensus layer, or off-protocol. Validator income is the third with a bit of the second; token transfers are the first. A vendor conversation that starts "does this include beacon state" ends in one message; one that starts "does this cover Ethereum" ends in a contract that does not.

If you account for ETH balances, reconcile against state, not against flows. Pick one address with staking rewards, sum every transaction and internal transfer touching it, and compare the total to eth_getBalance at the same block. The difference is withdrawals. Do this before you trust any balance series you did not derive from state diffs or balance tables, including your own.

Report burned and tipped as two numbers, always. If a figure has to be a single one, say which it is in the label — "fees paid by users" or "priority fees received by proposers" — and never let gas used times price be described as revenue. This is one word in a column header and it is the difference between a correct chart and a wrong one.

Do not compute proposer income from on-chain data alone, and name the relay when you do. The bid, the builder and the competition are off-protocol. Any number here carries a dependency on a third party's records, and the footnote that says whose is the whole of its credibility.

Never present a mempool-derived metric as complete. Label it "publicly broadcast" and mean it. If the question is genuinely about what is coming rather than about what was public, the honest answer is that no public source can answer it, and that is a better deliverable than a biased one.

Replace the two broken address heuristics. Test for the 0xef0100 delegation prefix rather than for non-empty code, and for any chain with account-abstraction usage ask your vendor a direct question: does your active-address count use tx.from, or does it decode handleOps and count UserOperation senders? There is no third answer, and the two differ by a lot on exactly the chains being marketed hardest.

Measure your log-range cap before you write the backfill, not during. One eth_getLogs call over a thousand blocks tells you your plan's real ceiling in ten seconds. Multiply out the call count for the range you actually need, compare it to the quota, and you will know before you write the loop whether the answer is a bigger plan, an explorer API, or a vendor that sells the archive.

Try the explorer API first for anything account-shaped. Address history, token transfers, verified source — three calls per second and 100,000 a day on a free key, one key across 60+ EVM chains. A large share of what people reach for a paid RPC plan to do is this, and it is free.

Know the threshold below which none of this matters. One chain, recent blocks, confirmed data, token transfers and balances read from state, no staking and no claim about order flow: a plain RPC endpoint is completely adequate and every gap on this page is somebody else's problem. The gaps start to bite when the number describes income, when it describes what was about to happen, or when it has to reconcile against an address that stakes.

The on-chain analytics category page has the products that sell the execution half already indexed; for the consensus half, this catalogue has nothing, and saying so is more useful than a shortlist that does not fit.