//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.
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.
