Summary
A Solana RPC URL is the HTTP or WebSocket endpoint your app sends JSON-RPC calls to for reading accounts, submitting transactions, and subscribing to on-chain events. OnFinality exposes a public Solana endpoint at https://solana.api.onfinality.io/public and a matching WebSocket at wss://solana.api.onfinality.io/public-ws, which you can drop into wallets, SDKs, and scripts for testing.
Public endpoints are convenient for development, but production apps usually need dedicated capacity, predictable throughput, and failover. This article covers where the Solana RPC URL goes in common tools, how to verify it works, and when to move from a shared public endpoint to dedicated Solana node infrastructure.
A Solana RPC URL is the address your application uses to talk to a Solana node over JSON-RPC. Instead of running a validator or RPC node yourself, you point your wallet, backend, or script at an endpoint and let it handle getAccountInfo, sendTransaction, getLatestBlockhash, and the rest of the Solana JSON-RPC surface. This page answers the immediate question — what URL do I use — then helps you decide whether a shared public endpoint is enough or whether your workload needs dedicated capacity.
Which Solana RPC URL to use right now
The fastest answer: OnFinality publishes a public Solana mainnet endpoint you can use immediately.
| Setting | Value |
|---|---|
| Network | Solana Mainnet |
| HTTP RPC URL | https://solana.api.onfinality.io/public |
| WebSocket RPC URL | wss://solana.api.onfinality.io/public-ws |
| Native currency | SOL (9 decimals) |
| Block explorer | https://explorer.solana.com |
| Chain ID | Not applicable — Solana does not use EVM-style numeric chain IDs |
That last row matters. If you are coming from Ethereum tooling, you may expect a numeric chain ID for wallet network configuration. Solana identifies its cluster by name (mainnet-beta, devnet, testnet) and by genesis hash, not by a chain ID. Wallet and SDK configuration therefore takes an RPC URL plus a cluster name, not a chain ID integer.
If you are building or testing rather than shipping, use the Solana Devnet RPC endpoint instead so you are not spending real SOL. For a full list of chains OnFinality serves, see supported RPC networks.
Drop the endpoint into your stack
curl smoke test
Before wiring anything into an app, confirm the endpoint responds. Solana uses JSON-RPC over HTTP POST, so a single curl call is enough:
curl https://solana.api.onfinality.io/public \
-X POST \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getHealth"
}'
A healthy node returns {"jsonrpc":"2.0","result":"ok","id":1}. If you get a timeout or a non-200 status, the endpoint is unreachable from your network — check egress rules, proxies, or try a different region.
JavaScript with @solana/web3.js
Most Solana apps use @solana/web3.js. The connection object takes the HTTP URL and, optionally, a WebSocket URL for subscriptions:
import { Connection, PublicKey, clusterApiUrl } from "@solana/web3.js";
const connection = new Connection(
"https://solana.api.onfinality.io/public",
{
wsEndpoint: "wss://solana.api.onfinality.io/public-ws",
commitment: "confirmed",
}
);
const balance = await connection.getBalance(
new PublicKey("11111111111111111111111111111111")
);
console.log("lamports:", balance);
Swap the URL string for your devnet endpoint when testing. The rest of the code is identical, which is one reason Solana developers keep a single connection factory and switch endpoints by environment variable.
Wallet network configuration
Wallets such as Phantom and Solflare let users add a custom RPC endpoint in settings. Provide the HTTP URL and, where the wallet supports it, the WebSocket URL. Users who hit rate limits on a default public endpoint can paste your dedicated URL instead. If you ship a dApp, exposing a configurable endpoint is a small feature that pays off when a shared endpoint is congested.
Public endpoint vs dedicated Solana nodes
The public endpoint is fine for development, demos, and low-volume scripts. It is not designed for sustained high request rates, heavy getProgramAccounts scans, or latency-sensitive trading. Here is how the two options differ in practice:
| Workload signal | Public endpoint | Dedicated Solana node |
|---|---|---|
| Prototyping, one-off scripts | Good fit | Overkill |
| Wallet or dApp with steady user traffic | May hit shared limits | Predictable capacity |
High-frequency sendTransaction | Contention risk | Isolated throughput |
Large getProgramAccounts / getSignaturesForAddress scans | Often throttled | Better suited |
| WebSocket subscriptions at scale | Shared | Dedicated connections |
| Compliance or data-residency needs | Shared infrastructure | Configurable |
If your app is past the prototype stage and you are seeing intermittent 429s, slow getProgramAccounts, or dropped WebSocket subscriptions, that is the signal to move. OnFinality offers both managed RPC API access and dedicated nodes where you get isolated capacity. Pricing scales with the plan you pick — see RPC pricing for the current tiers rather than guessing from a blog post.
Solana JSON-RPC methods you will actually call
Solana's JSON-RPC surface is broad. In production, a handful of methods dominate:
getLatestBlockhash— required before building any transaction; blockhashes expire, so fetch fresh ones.sendTransaction— submits a signed transaction. Returns a signature, not a confirmation.getSignatureStatuses— poll this to confirm a transaction landed.getAccountInfo— read a single account's data and lamports.getProgramAccounts— scan all accounts owned by a program. Powerful and expensive; use filters.getTokenAccountsByOwner— list SPL token accounts for a wallet.getSlotandgetBlockHeight— cheap liveness checks.accountSubscribe/logsSubscribe(WebSocket) — push-based updates instead of polling.
A common mistake is treating sendTransaction as synchronous. It is not. You submit, then confirm via getSignatureStatuses or a WebSocket subscription. Building that confirmation loop correctly is the difference between a reliable app and one that shows stale balances.
Debugging a Solana RPC URL that is not working
When calls fail, the error usually points to one of a few causes. Match the symptom to the likely fix:
| Symptom | Likely cause | What to try |
|---|---|---|
Connection refused or timeout | Wrong URL, blocked egress, or proxy | Re-run the curl test from the same host |
| HTTP 429 | Shared endpoint rate limit | Back off, batch calls, or move to dedicated capacity |
Blockhash not found | Stale blockhash | Fetch a fresh getLatestBlockhash right before signing |
| Transaction never confirms | Dropped or underpriced | Check getSignatureStatuses, resubmit with a fresh blockhash |
| WebSocket disconnects | Idle timeout or network blip | Implement reconnect with backoff; re-subscribe |
getProgramAccounts times out | Unfiltered scan | Add dataSize and memcmp filters |
| Works locally, fails in CI | Environment variable not set | Log the resolved endpoint at startup |
Two habits prevent most of these. First, log the endpoint your app actually resolved — a surprising number of "RPC is down" reports turn out to be a stale environment variable. Second, wrap RPC calls in retry logic with exponential backoff, and treat 429 and 5xx differently from 4xx client errors.
Production readiness checklist
Before you point real users at a Solana RPC URL, confirm the following:
- Endpoint is configurable, not hardcoded. Read it from an environment variable so you can switch providers without a redeploy.
- You have a fallback. A second endpoint — even a different provider — keeps you online if the primary degrades. See how to choose an RPC provider for evaluation criteria.
- Confirmation logic is correct. Do not assume
sendTransactionsuccess means finality. Poll or subscribe. - WebSocket reconnection is handled. Subscriptions drop; your client should re-establish them.
- You monitor error rates. Track 429s, timeouts, and confirmation latency as first-class metrics.
- You know your peak request rate. Compare it to your plan's capacity before launch, not after.
If any of these are missing, fix them before scaling traffic. They are cheaper to address now than during an incident.
When to move to dedicated Solana infrastructure
Shared public endpoints are a starting point, not a destination. Move to dedicated infrastructure when:
- Your request volume is steady and high enough that shared limits become the bottleneck.
- You rely on
getProgramAccountsor archive-style queries that are expensive on shared nodes. - You need predictable latency for trading, liquidations, or real-time dashboards.
- You want isolated WebSocket capacity for many concurrent subscribers.
- You need a support channel and an SLA rather than best-effort public access.
OnFinality provides Solana RPC as a managed API and as dedicated node infrastructure, so you can start on the public endpoint and scale without changing your application code — only the URL. Explore the Solana network page for endpoint details, or review RPC pricing when you are ready to size a plan.
Key Takeaways
- The OnFinality public Solana mainnet RPC URL is
https://solana.api.onfinality.io/public, with WebSocket atwss://solana.api.onfinality.io/public-ws. - Solana does not use EVM-style numeric chain IDs; configure by cluster name and RPC URL.
- Always smoke-test an endpoint with a
getHealthcurl call before wiring it into an app. sendTransactionis asynchronous — confirm viagetSignatureStatusesor a WebSocket subscription.- Public endpoints suit development; dedicated nodes suit sustained, latency-sensitive, or scan-heavy workloads.
- Keep the endpoint in an environment variable and configure a fallback so you can switch without redeploying.
Frequently Asked Questions
Is there a chain ID for Solana?
No. Solana does not use EVM-style numeric chain IDs. Tools identify the cluster by name (mainnet-beta, devnet, testnet) and by genesis hash. When a wallet asks for a chain ID, it is usually an EVM-oriented field that does not apply.
Can I use the same RPC URL for devnet and mainnet? No. Mainnet and devnet are separate clusters with separate endpoints. Use the Solana Devnet RPC endpoint for testing and the mainnet URL for production, and keep them in separate environment variables.
Why does my transaction say "blockhash not found"?
The blockhash you signed against has expired. Solana blockhashes are short-lived. Fetch a fresh getLatestBlockhash immediately before signing and resubmitting.
Do I need a WebSocket URL?
Only if you use subscriptions such as accountSubscribe or logsSubscribe. If you poll with HTTP calls, the HTTP URL alone is sufficient. For real-time apps, WebSockets reduce polling load.
When should I stop using a public endpoint?
When you see recurring 429s, timeouts on getProgramAccounts, dropped subscriptions, or when you need predictable latency and support. At that point, move to dedicated capacity — see RPC pricing and dedicated nodes.
Can I switch providers without changing my code? Usually yes, if you keep the endpoint in configuration rather than hardcoded. Solana JSON-RPC is standardized, so most method calls work across providers. Test WebSocket behavior and any provider-specific extensions before switching in production.