RPC endpoint
Also written RPC node, RPC provider, RPC URL
The URL at which a blockchain node answers remote procedure calls — on Ethereum and most chains modelled on it, JSON-RPC requests such as a balance, a block, a receipt or a contract call. It returns raw chain state, one question at a time, as the node that serves it holds that state. It is plumbing: it answers about accounts and blocks, not about markets.
Three pages in this catalogue use the phrase to say what is not in it: node providers are out of scope, because an RPC endpoint is plumbing. This page is the reason spelled out, and the list of things a reader expects from one that it will not do.
How it works
A node is a computer running a chain's client software and holding a copy of the chain. The endpoint is the address at which it takes questions. On Ethereum those questions are JSON-RPC: ethereum.org describes JSON-RPC as "a stateless, light-weight remote procedure call (RPC) protocol", and says every Ethereum client implements the same specification "so there is a uniform set of methods that applications can rely on regardless of the specific node or client implementation." The methods are narrow by design — the balance of one address, one block, one transaction receipt, the logs matching a filter, the result of calling a contract function.
Three things decide what a given endpoint can answer, and none of them is visible in the URL.
Which state the node kept. A full Ethereum node, per ethereum.org, "only caches the past few states, e.g., the state associated with the last 128 blocks." An archive node keeps "every historical state created after each block", at a cost of roughly 3 to 12 TB of disk depending on the client. Asking a full node for an address's balance a year ago fails, or forces a re-execution of past transactions, however polished the provider's dashboard.
Which block it answers from. Ethereum requests take a block parameter — latest, safe,
finalized or a number. Solana requests take a commitment level, processed, confirmed or
finalized, and Solana's documentation says the default "is typically finalized". Two calls to
two endpoints a second apart can disagree because they read different points in the chain, and
neither is wrong.
Who runs it, and on what terms. Solana publishes free endpoints for mainnet, devnet and testnet
with a cap of 100 requests per 10 seconds per IP, 40 for any single method, and states that they
"are not intended for production applications." Hosted providers meter by method weight rather
than by call: Alchemy's published table prices eth_blockNumber at 10 compute units and
eth_getLogs at 60, so the methods that do data work drain a quota fastest.
Why it matters here
It is not a data product, and the catalogue does not list it as one. The on-chain analytics page and the market data APIs page both exclude node providers by name. An endpoint answers about accounts, blocks and transactions. It has no method for a token's holder list or a protocol's quarterly revenue, and a pool's trades come back as raw logs, because those questions span every transaction touching a contract and need each one decoded. The Solana collection makes the same point for that chain; what an Ethereum RPC endpoint cannot answer walks through the Ethereum gaps method by method, including the staking data that sits behind a second client altogether.
Indexed products sit on top of endpoints, and some say so. growthepie states that it indexes most of its numbers itself via RPCs. That is what "multi-chain" costs a vendor: not one endpoint with a chain parameter, but a pipeline per chain. Dune, Allium and Bitquery sell the result of that work — decoded tables — and the price of any of them is mostly the price of not writing the loop yourself.
A research tool that says "RPC" wants you to bring one. NautilusTrader ships direct WebSocket RPC clients for Ethereum, Polygon, Base, Arbitrum and BSC. The node, its quota and its archive depth are yours to provide, and a free endpoint that only keeps recent state will quietly end a backfill at the edge of what it holds.
"RPC" on an exchange card is a different word. JSON-RPC is only a message format, and the specification is explicit that it is "transport agnostic". Paradigm runs its API as REST plus JSON-RPC over WebSocket; CoinAPI lists JSON-RPC among six protocols; Kaiko streams over gRPC. None of those is a blockchain node. A card saying "JSON-RPC" describes how requests are framed, and says nothing about on-chain data. Read the noun after "RPC" before assuming which one a vendor means.
Rate limits are the second trap. A node provider's quota is counted in method-weighted units, an exchange's in request weight or orders per second, and the two numbers are not comparable. The rate limit entry covers the exchange side.
Where you will meet this
The cards where this changes a decision, then the rest that use the word.
Sources
- JSON-RPC API — ethereum.org,
- Archive nodes — ethereum.org,
- JSON-RPC 2.0 Specification — JSON-RPC Working Group, . Version 2.0 is still the latest the working group has published.
- Solana clusters and public RPC endpoints — Solana Foundation, read
- Solana RPC methods — commitment levels — Solana Foundation, read
- Compute unit costs — Alchemy, read
Updated