Solana RPC endpoints explained

What an RPC endpoint actually does

Solana validators run the chain. Your phone does not. Instead, wallets and apps call a remote procedure call (RPC) node that mirrors validator state and forwards transactions. Typical requests include:

• getBalance — how much SOL an address holds
• getTransaction — whether a signature succeeded and what it did
• sendTransaction — broadcast a signed transaction to the network
• getAccountInfo — read on-chain program data (token accounts, NFT metadata, etc.)
• getLatestBlockhash — fetch a recent blockhash so a transaction can be built

The RPC node is a read/write gateway. It does not custody your keys — you still sign locally in Phantom, Solflare, or Backpack — but it is the lens through which software sees the chain. Slow or rate-limited RPC makes the whole experience feel broken even when the network itself is healthy.

Clusters: mainnet-beta, devnet, testnet

An RPC URL always points at a cluster — a separate Solana network with its own validators and its own ledger. Mixing them up is a common beginner mistake.

Mainnet-beta

Real SOL, real NFTs, real payments. Production dApps, exchanges, and games use mainnet-beta. The public endpoint published by Solana Labs is https://api.mainnet-beta.solana.com — useful for quick tests, but heavily rate-limited for production traffic.

Devnet

Free test SOL from faucets, no monetary value. Developers deploy programs here first. Default devnet URL: https://api.devnet.solana.com. If you practice on devnet but visit a live site expecting mainnet, payments will fail silently or show zero balance. See our devnet vs mainnet guide for the full distinction.

Testnet

Validator testing cluster — rarely used by end users. Most wallets expose only mainnet and devnet in settings.

Public RPC vs dedicated providers

Not all endpoints are equal. They differ in rate limits, geographic latency, archive depth (how far back you can query), and WebSocket support for live account subscriptions.

Public / free endpoints

Solana Labs operates public HTTP endpoints for each cluster. They are fine for occasional balance checks or solo development, but shared by millions of users. Under load you will see HTTP 429 responses ("rate limited") or slow getTransaction polling. Browsers hitting public RPC directly from frontend JavaScript is especially fragile — keys in URLs leak in DevTools, and CORS may block requests.

Dedicated RPC providers

Services such as Helius, QuickNode, Alchemy, Triton, and Chainstack run Solana nodes with API keys, higher quotas, and optional extras (parsed transaction APIs, webhooks, enhanced NFT metadata). Production backends almost always use a paid or free-tier dedicated URL rather than the public mainnet endpoint.

Pattern for serious apps:

1. Backend proxy — your server holds the API key and forwards RPC calls; never expose keys in client code.
2. Fallback list — if endpoint A returns 429, retry B before failing the user.
3. Commitment level — use confirmed for UX speed; use finalized for settlement where reorgs matter.

Our own settlement service uses a primary Helius URL with multiple fallbacks — when the first node rate-limits a balance check, it rotates automatically rather than dropping payouts. That is standard production hygiene, not luxury.

HTTP vs WebSocket

Most RPC traffic is HTTPS POST with JSON bodies — one request, one response. For live updates (watch an account balance change, stream slot notifications), clients open a WebSocket to the same provider, often at a wss:// URL. Wallets use WebSockets sparingly; high-frequency trading bots and indexers depend on them. If your dApp only polls getSignatureStatuses every second, HTTP alone is enough; if you need sub-second detection without polling, WebSocket subscriptions reduce load and latency.

When users should change their wallet RPC

Phantom, Solflare, and Backpack let advanced users set a custom RPC URL in network settings. Most people should leave the default alone — wallet vendors already route through reasonably reliable infrastructure.

Consider a custom RPC if:

• Your balance lags minutes behind Solscan while the explorer shows the correct amount
• Transactions confirm on-chain but the wallet UI never updates
• You are in a region where the default node has high latency
• You run a local validator or corporate proxy for compliance

Paste a reputable provider URL (with your own API key if required), select Mainnet Beta, and retry. Wrong-cluster URLs are worse than slow ones — always match mainnet for real money. After changing RPC, verify a small payment with our payment verification walkthrough.

Rate limits and the 429 error

RPC providers enforce per-IP or per-API-key quotas. A 429 Too Many Requests response means "slow down or upgrade your plan," not "your transaction failed." The on-chain transfer may already be final even while your app cannot read it yet.

Symptoms users notice

• Spinner never ends though Solscan shows success
• "Network error" on an otherwise healthy site during busy market hours
• NFT metadata or token list fails to load intermittently

What developers should do

• Cache read-heavy calls (getAccountInfo) with short TTLs
• Exponential backoff on 429; rotate through a fallback endpoint list
• Batch requests with getMultipleAccounts instead of N separate calls
• Never poll faster than you need — confirmation checks every 500–1000 ms are usually enough

Congestion on Solana also affects landing transactions — that is separate from RPC rate limits and is where priority fees help. RPC lag can make a landed transaction look pending; priority fees help it land in the first place.

Commitment levels matter for reads

When you call getTransaction or getSignatureStatuses, you pass a commitment:

• processed — fastest, but a minority of slots can be skipped in edge cases
• confirmed — supermajority voted; good default for games and shops
• finalized — irreversible under normal network assumptions; best for accounting

A dApp waiting for finalized will feel slower than one using confirmed even on the same RPC URL. For typical wait times at each level, see how long Solana transactions take.

Security: RPC is not your wallet

A malicious RPC could lie about balances or censor transactions — theoretically showing fake state or refusing to forward your tx. In practice, reputable wallets and explorers cross-check, and you can always verify signatures on a second explorer. Still:

• Do not paste your seed phrase into any "RPC configuration" page
• Do not install browser extensions that only exist to "optimize RPC"
• Treat unknown RPC URLs like unknown dApps — prefer defaults or named providers

RPC endpoints read public chain data and relay signed transactions; they never need your private key. Anything asking for a mnemonic while claiming to fix RPC is phishing. Broader wallet hygiene lives in our wallet security guide.

Quick reference: choosing an endpoint

Builders shipping wallet-native flows can see how we wire RPC behind nginx in the Garden Dice build log — payment detection, not client-side keys.

Related guides

• Solana devnet vs mainnet explained
• How long do Solana transactions take?
• Solana priority fees explained
• Read a Solana transaction on Solscan