What is an RPC node? JSON-RPC explained for builders
What an RPC node is, how JSON-RPC requests over HTTPS and WebSocket work, which read methods apps use most, and why most apps use an RPC provider.
On this page
An RPC node is a blockchain node that answers requests from outside: an app sends a JSON message such as "what is the balance of this address?" and the node replies with the answer from its copy of the chain. Every wallet, dApp, indexer and on-chain bot talks to a blockchain this way, either through its own node or through an RPC provider that runs nodes for it.
What "RPC" means here
RPC stands for remote procedure call: the app calls a function, but the function runs on another machine. On Ethereum and the chains that copy its interface (Base, Arbitrum, BNB Smart Chain, HyperEVM and many more), the format is JSON-RPC, a small, stateless protocol in which every request names a method and its parameters.1
Every Ethereum client implements the same JSON-RPC methods, so an app can rely on one interface regardless of which node software answers.2 That is what makes nodes interchangeable: the same request works against a node in your own rack, a node of a provider, or a public endpoint of the chain.
A typical request has four fields:
{ "jsonrpc": "2.0", "id": 1, "method": "eth_getBalance", "params": ["0x0000000000000000000000000000000000000000", "latest"] }The node answers with the same id and either a result or an error. Several requests can travel together as a batch (a JSON array), and the answers come back in one response.
The methods most apps use
Most traffic is reading. A handful of methods covers the bulk of it:
| Method | What it returns | Typical use |
|---|---|---|
eth_blockNumber | The newest block number | Health checks, "is my node in sync?" |
eth_getBalance | The native balance of an address at a block | Wallet balances |
eth_call | The result of a contract function, executed without creating a transaction | Token balances, prices from a pool, any view function |
eth_getLogs | The events (logs) matching a filter of addresses, topics and a block range | Indexers, transfer histories, event-driven bots |
eth_getTransactionReceipt | Status, gas used and logs of a mined transaction | Confirming that a transaction went through |
eth_sendRawTransaction | Broadcasts a transaction that was signed locally | Every write to the chain |
The methods that read state (eth_getBalance, eth_getCode, eth_getTransactionCount, eth_getStorageAt and eth_call) take a block parameter: a block number, or a tag such as latest, safe or finalized.2 Asking for latest gives the newest state; asking for an old block number asks for the state at that time, which is where full nodes and archive nodes start to differ.
Writing is different from reading. The node never holds your private key: the transaction is signed in the wallet or the app, and the node only broadcasts the signed bytes.
HTTPS or WebSocket
The same JSON messages travel over two transports.
- HTTPS is request and response. The app asks, the node answers, the connection can close. It suits most reads and is easy to cache, retry and load-balance.
- WebSocket keeps one connection open, which allows subscriptions: with
eth_subscribethe node pushes every new block header (newHeads) or every log matching a filter (logs) as it appears. Bots that react to events use this instead of polling.
A WebSocket connection can drop. A client that reconnects has to find out what it missed, usually by reading the gap with eth_getLogs over the blocks in between.
Why most apps use an RPC provider
Running your own node is possible, and some teams do it for control or privacy. It also means hardware, a full sync of the chain, upgrades with every client release, monitoring and a second node for when the first one fails. For a team that builds on several chains, that is several nodes per chain.
A provider runs those nodes and puts a gateway in front of them. What the gateway adds is what an app would otherwise build itself: routing to a healthy node, failover when one stops answering, rate limits so one customer cannot slow down another, authentication with a token, and usage accounting.
Public endpoints of a chain exist too, but they are built for light use. HyperEVM is an example: its official JSON-RPC answers eth_call, eth_getBalance and similar state reads for the latest block only, limits eth_getLogs to 50 blocks and 4 topics per query, and rate-limits the public endpoint per IP address.3 Its documentation points to independent archive node implementations for historical state.3
Limits and credits
Every RPC service measures use in some unit. A plain request count treats a cheap eth_blockNumber the same as an eth_getLogs over many blocks, so many services weigh methods by how much work they cause.
Blockmetric RPC counts in credits, where one credit is one standard request and heavier methods weigh more:4
| Method class | Weight | Examples |
|---|---|---|
| Answered by the gateway | 0 | eth_chainId, net_version |
| Standard reads | 1 | eth_blockNumber, eth_getBalance, eth_call |
| Heavy reads | 2 | eth_getLogs, eth_getBlockReceipts |
| Trace and debug | 5 | trace_block, debug_traceTransaction |
A batch costs the sum of its calls, and every response reports what it cost in the header X-Blockmetric-Credits. Next to the monthly credits, each plan has a requests-per-second limit; a request above it answers 429 with a Retry-After header. The allowance of each plan is on the RPC pricing page.
How Blockmetric RPC works
Blockmetric RPC is standard JSON-RPC over HTTPS and WebSocket for Ethereum, Base, Arbitrum, OP Mainnet, Polygon, BNB Smart Chain, Avalanche, HyperEVM and the HyperCore info API, plus testnets.5 An endpoint is one URL per chain with an endpoint token (bmr_…), either in the path or in an Authorization: Bearer header:
curl -s https://rpc.blockmetric.io/base/$BLOCKMETRIC_RPC_TOKEN \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'What the public pages describe:
- Reads and subscriptions. Batches,
eth_subscribefor new heads and logs with a gap notice after reconnects, archive data on every plan, trace and debug methods on the paid plans.5 - Consistency. Health checks on every upstream node, failover for reads, and requests of one account stay on the same node for a short time so that
latestdoes not jump back between two nodes.5 - Read-only during the beta. Sending transactions is not enabled yet; the gateway holds no keys and never signs.4
- Opened on demand. Chains, regions and plans open when enough teams ask for them, and the waitlist on the RPC product page takes the exact combination a team needs.5
RPC is a separate product from the Blockmetric market-data API. The API answers questions about markets (liquidations, funding, open interest, whale positions) with our own computed data; RPC gives direct access to the chain itself. The developer overview has a short "API or RPC?" comparison, and the Hyperliquid side of both is described on the Hyperliquid exchange page.
Common questions
Is an RPC node the same as a validator? No. A validator takes part in consensus and produces blocks. An RPC node follows the chain and answers queries; it does not need to stake or vote.
Can an RPC provider move my funds? Not through standard JSON-RPC. Transactions are signed on your side, and the node can only broadcast what you signed. It can see which addresses you query, which is one reason some teams keep their own node.
Why does the same call give different answers on two nodes? Two nodes can be a block or two apart. Pinning reads to one node for a while, or asking for safe or finalized instead of latest, avoids answers that seem to go back in time.
Sources
- JSON-RPC Working Group, "JSON-RPC 2.0 Specification": https://www.jsonrpc.org/specification (accessed 2026-11-05)Back to text
- ethereum.org, "JSON-RPC API": https://ethereum.org/en/developers/docs/apis/json-rpc/ (accessed 2026-11-05)Back to text
- Hyperliquid Docs, "JSON-RPC" (HyperEVM): https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/json-rpc (accessed 2026-11-05)Back to text
- Blockmetric RPC docs, "Limits and errors": https://blockmetric.io/docs/rpc/limits (accessed 2026-11-05)Back to text
- Blockmetric RPC product page: https://blockmetric.io/rpc (accessed 2026-11-05)Back to text
How we collect and check the data: Data & methodology.
See today’s numbersThe live pages update continuously.
See RPC plans