Solana RPC nodes that keep up with mainnet, on bare metal and without a per-call meter
Solana RPC sounds simple until you actually hit it under load. The public endpoint at api.mainnet-beta.solana.com is rate-limited to roughly 40 requests per ten seconds and the docs explicitly say not to use it in production. Every serious app needs a private RPC, and the choice is then which provider routes faster, doesn't drop your getProgramAccounts call after 30 seconds, and supports Jito simulateBundle without a separate plan tier. NoLimitNodes runs RPC on dedicated bare-metal nodes co-located near the validator set. You authenticate with an x-api-key header, you talk to https://rpc.nln.clr3.org, and you get every standard Solana JSON-RPC method plus Jito's bundle endpoints. No per-call surcharge, no method allowlist, no premium tier hiding getMultipleAccounts behind a paywall.
- Solana System Program11111111111111111111111111111111, The on-chain anchor every RPC call ultimately resolves against. Lamport transfers, account creation, nonce advances.
- Vote ProgramVote111111111111111111111111111111111111111, Validator vote transactions. About 70% of mainnet tx volume; you almost always want vote=false in your filters.
- BPF Loader UpgradeableBPFLoaderUpgradeab1e11111111111111111111111, Program deployments and upgrades. Surfaces in getTransaction logs whenever a program redeploys.
The RPC methods you'll actually use
every standard JSON-RPC method plus Jito's bundle endpoints, with real latency numbers
| Event | Type | Description | Frequency | Latency |
|---|---|---|---|---|
| getSlot | instruction | Returns the current slot the validator is processing. The cheapest sanity check; use it as a health probe. | Very high | 8ms |
| getAccountInfo | instruction | Fetches account data, owner, lamports, and rent epoch. Hot-cached on our side, served well under 20ms. | Very high | 15ms |
| getMultipleAccounts | instruction | Batches up to 100 account reads in a single call. Cuts round trips for any indexer or wallet doing portfolio reads. | High | 25ms |
| getProgramAccounts | instruction | Lists every account owned by a program with optional dataSize and memcmp filters. The method most providers throttle; we run it on warm replicas. | Medium | 350ms |
| getSignaturesForAddress | instruction | Walks the transaction history for a pubkey, paginated by signature. Slow to scan a busy wallet; we hold the index in memory. | High | 120ms |
| getTransaction | instruction | Returns a fully decoded transaction by signature. We default jsonParsed encoding so you skip the bincode pass. | High | 35ms |
| getBlock | instruction | Pulls a full block with all transactions, balances, and rewards. The heaviest standard read; pages on our nodes have it warm. | Medium | 220ms |
| sendTransaction | instruction | Submits a signed transaction to the cluster. We forward to the leader schedule with skip preflight optional. | Very high | 18ms |
| simulateTransaction | instruction | Dry-runs a tx and returns logs, fee, and compute units. Use it before sendTransaction on anything user-facing. | High | 22ms |
| getRecentPrioritizationFees | instruction | Returns the prioritization fee landscape for a set of accounts. The right input for any modern compute-budget heuristic. | High | 14ms |
| simulateBundle (Jito) | instruction | Jito-only. Simulates an atomic bundle of transactions. Required for any MEV searcher building on the block engine. | Medium | 45ms |
| getLatestBlockhash | instruction | Recent blockhash plus last-valid block height. The signature-anchor for every transaction you build. | Very high | 9ms |
RPC performance at a glance
last reviewed 2026-04-28
What “Solana RPC” actually means in production
RPC is the HTTP interface a Solana validator exposes so the rest of us don't have to run a node. You POST a JSON body with a method name and parameters, you get back a JSON result. That's the entire contract. The interesting part is which methods exist, how fast they answer, and how the validator behind your endpoint behaves when 200 of those calls land at once.
Solana ships a single canonical method set. getAccountInfo, getBalance, getBlock, getTransaction, getSignaturesForAddress, sendTransaction, and a few dozen more. The spec is on solana.com. Every provider implements the same surface. The differences are which of those calls actually finish under load, which are silently capped at a smaller page size than the spec implies, and whether the operator runs validators close enough to the leader schedule that your sendTransaction doesn't miss the slot.
On NoLimitNodes the URL is https://rpc.nln.clr3.org, the auth is an x-api-key header, and the method set is the full Agave 3.1.x JSON-RPC spec plus the Jito extensions. You don't need a special SDK. @solana/web3.js and solana-py work out of the box.
The methods that actually matter (and the ones that hurt)
The JSON-RPC spec lists about 50 methods. In practice you spend most of your call budget on six or seven, and three of those are the ones that decide whether your provider is real or pretending.
| Method | Used for | Cost shape |
|---|---|---|
| getAccountInfo | Single-account reads, wallets, oracles | Cheap, hot-cached |
| getMultipleAccounts | Portfolio reads, batch lookups | Cheap, batch up to 100 |
| getProgramAccounts | Indexers, full program scans | Expensive, often throttled |
| getSignaturesForAddress | Wallet history, audit trails | Index walks, paginated |
| sendTransaction | Submitting signed txs | Cheap, leader-routed |
| simulateTransaction | Pre-flight, fee estimate, log capture | Medium, runs the BPF |
| getRecentPrioritizationFees | Dynamic compute-budget pricing | Cheap, fixed-window |
The painful one is getProgramAccounts. Without a dataSize or memcmp filter it scans every account a program owns, which on Token-2022 is millions of rows. The public RPC drops the call. Most providers cap it at 30 seconds. We hold the program-account index on warm replicas and serve a filtered call against Token in well under a second. Without a filter, anywhere is going to be slow. Use the filter.
The next one to know about is getRecentPrioritizationFees. If you're still hard-coding compute-unit prices on transaction build, you're paying too much half the time and getting dropped the rest. Pass the writable accounts your tx will lock and read the 75th-percentile fee back. The whole call is under 15ms on our nodes.
Free public RPC vs a private endpoint
The public Solana endpoint at api.mainnet-beta.solana.com is fine for the first hour you spend on Solana. It runs from a single AWS region, it's rate-limited to roughly 40 requests per ten seconds per IP, and the foundation's docs spell out that it's not for production. Devnet gets the same treatment at stricter limits.
The moment your app gets one real user the public RPC stops working. Either you hit the rate limit, or your getProgramAccounts call comes back as 429, or your sendTransaction takes longer than the leader window and your tx never lands. None of those failure modes are bugs. They're the design. The public endpoint exists to keep the foundation's servers from being a free CDN for every wallet on earth.
A private RPC, ours or anyone's, gives you three things the public one doesn't: a request budget that scales with your plan instead of your IP, the heavy methods (program scans, full block reads) actually working, and a routing path that puts your tx submission in front of the next leader instead of through a public fan-out. The only honest reason to keep using the public RPC past development is laziness, and the cost of fixing it is one URL change.
We have a free tier so the cost isn't the blocker. Sign up, get an API key, point your Connection at https://rpc.nln.clr3.org with x-api-key in headers, and you're done.
How NoLimitNodes routes RPC traffic
We don't run on shared cloud VMs. The RPC nodes are bare-metal, NVMe-backed, with the Agave validator pinned to physical cores and the JSON-RPC service running on a separate process group so a heavy getProgramAccounts can't starve the consensus thread. The replicas sit in datacenters near where the leader schedule actually lives, which matters more for sendTransaction than most teams realize.
Reads route through a regional load balancer that knows which replicas have a warm program-accounts index and which ones are catching up. Writes take a different path. sendTransaction goes through a leader-aware forwarder that parallels the submission across the next 4 leaders so a single dropped UDP packet doesn't cost you the slot. If you're using Jito, the same call gets mirrored to the block engine.
The opinion: bare metal still wins on Solana. The validator cares about p99 jitter, NVMe latency, and CPU isolation, not vCPU count. A managed VM that looks the same on paper will lag a few slots behind under load, which shows up as your getSlot reading slot 410205370 while the cluster is at 410205374. We've audited our own fleet against four major providers across a 7-day window; the slot gap matters.
What we don't do: parsed-NFT APIs in the Helius DAS shape. If you need that, Helius is genuinely the right call. We focus the stack on plain JSON-RPC plus Jito plus the gRPC and stream layer on top.
Common RPC failure modes (and how to debug them)
Every team that ships on Solana hits the same four failure modes in roughly the same order. None of them are bugs in the protocol. All of them are fixable in your client.
Rate-limit 429s
You're polling getAccountInfo in a loop. Replace it with accountSubscribe on our WebSocket and the call disappears entirely. Polling at 5 requests per second to 50 wallets is 250 calls per second. A single WS subscription per wallet is zero.
Slot lag
Your getSlot reads older than the cluster head. Usually the provider's replicas are catching up, sometimes your client is reading at finalized when you meant processed. Check both. We surface live replica health on status.
Tx not landing
Your sendTransaction returns a signature but getSignatureStatuses never confirms. Either your priority fee is below the cluster floor, your blockhash is too old, or you're submitting to a replica that isn't the current leader. Use getRecentPrioritizationFees and refresh the blockhash every 30 seconds.
getProgramAccounts timeout
You're scanning a busy program without filters. Add a dataSize matching the account layout and a memcmp on the owner offset. A Token mint scan goes from 30 seconds to 200ms the moment the filters are right.
Two of these (rate-limit 429s and getProgramAccounts timeouts) are signals you should be on a different transport entirely. The right answer for portfolio reads is WebSocket. The right answer for full program scans is gRPC with an accountInclude filter. RPC stays for what RPC is good at: one-shot reads and submitting transactions.
Frequently asked questions
Related products
Real-time push for account changes, logs, and slot progression. The right next step after RPC.
Binary streaming for indexers and HFT. When WebSocket runs out of headroom, this is what you graduate to.
18 curated, decoded topics for Raydium, PumpFun, Orca, and Meteora on top of our gRPC. Skip the IDL step.
Free RPC tier through Ultra at $199/mo. Every plan has Jito bundle support included.
Run your own Geyser plugin on our validators. The next step past managed gRPC.
Get a private Solana RPC endpoint in under 60 seconds
Free tier covers most development. Pro at $49/mo unlocks the higher request budget and Jito bundle routing. Ultra at $199/mo adds dedicated capacity, reserved replicas, and 30 hours of custom dev time.