Answers>Learn about RPC & APIs>What is an RPC endpoint?
What is an RPC endpoint?
// Tags
RPC endpointwhat is RPCJSON-RPC
TL;DR: An RPC endpoint is a URL that your application uses to communicate with a blockchain node. RPC stands for Remote Procedure Call, which is a protocol that lets one program request data or actions from another program over a network. In blockchain, RPC endpoints are how wallets check balances, dapps execute smart contracts, and developers read and write onchain data. Every blockchain interaction you have, whether you realize it or not, flows through an RPC endpoint.
The Simple Explanation
When you open a wallet app and see your ETH balance, your wallet is not somehow "on" the blockchain. It is a regular application running on your phone or browser that needs to ask the blockchain what your balance is. To ask that question, it sends a request to an RPC endpoint. The endpoint receives the request, the node behind it looks up the answer, and it sends the response back. Your wallet then displays the result.
Think of an RPC endpoint like a restaurant's front door. The kitchen (the blockchain node) is where the actual work happens: verifying transactions, maintaining state, producing blocks. But you do not walk directly into the kitchen. You enter through the front door (the RPC endpoint), place your order (your request), and a waiter (the RPC protocol) delivers your food (the response). The RPC endpoint is the access point that makes the node's capabilities available to the outside world.
In technical terms, an RPC endpoint is a URL (like https://your-endpoint.quiknode.pro/your-token/) where your application sends HTTP or WebSocket requests formatted according to the JSON-RPC specification. JSON-RPC is a lightweight protocol that defines how to structure requests and responses as JSON objects. Every major blockchain uses some version of this standard, which means once you understand how to make an RPC call on Ethereum, the pattern is similar on Solana, Polygon, Arbitrum, Base, and dozens of other chains.
How RPC Calls Work
A typical RPC interaction follows a simple request-response pattern. Your application constructs a JSON-RPC request that specifies the method you want to call and any parameters it requires, then sends it to the endpoint URL via HTTP POST. The node processes the request, executes the corresponding logic, and returns a JSON response with the result.
For example, to get the latest block number on an EVM chain, your application sends a request with the method "eth_blockNumber" and an empty parameters array. The node responds with the current block number in hexadecimal. To check an account's ETH balance, you call "eth_getBalance" with the wallet address and a block parameter (like "latest" for the current block). To send a transaction, you call "eth_sendRawTransaction" with the signed transaction data.
These standard JSON-RPC methods are defined by each blockchain's specification. Ethereum's JSON-RPC API includes methods for reading block data, querying account and contract state, estimating gas, submitting transactions, subscribing to events via WebSocket, and more. Solana uses a similar but distinct set of RPC methods optimized for its account-based architecture. Each chain has its own API surface, but the underlying communication pattern through RPC endpoints remains consistent.
WebSocket connections are an extension of the basic RPC pattern that enable real-time, bidirectional communication. Instead of your application repeatedly polling the node for updates (which is inefficient and slow), a WebSocket connection lets the node push new data to your
application as it happens. This is essential for use cases like monitoring new blocks as they are produced, listening for specific smart contract events in real time, and receiving transaction confirmation notifications.
Public vs. Private RPC Endpoints
Public RPC endpoints are free, open URLs maintained by blockchain foundations or community projects. Anyone can connect to them without authentication. They are useful for quick testing, prototyping, and educational purposes, but they are not suitable for production applications. Public endpoints are heavily rate-limited (meaning they restrict how many requests you can send per second), frequently overloaded by thousands of concurrent users, and offer no guarantees around uptime, latency, or data freshness. If your application depends on a public endpoint and it goes down during a traffic spike, your app goes down with it.
Private RPC endpoints are dedicated connections, typically provided by an infrastructure service, that are reserved for your application. They offer faster response times, higher rate limits, consistent performance, and uptime guarantees backed by SLAs. Private endpoints often include additional features like token-based authentication, IP whitelisting, analytics dashboards, and access to enhanced APIs beyond the standard JSON-RPC specification.
For any application handling real users, real funds, or real-time data, private RPC endpoints are a baseline requirement, not an upgrade. The difference between a public and private endpoint in production is the difference between a shared public WiFi network and a dedicated fiber line. Both technically connect you to the internet, but only one is suitable for running a business.
Beyond Basic RPC
While standard JSON-RPC methods cover the fundamentals of reading and writing blockchain data, most production applications need more. Enhanced APIs extend the base RPC specification with higher-level methods that aggregate data and reduce the number of calls your application needs to make. Instead of making dozens of individual calls to reconstruct a wallet's token holdings, an enhanced API can return all token balances in a single request.
Streaming and event-driven architectures represent the next evolution beyond request-response RPC. Instead of your application constantly polling an RPC endpoint for new blocks or events, a streaming service pushes data to your application as it becomes available. This reduces latency, eliminates wasted requests, and simplifies your backend architecture.
gRPC is another protocol used alongside or instead of JSON-RPC on certain chains. Solana's Yellowstone gRPC, for instance, provides ultra-low-latency data delivery optimized for high-frequency use cases like trading bots and real-time analytics. gRPC uses Protocol Buffers instead of JSON, which are more compact and faster to serialize, making it ideal for applications where every millisecond of latency matters.
How Quicknode Fits In
Quicknode's Core API provides production-grade RPC endpoints across 80+ blockchain networks. When you create an endpoint on Quicknode, you get an HTTPS and WebSocket URL that connects your application to a globally distributed, high-performance node infrastructure with a 99.99% uptime SLA and response times 2.5x faster than competitors on average. Every endpoint includes full and archive data access, real-time analytics, token-based authentication, and security features like referrer whitelisting and domain masking.
Beyond standard RPC, Quicknode extends the developer experience with Streams for real-time and historical blockchain data delivery, Yellowstone gRPC for ultra-fast Solana data, an ecosystem of Marketplace add-ons for DeFi data, NFT APIs, and security tools, and the Quicknode SDK for streamlined integration in JavaScript and TypeScript. Whether you need a single endpoint for a weekend project or a multi-chain, multi-region infrastructure for an enterprise platform, Quicknode provides the RPC layer that everything else builds on.
What is the difference between an RPC endpoint and a node?
The terms are related but not identical. A node is the software that maintains a copy of the blockchain, validates transactions, and tracks state. An RPC endpoint is the network address you connect to in order to talk to that node. One node can sit behind many endpoints, and one endpoint can route requests across a fleet of load-balanced nodes for redundancy. When you use a managed provider, you interact with the endpoint and never have to operate the node yourself. For a deeper look at what runs behind the URL, see what is a blockchain node, and for the full request lifecycle, see how RPC requests work.
Which RPC transport should you use: HTTP, WebSocket, or gRPC?
RPC endpoints expose more than one transport, and the right choice depends on whether you are making one-off queries or consuming a continuous data feed. HTTP is the universal default for request-response calls. WebSocket keeps a persistent connection open so the node can push updates to you. gRPC offers the lowest latency for high-frequency workloads on supported chains. The table below compares the three at a glance.
Transport
Connection model
Best for
Trade-off
HTTP
Stateless request and response
Standard reads, transaction submission, batch calls
No server push, so you must poll for updates
WebSocket
Persistent, bidirectional
Subscriptions to new blocks, logs, and pending transactions
Connections must be kept alive and reconnected on drop
gRPC
Persistent, streaming with Protocol Buffers
Ultra-low-latency feeds like trading bots and analytics
More complex setup and limited to chains that support it
If your application needs an ongoing feed rather than repeated polling, a managed streaming layer like Quicknode Streams can deliver blocks, receipts, and traces directly to your backend without you managing socket lifecycles.
What causes RPC endpoint latency and rate limiting?
Two factors most often shape the experience of using an RPC endpoint: how fast it responds and how many requests it allows. Latency is driven by geographic distance to the node, the complexity of the method you call, and how busy the underlying infrastructure is. Rate limits exist because every node has finite capacity, so providers cap requests per second to protect shared resources. Understanding both helps you size an endpoint correctly before traffic grows. Learn more in what is RPC latency and what is RPC rate limiting.
When should you use indexing instead of raw RPC?
Raw RPC is ideal for reading current state and submitting transactions, but it struggles with analytical questions like "every transfer this wallet made in the last year." Answering that with RPC alone means thousands of sequential calls. Indexing solves this by pre-processing onchain data into a queryable database, so historical and aggregate lookups return in a single query. Compare the two approaches in RPC vs indexing, and see why large queries are hard in querying blockchain data.
Frequently Asked Questions
What does RPC stand for?
RPC stands for Remote Procedure Call. It is a protocol that lets one program request data or trigger an action in another program over a network as if it were calling a local function. In blockchain, your application uses RPC to ask a node to read state or submit a transaction.
Is an RPC endpoint the same as an API?
An RPC endpoint is a specific kind of API. It exposes blockchain node functionality through the JSON-RPC standard at a single URL. Many providers layer enhanced REST or higher-level APIs on top of the base RPC interface, but the core endpoint is what speaks the JSON-RPC protocol the node understands.
Are free public RPC endpoints safe to use in production?
They are fine for testing and learning, but they are not built for production. Public endpoints are heavily rate-limited, frequently overloaded, and offer no uptime or latency guarantees. If a public endpoint degrades during a traffic spike, your application degrades with it, which is why production apps rely on dedicated private endpoints.
Can one RPC endpoint connect to multiple blockchains?
A single endpoint URL typically maps to one network, such as Ethereum mainnet or Solana mainnet. To support multiple chains you create separate endpoints, one per network. Because most chains share the JSON-RPC pattern, the code you write for one endpoint usually transfers to others with minor changes.
How do I get notified of onchain events without constant polling?
Use a push-based mechanism instead of polling. WebSocket subscriptions and event-driven services such as Quicknode Webhooks notify your backend the moment a relevant block or event occurs, which lowers latency and removes wasted requests. For step-by-step tutorials, the Builders Guide walks through common patterns.
