What is a Remote Procedure Call (RPC)? The Complete Developer Guide
A Remote Procedure Call (RPC) is a protocol that allows a program on one machine to execute a function on a remote server as if it were running locally. No manual networking code required. The calling program sends a request, the remote server executes the function, and the result comes back. From the developer’s perspective, it looks like a local function call.
This communication pattern powers distributed systems everywhere: microservices, cloud infrastructure, and, critically for Web3, blockchain. Every time a wallet checks your ETH balance, every time a DeFi protocol reads on-chain data, every time a trading bot queries the latest block, that’s an RPC call. Understanding remote procedure calls is foundational for anyone building on blockchain infrastructure.
The concept dates to 1981, when Bruce Jay Nelson coined the term at Xerox PARC. The landmark paper by Andrew Birrell and Nelson, “Implementing Remote Procedure Calls” (1984), won the ACM Software System Award and established RPC as the foundation of distributed computing. Four decades later, every major blockchain runs on this same protocol.
What is the Purpose of RPC?
The purpose of RPC is to abstract away network complexity so developers can call functions on remote systems using the same syntax as local function calls.
Instead of manually constructing HTTP requests, handling serialization, managing connections, and parsing responses, a developer using RPC simply calls a function. The RPC framework handles everything underneath.
Specifically, RPC serves three core purposes:
- Location transparency: the caller doesn’t need to know where the function is physically running. It could be on the same machine or on a server 10,000 miles away.
- Distributed computing: RPC is the backbone of systems where work is split across multiple machines. Microservices communicate via RPC. Blockchain nodes expose their state via RPC.
- Standardized communication: RPC defines a contract between client and server. Both sides agree on method names, parameter formats, and response structures. No ambiguity.
This is why RPC became the dominant communication model for high-performance, low-latency systems, and why every major blockchain protocol adopted it as its standard interface.
How Does Remote Procedure Call Work?
A remote procedure call follows a precise sequence of steps every time it executes. Here’s what happens under the hood:
1. The client calls a local stub The developer writes code that looks like a normal function call. Behind the scenes, this triggers a client stub, a proxy object that intercepts the call.
2. The stub marshals the data Marshalling is the process of packaging the function name and its parameters into a transferable format (typically JSON or binary). Think of it as packing a box before shipping.
3. The request travels over the network The marshalled data is sent over a transport protocol: TCP/IP for most implementations, UDP for performance-critical ones. The RPC protocol layer handles routing.
4. The server stub receives and unmarshals On the server side, a mirror stub receives the packet, unpacks it (unmarshalling), and reconstructs the original function call.
5. The server executes the function The actual function runs server-side. The result is marshalled back into a response packet.
6. The client receives the result The response travels back, gets unmarshalled, and the original calling code receives the return value, exactly as if the function ran locally.
This entire sequence happens in milliseconds. For blockchain infrastructure handling billions of calls per day, the efficiency of steps 2-5 is what separates fast RPC from slow RPC.
Remote Procedure Call Example: JSON-RPC in Blockchain
The most relevant real-world example of RPC for Web3 developers is JSON-RPC, the protocol every major blockchain uses to expose its state.
When your MetaMask wallet displays your ETH balance, it’s making an RPC call. When a DeFi protocol reads the price from a Uniswap pool, it’s an RPC call. When a trading bot checks the latest block number before submitting a transaction, that’s an RPC call.
Here’s what that call looks like:
// Request: check ETH balance via JSON-RPC
{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0xYourWalletAddress", "latest"],
"id": 1
}// Response from the Ethereum node
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x1BC16D674EC80000"
}The method field is the remote procedure being called. The params are the arguments. The result is the return value. Same pattern as a local function, just over a network.
Here’s a second example: querying the latest block number:
// Request: get current block number
{
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": [],
"id": 1
}Solana uses the same JSON-RPC pattern with its own method namespace. To check a wallet’s SOL balance:
{
"jsonrpc": "2.0",
"id": 1,
"method": "getBalance",
"params": ["YourSolanaWalletPublicKey"]
}Response:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"context": { "slot": 123456789 },
"value": 1500000000
}
}The value is in lamports: 1 SOL = 1,000,000,000 lamports.
Every blockchain uses this same JSON-RPC standard: Ethereum, Solana (boltrpc.io/networks/solana), Polygon (boltrpc.io/networks/polygon), Arbitrum, Base, Avalanche. Your application sends a JSON-RPC request to an RPC endpoint. The node processes it and returns the result.
HTTP vs WebSocket for Blockchain RPC
JSON-RPC runs over two transports depending on your use case:
HTTP: request/response. Best for one-off queries: checking balances, reading contract state, submitting transactions. Each call is independent. Simple to implement, easy to debug.
WebSocket: persistent connection. Best for real-time subscriptions: watching for new blocks, listening for pending transactions, monitoring events. Instead of polling every second, your application receives a push notification the moment something changes.
// WebSocket subscription: get notified on every new block
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_subscribe",
"params": ["newHeads"]
}For DeFi protocols and trading bots, WebSocket is the standard. Polling via HTTP adds unnecessary latency and burns through request limits faster.
Batch Requests: Multiple Calls in One Round Trip
JSON-RPC supports batching: send multiple method calls in a single request, receive all responses at once. This is critical for applications that need to fetch data across multiple accounts or contracts simultaneously.
[
{"jsonrpc": "2.0", "method": "eth_blockNumber", "params": [], "id": 1},
{"jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xAddress1", "latest"], "id": 2},
{"jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xAddress2", "latest"], "id": 3}
]One network round trip instead of three. At scale (a protocol tracking thousands of wallet balances), batching cuts latency and infrastructure cost significantly.
This is why blockchain RPC providers exist. Running your own node to handle these calls is complex, expensive, and requires constant maintenance. An RPC provider like BoltRPC handles the infrastructure so your application just points to an endpoint and calls methods.
For the full JSON-RPC specification, see jsonrpc.org/specification. For Ethereum’s specific RPC methods, see the Ethereum JSON-RPC API docs.
Types of Remote Procedure Call
Not all RPC implementations work the same way. The main types you’ll encounter:
Synchronous RPC
The most common type. The client sends a request and blocks. It waits until the server responds before continuing execution. Standard for queries where you need the result before proceeding (e.g., eth_getBalance before displaying a UI).
Asynchronous RPC
The client sends a request and continues executing without waiting for the response. The result is handled later via a callback or promise. Used in high-throughput systems where waiting wastes cycles.
Callback RPC
The server initiates contact with the client after completing a long-running task. The client registers a callback endpoint; the server calls it when ready. Common in event-driven architectures.
JSON-RPC
A lightweight, stateless RPC protocol using JSON over HTTP or WebSocket. This is the standard for all major blockchain networks. Simple, human-readable, and widely supported across every programming language.
gRPC
Google’s RPC framework using Protocol Buffers and HTTP/2. Over 579 verified companies (including Google, Netflix, Square, Lyft, and Cisco) use gRPC in production. Benchmarks from the gRPC team show it can be 5-10x faster than REST at the 95th percentile for latency-sensitive workloads. Common in microservices and internal server communication. Not used for blockchain node communication: every major blockchain runs JSON-RPC, which is what matters for Web3 development.
RPC vs REST: When to Use Each
RPC and REST are both communication models for distributed systems, but they’re built around different mental models.
| RPC | REST | |
|---|---|---|
| Model | Action / function based | Resource based |
| Protocol | JSON-RPC, gRPC, custom | HTTP |
| Latency | Lower | Higher |
| Coupling | Tight | Loose |
| Best for | Blockchain, microservices, real-time systems | Public APIs, web services, CRUD operations |
| Example call | eth_getBalance(address) | GET /accounts/{address}/balance |
| Error handling | Protocol-defined error codes | HTTP status codes |
Use RPC when:
- You need to invoke specific actions or computations on a remote system
- Low latency is critical (trading, DeFi, real-time data)
- You control both the client and server (internal systems, blockchain apps)
- You’re building on blockchain. JSON-RPC is the standard, not a choice.
Use REST when:
- You’re building a public API that third parties will consume
- You want loose coupling and standard HTTP tooling
- Your operations map cleanly to resources (create, read, update, delete)
- Latency tolerance is higher than for blockchain or trading applications
Blockchain chose RPC over REST for a reason: eth_sendRawTransaction is an action, not a resource. The RPC model fits naturally.
What Are the Disadvantages of Using RPC?
Honest coverage matters. RPC has real trade-offs:
Tight coupling Client and server must agree on the exact method signatures. If the server changes a method name or parameter structure, clients break. This is manageable in internal systems but painful for public APIs.
Harder to debug REST APIs are easy to test with a browser or curl. RPC calls require knowing the exact method name, parameter format, and correct encoding. JSON-RPC is more debuggable than binary protocols like gRPC, but still more complex than REST.
Network dependency If the network fails or the server goes down, the call fails, and failures can cascade through distributed systems. A slow RPC response blocks the calling thread in synchronous implementations.
Protocol overhead JSON-RPC adds serialization/deserialization overhead on every call. At low volume this is negligible. At scale, with millions of calls per second, it matters.
The blockchain trade-off For blockchain applications, these disadvantages are accepted because the alternative (REST) doesn’t fit the action-based nature of blockchain calls. The answer is not to avoid RPC. It’s to choose an RPC provider whose infrastructure handles failures, latency spikes, and scale reliably.
Why Performance Matters in RPC: Especially in Blockchain
At low request volumes, any RPC implementation works fine. At scale, performance becomes the product.
Consider what happens in production blockchain infrastructure:
- A DeFi protocol like a lending platform may execute thousands of
eth_callrequests per second to check collateral ratios across thousands of positions - A trading firm running arbitrage bots needs
eth_getBlockByNumberresponses in under 10ms. A 50ms delay means a missed opportunity and lost revenue. - A wallet application serving millions of users hits
eth_getBalanceandeth_getTransactionCountcontinuously. Slow responses mean a broken user experience.
At this scale, three things determine whether your RPC infrastructure is viable:
- Latency: how fast does each call respond? Every millisecond matters at production scale.
- Throughput: how many calls per second can the infrastructure handle without degrading?
- Reliability: what’s the uptime? A single dropped RPC call during a transaction can cost real money.
BoltRPC processes 2 billion RPC calls daily, trusted by Chainlink, Tiingo, Gains Network, Enjin. Whether you’re running a DeFi protocol, a high-frequency trading system, or a multi-chain application, the RPC layer underneath is not the place to cut corners.
Explore BoltRPC’s supported networks: boltrpc.io/networks
How to Choose a Blockchain RPC Provider
Once you understand what RPC is, the practical question becomes: which provider do you trust with your application’s data layer?
Not all RPC providers are equal. Here are the five criteria that matter:
1. Reliability and uptime Your application is only as reliable as the RPC layer underneath it. A DeFi protocol with a flaky RPC endpoint will fail during the moments it matters most: high network congestion, market volatility, large block events. Look for providers with enterprise-grade infrastructure and independent monitoring.
2. Network coverage If your application is multi-chain, your RPC provider needs to be too. Switching providers per chain adds complexity, inconsistent auth patterns, and multiple billing relationships. A single provider covering Ethereum, Arbitrum, Base, Polygon, Solana, and other chains simplifies your stack.
3. Pricing model transparency Some providers use compute unit weighting where different methods carry different multipliers, and the multipliers can be large. Look for providers with published, fixed weights for every method, so your costs are forecastable before you build.
4. Security and compliance Enterprise teams and institutional DeFi protocols need more than uptime. ISO 27001 certification means the provider’s security practices have been independently audited. Most RPC providers don’t have it. For regulated environments, this is a selection requirement.
5. Support when things break At 3am during a market event, you need someone who answers. Check what support level comes with your plan before you need it.
BoltRPC is trusted by Chainlink, Tiingo, Gains Network, Enjin. ISO/IEC 27001:2022 certified via parent company Matrixed.Link. Flat monthly plan pricing with fixed, published Request Unit weights for every method.
Explore BoltRPC plans and pricing →
FAQ: Remote Procedure Call
What is remote procedure call in simple terms?
RPC is a way for one program to run a function on another computer as if it were running locally. The program sends a request with the function name and arguments, the remote server executes it, and sends back the result. The developer doesn’t write any networking code. The RPC framework handles it.
Is remote procedure call the same as JSON-RPC?
No. JSON-RPC is one implementation of the RPC concept. RPC is the general communication pattern; JSON-RPC is a specific protocol that uses JSON for encoding and HTTP or WebSocket for transport. JSON-RPC is the standard for blockchain networks (Ethereum, Solana, Polygon, etc.).
What is the difference between RPC and API?
An API is a broad term for any interface that lets programs communicate. RPC is a specific style of API design focused on calling remote functions. REST is another API style focused on resources. All RPC systems are APIs, but not all APIs are RPC. A REST API is not an RPC system.
Is gRPC the same as RPC?
gRPC is one implementation of the RPC concept, built by Google. It uses Protocol Buffers for serialization and HTTP/2 for transport. The core concept is the same: calling remote functions. It is commonly used in microservices but is not the standard for blockchain node communication. Blockchain networks use JSON-RPC.
What port does RPC use?
It depends on the implementation. Traditional Windows RPC uses port 135. JSON-RPC for Ethereum nodes typically runs on port 8545 (HTTP) or 8546 (WebSocket). gRPC defaults to port 50051. Managed RPC providers like BoltRPC expose HTTPS endpoints on port 443. No open ports required on your end.
Conclusion
A remote procedure call lets distributed systems communicate by invoking functions across a network as if they were local. It’s the foundation of microservices architecture, internal cloud infrastructure, and, most importantly for Web3 developers, the standard protocol for every major blockchain.
Every Ethereum transaction, every Solana query, every DeFi interaction runs over JSON-RPC. The real question is not whether to use RPC. It’s whether your RPC infrastructure can handle the performance requirements of your application.
For teams building mission-critical blockchain applications, BoltRPC provides enterprise-grade RPC infrastructure at scale, trusted by Chainlink and Tiingo, handling 2 billion calls daily.
Start your free trial, no credit card required: trial.boltrpc.io