Answers>Learn about RPC & APIs>How do RPC requests work?
How do RPC requests work?
// Tags
RPC requestsJSON-RPCblockchain API calls
TL;DR: An RPC (Remote Procedure Call) request is how your application communicates with a blockchain node. Your app sends a JSON-formatted message to an RPC endpoint specifying which method to call and what parameters to include. The node processes the request, executes the corresponding logic against the blockchain's state, and returns a JSON response with the result. Every wallet balance check, transaction submission, and smart contract interaction follows this request-response pattern.
The Simple Explanation
When you tap "send" in a crypto wallet or check your token balance on a portfolio tracker, your application does not have direct access to the blockchain. It needs to ask a node for that information. The language it uses to ask is called JSON-RPC, a lightweight protocol that structures requests and responses as simple JSON objects.
Here is how the conversation works. Your application constructs a request object with four fields: the JSON-RPC version (always "2.0"), a method name that tells the node what operation to perform, an array of parameters that provide context for that operation, and a unique ID so your app can match the response to the request. It sends this object as an HTTP POST to the RPC endpoint URL. The node receives the request, looks up or computes the answer, and sends back a response object containing the same ID and either a result field (if successful) or an error field (if something went wrong).
For example, to check the ETH balance of a wallet address, your application sends a request with the method "eth_getBalance" and two parameters: the wallet address and "latest" (meaning the most recent block). The node looks up the current state, finds the balance associated with that address, and returns it as a hexadecimal value. Your application then converts that hex value to a human-readable number and displays it. The entire round trip typically takes tens of milliseconds with a performant provider.
Anatomy of Common RPC Methods
Every blockchain defines a set of standard RPC methods that nodes must support. On Ethereum and EVM-compatible chains, these methods follow the "eth_" namespace convention. Read operations query the blockchain's state without modifying it. "eth_blockNumber" returns the latest block height. "eth_getBalance" returns an account's native token balance at a given block. "eth_call" executes a smart contract function in read-only mode, which is how your app retrieves token balances, NFT metadata, and DeFi protocol states without spending gas.
Write operations submit data to the network for inclusion in a block. "eth_sendRawTransaction" broadcasts a signed transaction to the mempool, where validators pick it up for inclusion. "eth_estimateGas" simulates a transaction to predict how much gas it will consume, helping your application set appropriate gas limits before sending.
Subscription methods enable real-time communication over WebSocket connections. Instead of your app repeatedly polling the node with "eth_blockNumber" to detect new blocks, it can call "eth_subscribe" with the parameter "newHeads" and the node will push each new block header to your app as it is produced. This is far more efficient and lower latency than polling, and it is the foundation of real-time dapp experiences like live transaction feeds, event listeners, and instant balance updates.
Solana uses a different set of methods optimized for its account-based model. "getBalance" returns the SOL balance of an account. "getTransaction" retrieves a confirmed transaction by its signature. "getAccountInfo" returns the data stored in an account, which on Solana includes both token balances and program state. Despite the different method names, the underlying JSON-RPC pattern is identical: request with method and params, response with result or error.
Request Lifecycle Under the Hood
When your application sends an RPC request, multiple steps happen before you receive a response. First, the HTTP client establishes a TCP connection to the endpoint and performs a TLS handshake to encrypt the channel. Then it sends the JSON payload. The node's RPC server parses the request, validates the method name and parameters, and routes it to the appropriate handler. The handler either looks up cached data, queries the node's local database, or executes computation (like running a smart contract call in the EVM). Once the result is ready, the node serializes it as JSON and sends it back over the same connection.
Each of these steps adds time. DNS resolution, TCP handshake, TLS negotiation, request serialization, node processing, response serialization, and network transit all contribute to the total response time. This is why geographic proximity between your application and the RPC node matters, why connection pooling and HTTP/2 multiplexing improve throughput, and why caching frequently requested data on your end reduces unnecessary round trips.
Batch requests are a feature of the JSON-RPC spec that lets you send multiple requests in a single HTTP call. Instead of sending five separate requests for five different wallet balances, you package all five into a JSON array and send them together. The node processes each one and returns an array of responses. Batching reduces HTTP overhead and can improve throughput, though each individual request still consumes the same processing resources on the node side.
Error Handling and Best Practices
RPC responses include standard error codes when something goes wrong. A malformed request returns a parse error. An invalid method name returns a method-not-found error. Rate limiting typically returns an HTTP 429 status or a JSON-RPC error with code -32005. Understanding these error codes and handling them gracefully in your application is essential for building reliable blockchain software.
Retry logic with exponential backoff is a best practice for transient failures. If a request fails due to a network hiccup or a temporarily overloaded node, your app should wait a short period and try again, increasing the wait time with each successive retry. This prevents your application from hammering a struggling node and making the problem worse. Setting reasonable timeouts is equally important, as a hung request that never resolves can block your application's event loop.
Choosing the right RPC method for the job also matters. A common mistake is calling "eth_getBlockByNumber" with the full transactions flag set to true when your application only needs the block header. The full transactions response can be orders of magnitude larger, consuming more bandwidth and taking longer to parse. Similarly, using "eth_getLogs" with an excessively broad block range can return massive datasets that overwhelm both the node and your application. Paginating log queries into smaller block ranges is standard practice.
What is the difference between HTTP and WebSocket RPC requests?
RPC requests travel over a few different transports, and choosing the right one has a big impact on latency and efficiency. HTTP is a request-response model: your app opens a connection, sends one request, gets one response, and the exchange ends. WebSocket keeps a single persistent connection open so the node can push data to your app the moment it is available. gRPC adds a high-performance binary protocol for low-latency, high-throughput workloads.
Transport
Best for
Connection
Real-time push
HTTP (JSON-RPC)
One-off reads and writes
New per request (poolable)
No, you must poll
WebSocket
Subscriptions and live updates
Single persistent connection
Yes, server pushes data
gRPC
High-throughput, low-latency pipelines
Persistent, multiplexed
Yes, streaming
If your application only needs occasional reads, plain HTTP is simplest. If you need live blockchain events, a WebSocket subscription beats hammering the node with repeated calls. For a deeper look at the connection types a node exposes, see what an RPC endpoint is, and for the trade-offs between checking repeatedly versus subscribing, see polling vs streaming.
Why do RPC requests fail or time out?
Most RPC failures fall into a few buckets. Rate limiting returns an HTTP 429 or JSON-RPC code -32005 when you exceed your request allowance, so back off and retry rather than retrying immediately. Node unavailability returns 502 or 503 when the node is restarting, syncing, or overloaded. Oversized queries, such as an eth_getLogs call across millions of blocks, can time out because the node cannot assemble the response in time. Understanding RPC rate limiting and pairing your provider with strong node reliability practices keeps these failures rare and recoverable.
How can you make RPC requests faster?
RPC latency is the sum of network transit and node processing time, and both are controllable. Route requests to a node geographically close to your users, reuse connections with pooling and HTTP/2 multiplexing, batch related calls into a single request, and cache data that does not change between blocks. Choosing the leanest method for the job also helps: request a block header instead of full transactions when you only need the header. For the full breakdown of what slows requests down, see what drives RPC latency, or skip the tuning entirely with the globally distributed Quicknode Core API.
When should you use RPC instead of indexing or streaming?
RPC is the right tool for point lookups and writes: fetching a single balance, reading one contract value, or broadcasting a transaction. It becomes inefficient when you need large historical datasets or aggregated views, because reconstructing that data from raw RPC calls is slow and request-heavy. For analytical queries, an indexed dataset is far more efficient, and for continuous real-time data, streaming removes the request-response overhead entirely. See RPC vs indexing for choosing between live calls and prepared datasets.
How Quicknode Optimizes RPC Requests
Quicknode's Core API is built to make every RPC request as fast and reliable as possible. The platform's globally distributed infrastructure routes each request to the nearest available node, minimizing network transit time. With response times 2.5x faster than competitors on average and a 99.99% uptime SLA, Quicknode ensures your application's RPC calls resolve quickly and consistently regardless of traffic volume.
Beyond standard JSON-RPC, Quicknode provides enhanced API methods that reduce the number of requests your application needs to make. Instead of calling multiple standard methods to reconstruct a wallet's complete token holdings, a single enhanced API call can return all the data in one response. Quicknode Streams takes this further by eliminating the request-response pattern entirely for real-time data, pushing blockchain events directly to your application or database as they happen. For developers looking to optimize their RPC usage, Quicknode publishes a detailed guide to efficient RPC calls covering pagination, caching, error handling, and method selection best practices.
Frequently Asked Questions
What does RPC stand for in blockchain?
RPC stands for Remote Procedure Call. It is a pattern where your application calls a function that runs on a remote machine, in this case a blockchain node, as if it were calling a local function. The node executes the procedure against the chain's state and returns the result.
What is JSON-RPC?
JSON-RPC is the lightweight protocol most blockchains use for RPC. Requests and responses are plain JSON objects. A request names a method and its parameters, and the response carries either a result or an error, matched to the request by a shared ID.
Is an RPC request the same as an API call?
It is a specific kind of API call. A general REST API exposes resources at different URLs, while a blockchain RPC API exposes methods at a single endpoint URL and selects the operation through the method name in the request body. The round-trip request-response idea is the same.
How long does an RPC request take?
A simple read against a nearby, well-provisioned node typically completes in tens of milliseconds. Heavier calls, such as broad log queries or full block fetches, take longer because the node has more data to assemble and serialize before responding.
What is the difference between an RPC node and an RPC endpoint?
An RPC node is the running server that holds blockchain data and executes requests. An RPC endpoint is the URL your application sends requests to, which routes them to one or more nodes behind it. See what a blockchain node is for the underlying infrastructure.
