TL;DR

• Solana is a blockchain where applications need a way to communicate with the network.
• RPC (remote procedure call) is the protocol that bridges this gap – it’s the communication layer between your app and the blockchain.
• RPC nodes expose this interface through endpoints (URLs), allowing developers to read on-chain data and broadcast transactions.
• In this guide, we’ll explore how RPC nodes work, the different types of endpoints available, and how to choose the right infrastructure for your Solana application.

Solana RPC explained

Let’s say you've built a UI. You've written a program in Rust or Anchor. You are ready to ship. But for now, your code (frontend) is isolated from Solana (backend). Your app still needs a way to read what's happening on-chain, and submit transactions to the network.

That gateway is remote procedure call. It lets your application call a method on a remote server (an RPC node), and get a structured response back.

In practice, these methods do 1 of 2 things:

• Read state. Query wallet balances, token accounts, programme data, recent blockhashes, signatures, and more.
• Write state. Send transactions, like swaps, mints, or transfers, that change Solana state.

Understanding the key RPC concepts

Here is a clear breakdown of what the core RPC concepts mean.

RPC vs API

RPC is a style of API (application programming interface). You might have used REST APIs before, which are resource-based (GET /users/123). RPC APIs, on the other hand, are action-based (you call a method name with params). On Solana, when builders say “API”, they are usually referring to the JSON-RPC interface.

RPC vs RPC node

RPC is the interface and the methods your app uses to communicate with Solana.

RPC node is the server running Solana node software (such as Agave) that exposes JSON-RPC endpoints for applications to interact with.

For example, when someone says “my RPC is down”, they usually mean their provider’s RPC node isn't responding.

RPC node vs RPC endpoint

RPC node. The machine running the Solana client, with CPU, RAM, and NVMe storage.

RPC endpoint. The URL your app uses to connect to an RPC node, such as HTTP (https://) for request-response calls and WebSocket (wss://) or gRPC streams for subscriptions and streaming.

RPC nodes vs validator nodes

They run the same Solana software, Agave (this is expected to change with the Alpenglow rollout), but are optimised for different workloads.

Validators focus on producing blocks and voting on other block producers’ blocks.

RPC nodes are optimised for serving data and broadcasting transactions to the network for processing.

Simple mental model to understand RPCs

Imagine the Solana ledger (history) as an endless, ancient scroll located inside a great library (the Solana network). Scribes (validators) can write on the scroll (produce blocks) only one at a time (the current leader), while the others watch closely to agree that the history is being written correctly (reaching consensus).

It’s a busy, high-stakes environment inside the library, and normal people (dApps and users) must stay outside the library walls. That’s where the librarians come in (RPC nodes) to act as the critical bridge.

They read the scroll in real time to tell you what’s been written (current state), and they take your requests (transactions) and rush them to the scribe circle to be included in history.

We take pride in being one of the most reliable “librarians” in the ecosystem, but not all providers are equal. If your librarian is slow or overwhelmed, you are left waiting outside the walls (high latency) or facing total silence (downtime). In other cases, you are handed data that's already outdated (stale data) or receive only a fraction of the records you requested (missed slots).

RPC communication methods: HTTP, WebSocket, and gRPC

These are different transports for the same job: reading on-chain state, and interacting with the network.

HTTP RPC

Mechanism. You ask, the node returns a JSON-formatted response, and the connection closes.

Use case. One-off reads and transaction submission.

Trade-off. It’s inefficient for certain workloads. You repeatedly re-fetch unchanged data instead of receiving updates only when events occur, driving up both latency and costs.

WebSocket RPC

WebSockets are still part of the RPC surface, with responses delivered over a persistent connection.

Mechanism. You subscribe, the node pushes JSON-formatted updates as state changes, and the connection stays open until you unsubscribe.

Use case. Real-time UIs, frontends, and notifications.

Trade-off. Connections drop. You need reconnection and backfill logic. Standard WebSockets can have limitations at scale. Some providers use enhanced WebSocket implementations (like Triton’s Whirligig) or alternative streaming protocols (like gRPC) for better performance at high throughput.

gRPC (Geyser-based)

gRPC is a high-performance streaming protocol used with the Geyser plugin interface.

Mechanism. Similar to WebSocket subscriptions, but you receive updates as protobuf messages over a persistent HTTP/2 connection.

Use case. High-throughput dApps, indexers, and latency-sensitive bots.

Trade-off. More engineering work than WebSockets, such as parsing and deserialisation.

Types of Solana RPC endpoints

Choosing your RPC infrastructure strategy

There are 4 primary strategies for accessing Solana RPC nodes, each with distinct trade-offs.

1. Use an RPC provider (most popular)
   • How it works. Sign up, get API keys, and integrate the endpoint.
   • Advantage. Fastest route to production-ready. Higher reliability, higher throughput, support, and often, automatic scaling.
   • Example providers. Triton One (Solana-native); Alchemy and QuickNode (Ethereum-native with Solana support).
2. Run your own Solana validator (self-hosting)
   • When to use. Large exchanges, hedge funds, or teams with dedicated DevOps staff, requiring complete control.
   • Requirements. High-performance hardware (for example, 768GB+ RAM, 4TB+ NVMe), significant initial sync time, and ongoing maintenance.
   • Cost. High operating cost (roughly $3,000–$15,000+/month in resources and staffing).
3. Public endpoints
   • When to use. Only for learning and local development.
   • Limitation. Rate-limited, can be slow and unreliable. Generally not suitable for any live production environment.
4. Hybrid / multi-provider strategy
   • Recommended. Best practice for production apps that demand maximum reliability.
   • How it works. Use multiple providers simultaneously (primary endpoint from one, backup from another), and automatically switch endpoints on failure.
   • Benefit. Eliminates a single point of failure, enables load balancing, and ensures graceful degradation during outages.

Real-world use cases of Solana RPC nodes

RPC nodes are the fundamental infrastructure for almost every on-chain interaction.

• Wallet balance checking. Wallets (like Phantom, Solflare, and Backpack) call RPC methods to instantly fetch and display your SOL and token balances.
• Trading and token swaps. RPC nodes broadcast the signed transaction (via sendTransaction) to the network. Any latency directly impacts execution quality and can be the difference between a successful trade and a failure.
• DeFi protocol queries. Protocols (like lending or AMMs) constantly query programme data via RPC to check collateral health, or accurately price swaps.
• NFT operations and verification. Marketplaces (like Magic Eden, Tensor, and Exchange Art) use RPC calls to verify ownership, fetch metadata, and record purchases.
• Bot operations and arbitrage. High-frequency traders and bots rely on the absolute lowest RPC latency. Even a 100ms difference is critical for capturing opportunities.
• Analytics and indexing. Services (like Solscan, Jupiter Portfolio, and Circular.fi) rely on billions of RPC calls to aggregate historical data and build searchable, human-readable views of the blockchain.

Key decision criteria: what to look for in an RPC provider

Public endpoints are free, but heavily rate-limited, and can get crowded. They're fine for learning and early MVPs, but when you ship a production app, you usually need a private endpoint from a provider.

When choosing an infrastructure partner, consider:

• Consistent low latency. If RPC is slow, your app lags. If you are trading, execution degrades. Tools like Thorofare can help measure this.
• Reliability. If nodes go down, your app goes down. Uptime and failover matter as much as speed (sometimes more, depending on your use case).
• Streaming support. If you are indexing or trading, you’ll probably need gRPC streaming access for high throughput and ultra-low latency.
• Ledger access. If you need deep history (more than 3 epochs), check how the provider serves historical data, and whether ledger streaming is available.
• Support. When things break, you want an engineer on the other side, not a generic ticket loop.
• Pricing clarity. Estimate cost from your actual method mix. If you want predictable spend, look for transparent pricing and overage rules you can model.
• Lock-in. Prefer providers that you can leave. This means they don’t force you into proprietary SDKs or long-term contracts. That 10% discount on a 12-month subscription stops looking good the moment you discover better infrastructure that follows open standards at a cheaper price point.

Frequently asked questions

What is a Geyser plugin?

A Geyser plugin runs inside a validator and streams data out, typically over gRPC. It is used for real-time ingestion and indexing. Many RPC providers use the Yellowstone gRPC protocol (an open-source streaming standard) as their Geyser plugin layer.

Why did my transaction say “sent” but never “landed”?

Submitting a transaction is not the same as confirming it. On Solana, transactions generally face 2 distinct failure modes.

1. Dropped before landing. This typically happens during congestion or due to expired blockhashes (insufficient priority fees are a common culprit). In this scenario, the transaction never touches the chain, and you pay 0 fees.

2. Landed but failed. A transaction can successfully land in a block and still fail execution. This occurs because transaction instructions resulted in error given the current Solana state. Common examples include triggered slippage limits, insufficient balances, or a bot attempting a double spend with a duplicate signature. In these instances, the protocol correctly processes the fee, but aborts the action to protect the state.

By default, RPC nodes simulate transactions and reject invalid ones instantly, ensuring errors cost you nothing. However, developers often enable skipPreflight to shave off milliseconds. This bypasses the safety check, causing the RPC to blindly broadcast a transaction that may fail on-chain – you save a few milliseconds on latency, but you risk paying a transaction fee for a failure record.

Can I use a custom RPC in my wallet?

Most major wallets don’t currently offer direct custom RPC configuration, though many have placed it on their roadmaps. At this stage, Backpack is one of the few that supports it natively.

To set it up: open the Backpack main menu → choose the network → select RPC connection → enter the custom menu → paste your private RPC URL.

What are Solana commitment levels?

Commitment controls how certain you want your read results to be. Solana defines 3 levels.

A transaction is processed when it has been processed by a node and is visible, but not yet confirmed by a supermajority of stake. It is confirmed (the common default for most applications) once the block has been voted on by a supermajority of stake (66%+). It is finalised after 31 or more subsequent confirmed blocks have been built after it.

Higher speed means lower certainty, and higher certainty means more delay.

What are devnet, testnet, and mainnet?

Solana runs multiple clusters for different purposes. Devnet is used for development and experiments. Testnet is mainly used by validators to test upgrades and network changes under realistic conditions. Mainnet is the production network where real assets live. RPC providers typically expose separate endpoints for each cluster.

Should you run your own Solana node?

For most teams, no.

Self-hosting can make sense for large exchanges, market makers, and latency-sensitive bot ops, but it demands constant operational overhead. The burden of upgrades, monitoring, and on-call rotations rarely makes economic sense compared to a provider.

Typical specs for an RPC node:

• RAM. 768GB (ECC preferred)
• CPU. 24+ high-frequency cores
• Disk. 4TB+ NVMe
• Bandwidth. 1Gbps unmetered

Does a private RPC hide my wallet address?

No. Once the transaction is on-chain, it is public. Private endpoints primarily reduce failed submissions and improve execution reliability. They do not provide anonymity.

What are common RPC errors?

• HTTP 429 too many requests. You exceeded a rate limit. Fix with retries and backoff, batching requests, caching results, or upgrading to a private endpoint.
• HTTP 503 / 504 gateway timeout. The node or gateway is overloaded, unhealthy, or offline. Fix with retries and failover logic, and reassess the provider if it happens often.
• -32603 internal error. The node failed internally. Validate parameters, retry the request, and log raw requests if it persists.

We’ve put together a full error list here.