# What an Ethereum RPC endpoint cannot answer

The eth_ namespace is one half of Ethereum. Staking, proposer pay, private order flow and smart-account users sit outside it, and so does some of the ETH.

*https://cryptomarkets.tools/guides/what-an-ethereum-rpc-cannot-answer · background to On-chain Analytics Platforms*

**Answer:** An Ethereum node is two clients, and the JSON-RPC endpoint you plug into is the execution half: blocks, balances, logs, transactions. Staking and validator data live on a separate consensus API that most RPC plans do not include. Proposer pay is arranged off-chain through relays. Transactions can reach a block without ever entering the public mempool. And ETH can arrive at an address with no transaction behind it.

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](https://cryptomarkets.tools/guides/where-an-onchain-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](https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/),
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](https://github.com/ethereum/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](https://github.com/ethereum/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](https://cryptomarkets.tools/tools/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](https://eips.ethereum.org/EIPS/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](https://cryptomarkets.tools/tools/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](https://eips.ethereum.org/EIPS/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](https://github.com/flashbots/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](https://docs.flashbots.net/flashbots-protect/overview) 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](https://cryptomarkets.tools/tools/dune) and
[CryptoQuant](https://cryptomarkets.tools/tools/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](https://eips.ethereum.org/EIPS/eip-4337) 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](https://eips.ethereum.org/EIPS/eip-7702) 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](https://cryptomarkets.tools/guides/where-an-onchain-number-comes-from), and it is the
reason an L2 series can depend on somebody having archived a disappearing input.

[growthepie](https://cryptomarkets.tools/tools/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](https://www.alchemy.com/docs/reference/eth-getlogs), 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](https://cryptomarkets.tools/tools/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](https://cryptomarkets.tools/categories/onchain-analytics) 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.

## Tools this bears on

- [Allium](https://cryptomarkets.tools/tools/allium.md) — Institutional SQL over 85+ indexed chains, with labels and no published price.
- [Bitquery](https://cryptomarkets.tools/tools/bitquery.md) — GraphQL over indexed chains — self-service plans are a real-time window, not history.
- [Kaiko Market Data API](https://cryptomarkets.tools/tools/kaiko.md) — Tick history back to 2010, by REST, gRPC stream or cloud delivery.
- [growthepie](https://cryptomarkets.tools/tools/growthepie.md) — Ethereum L2 economics, CC BY licensed, on an API with no key — and chains pay for depth.

## FAQ

### Does an Ethereum RPC endpoint give me staking and validator data?

Almost never. An Ethereum node is two clients, and the eth_ JSON-RPC namespace belongs to the execution one. Validators, attestations, epochs and the beacon state are served by the consensus client over a separate REST specification, the Beacon API, on a different port. Some providers sell access to it as a distinct product and many do not offer it at all, so ask before you assume a plan covers both halves.

### Why did an address balance change with no transaction?

Because it was a validator withdrawal. EIP-4895 made withdrawals a system-level operation that lives in the execution payload's withdrawals list rather than in the transaction list, with no signature and no gas cost. An indexer that reconstructs balances from transactions, internal calls and token transfers will be wrong for every address that receives staking rewards.

### Is gas paid the same thing as network revenue?

No. Under EIP-1559 the base fee "is always burned (i.e. it is destroyed by the protocol)" and only the priority fee reaches the block proposer. A figure computed as gas used times effective gas price is the sum of what users paid, most of which nobody received, and it is not the proposer's income either — a large part of that is negotiated off-chain through a relay.

### Can I see what is about to happen by watching the mempool?

Only the part that was public. Flashbots Protect describes sending transactions to "a private Flashbots mempool where they will be hidden from frontrunning and sandwich bots", and other private order-flow routes work the same way. A transaction can appear for the first time in a block, so a pending-transaction subscription measures publicly broadcast flow rather than everything that is coming.

### Is checking for code still a reliable way to tell a contract from a wallet?

Not since EIP-7702. An externally owned account can carry a delegation indicator — the specification sets its code to "0xef0100 || address" — so a non-empty code response no longer means the address is a contract. If your classification depends on the distinction, test for the 0xef0100 prefix rather than for code length.

## Sources

1. [Node architecture — execution clients, consensus clients and the Engine API](https://ethereum.org/en/developers/docs/nodes-and-clients/node-architecture/) — ethereum.org, 2026-03-25
2. [Proof-of-stake — slots, epochs and finality](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) — ethereum.org, 2026-08-31
3. [execution-apis — the JSON-RPC specification execution clients implement](https://github.com/ethereum/execution-apis) — Ethereum Foundation, read 2026-09-21
4. [beacon-APIs — the REST specification beacon nodes implement](https://github.com/ethereum/beacon-APIs) — Ethereum Foundation, read 2026-09-21
5. [EIP-1559 — Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) — Ethereum Improvement Proposals, 2019-04-13. Status Final, which freezes the text — the burn and the priority-fee split are what the specification says, not a schedule anyone refiles.
6. [EIP-4895 — Beacon chain push withdrawals as operations](https://eips.ethereum.org/EIPS/eip-4895) — Ethereum Improvement Proposals, 2022-03-10. Status Final, which freezes the text — withdrawals are still the object this document defines, not a later replacement.
7. [ERC-4337 — Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) — Ethereum Improvement Proposals, 2021-09-29. Status Final, which freezes the text — cited for the UserOperation and EntryPoint shape it defines, not for adoption figures.
8. [EIP-7702 — Set EOA account code](https://eips.ethereum.org/EIPS/eip-7702) — Ethereum Improvement Proposals, 2024-05-07
9. [mev-boost — middleware for the block-building market](https://github.com/flashbots/mev-boost) — Flashbots, read 2026-09-21
10. [Flashbots Protect overview](https://docs.flashbots.net/flashbots-protect/overview) — Flashbots, 2025-11-17
11. [eth_getLogs — supported block ranges by plan](https://www.alchemy.com/docs/reference/eth-getlogs) — Alchemy, read 2026-09-21
12. [Compute unit costs by method](https://www.alchemy.com/docs/reference/compute-unit-costs) — Alchemy, read 2026-09-21
13. [API rate limits by plan](https://docs.etherscan.io/rate-limits) — Etherscan, read 2026-09-21

*Last updated 2026-09-21. A reference page, corrected in place — not a dated post.*