Solana RPC explained: nodes, endpoints, providers — how wallets talk to the chain
What a Solana RPC node is and how wallets talk to the chain through endpoints — public vs. dedicated, rate limits, privacy, and WebSockets.
When your wallet shows a balance or you send a transaction, the app does not talk to the blockchain directly — it talks to an RPC node. RPC stands for Remote Procedure Call: the interface through which programs query data from Solana and submit transactions. Every wallet, every dApp, and every bot needs an RPC endpoint for this — a URL behind which such a node runs.
Short answer: A Solana RPC node is a server that holds the current state of the chain and answers requests: balances, transactions, program data. It runs the same software as a validator but typically does not participate in consensus. Wallets and apps connect to it through an endpoint (a URL) — public and rate-limited, or dedicated via commercial providers.
In plain terms: The RPC node is the switchboard between you and Solana. Your wallet calls in, asks “how much SOL sits on this address?” — and hands your signed transactions on to the network.
What an RPC node is
An RPC node is a full Solana node that follows the chain live and exposes a JSON-RPC interface to the outside. Methods like getBalance (balance of an address), getAccountInfo (data of an account), getTransaction (details of a transaction), and sendTransaction (submit a signed transaction) run over this interface.
The endpoint is simply the address where this node can be reached — for example https://api.mainnet.solana.com. When you look up a transaction in an explorer, the same thing happens under the hood: an explorer is ultimately a user interface on top of RPC data (plus its own indexes).
RPC node vs. validator: same software, different job
An RPC node and a validator run the same node software. The difference is the role:
- A validator participates in consensus: it votes on blocks and produces them when it is its turn. How to pick a good one as a staker is covered in our article on validator selection.
- An RPC node, per the Anza documentation, typically runs with the
--no-votingflag — it follows the chain but does not vote. Its resources go into answering queries.
Running both on one machine is considered bad practice: consensus work and query load compete for the same resources. In the standard setup, the RPC interface listens on port 8899.
Some RPC nodes additionally keep the complete transaction history (“full history”) — that requires far more storage than normal operation, where older data drops out of the local ledger.
Why every wallet uses an endpoint
A wallet stores your keys — nothing more. Everything it shows you has to be queried somewhere: balances, token holdings, NFT images, transaction status. This data arrives through the RPC endpoint the wallet is preconfigured with. Sending works the same way: the wallet signs locally and hands the transaction to the RPC node via sendTransaction, which forwards it to the block producer currently in charge.
In practice this means: there is always a server between you and the chain, and someone operates it. Which one is the wallet vendor’s decision — most major wallets use commercial RPC providers behind the scenes. Some wallets let you enter a custom endpoint in the settings.
Public vs. dedicated endpoints
Roughly, there are three tiers:
- Public endpoints: Solana provides one per network — for mainnet that is
https://api.mainnet.solana.com(long known asapi.mainnet-beta.solana.com; both addresses respond). Free, but strictly rate-limited and without availability guarantees. Good for trying things out, unsuitable as the backbone of an app. - Shared provider endpoints: Commercial RPC providers operate node fleets and sell access via API keys — with higher limits, uptime commitments, and often extra APIs beyond the RPC standard. This is the tier where most wallets and dApps live.
- Dedicated nodes or self-hosting: Whoever needs maximum control — indexers or latency-critical applications, for instance — rents an exclusive node or runs one themselves. That costs real hardware and upkeep but removes the middleman.
Providers differ in price, latency, regions, and extra features — we deliberately skip a ranking here: the category matters more than the name.
Rate limits: the public endpoint’s numbers
For the public mainnet endpoint, Solana documents (as of July 2026) these limits, among others — with the explicit note that they are subject to change:
- A maximum of 100 requests per 10 seconds per IP
- A maximum of 40 requests per 10 seconds per IP for a single RPC method
- A maximum of 40 concurrent connections per IP
- A maximum of 100 MB of data per 30 seconds
For comparison: a single wallet interface with a handful of token accounts easily fires a dozen queries on opening. For an app with many users, the public limits are exhausted within minutes — which is the real reason the provider market exists.
Privacy: your RPC sees you
A point rarely spelled out: the operator of your RPC endpoint sees your IP address and every single query. Quite a lot can be read from that:
- Which wallet addresses you query regularly — presumably your own
- Which tokens and programs you are interested in
- When you are active and from where (IP geolocation)
- Which transactions you send, before they are confirmed
This is not an accusation against any particular provider but a structural property of the model: whoever answers the requests knows the requests. If you want to minimize it, you have three levers — run your own node, choose providers based on their privacy policy, or decouple your IP (via VPN, for instance) from your wallet behavior.
WebSockets and subscriptions, briefly
Beyond the request-response pattern over HTTP, the RPC interface offers a WebSocket channel: instead of asking over and over (“polling”), you subscribe to events and get them pushed. The Solana docs list methods like accountSubscribe (an account changes), logsSubscribe (program logs), signatureSubscribe (a specific transaction gets confirmed), and slotSubscribe (new slots).
That is exactly how your wallet shows the “confirmed” checkmark without asking every second. For anything event-driven — price updates, bot triggers, live dashboards — subscriptions are the clean way.
Where RPC is heading
Two directions are currently visible. First: the Solana Foundation announced RPC 2.0 in spring 2026 — a reworked read layer meant to improve latency, cost, and query expressiveness, and to standardize parts of what providers built as custom extensions. A final specification is still pending.
Second, the transport layer is moving: providers are modernizing the connection layer beneath the API — for example with HTTP/3 and QUIC, which is most noticeable on mobile and unstable connections, without changing the RPC methods themselves.
At a glance
- RPC is the interface between apps and Solana — every wallet uses an endpoint.
- An RPC node runs validator software but typically without participating in consensus.
- Public endpoints are free and tightly rate-limited; production apps run on providers or their own nodes.
- The RPC operator sees IP and queries — an often overlooked privacy point.
- WebSocket subscriptions replace polling; RPC 2.0 is set to modernize the read layer.
Note: Not financial advice.
Sources
- Solana documentation — Clusters & public RPC endpoints
- Solana documentation — RPC WebSocket API
- Anza documentation — Setup an RPC Node
Related articles
- What is Solana? — the basics of the chain
- Solana validator selection — the consensus side of the same software