◆ COMPARE

rpc edge vs public RPC

The free public endpoints are a genuinely good starting point - until you put real volume or real money through them. Here is the honest line between public RPC and a co-located trading stack.

Get Started →View pricing →

◆ THE HONEST READ

Two strong providers, different jobs.

We build for one job - the latency-critical trading path. Solana's public RPC solves a broader set of problems. Here is the fair read of where each one fits.

rpc edge

Built for one job: the trading and HFT niche. The shortest, most predictable path between the cluster and a strategy.

  • Co-located with stake clusters and the Jito Block Engine, with a direct low-hop path to the current leader - public endpoints are generic shared nodes with no proximity guarantee, and proximity is the lever that decides latency.
  • Decoded shreds read first-seen from the propagation layer and aggregated from multiple independent sources, so you act before a block is assembled - public RPC only serves you data at standard commitments, well after the wire.
  • Single-tenant bare-metal on dedicated, so your tail latency is yours alone - public endpoints are shared by the whole ecosystem and will rate-limit or 429 you under load.
  • Flat throughput pricing with included bandwidth in USDC; contractual SLA on Custom/Dedicated. Public RPC is free but offers no uptime guarantee, no support, and no recourse when it throttles you mid-strategy.

Solana's public RPC

Solana's public RPC endpoints (such as api.mainnet-beta.solana.com) are the free, shared mainnet nodes the project runs for the ecosystem. They are great for learning, prototyping, occasional reads, and low-volume scripts - and the docs are clear that they are rate-limited, shared, carry no SLA, and are not meant for production.

// where public RPC is genuinely strong

  • Free, with zero signup or commitment - the fastest possible way to start reading Solana data.
  • Maintained by the project for the ecosystem, so it is a fair, neutral default for docs, tutorials, and examples.
  • Perfectly adequate for prototyping, low-volume scripts, occasional reads, and non-latency-sensitive devnet/testnet work.
  • Always available as a fallback or sanity check without provisioning anything.

◆ SIDE BY SIDE

rpc edge vs public RPC, by dimension.

A table flattens nuance - read it alongside the profiles above. Every cell is publicly known architecture and positioning, with no invented numbers.

Feature comparison of rpc edge and Solana's public RPC across infrastructure dimensions.
Dimensionrpc edgepublic RPC
Center of gravityHFT & trading, co-locatedFree shared dev access
CostPaid - throughput, USDCFree
Rate limitsScoped to your throughputHard per-IP limits, 429s
Reliability / SLASLA on Dedicated/Custom + supportNo SLA, best-effort
Co-location with stake + JitoRacked beside stake + JitoGeneric shared nodes
Decoded shreds (first-seen)Yes, multi-source aggregatedNo - standard commitments only
Yellowstone gRPCYes, on the geyser portNo
Transaction landingDirect-to-leader TPU + JitoStandard, throttled send
TenancySingle-tenant on dedicatedShared by everyone
Best fitDesks, funds, quants, latency-sensitive botsPrototyping, low-volume, learning

◆ WHEN TO CHOOSE WHICH

Match the tool to the job.

Choose rpc edge if…

Choose rpc edge once real volume or real money is on the line: when rate limits start dropping your requests, when you need co-location with stake and Jito, first-seen decoded shreds, single-tenant hardware with predictable tail latency, transactions that land under congestion, and an SLA you can actually rely on.

Choose public RPC if…

Use public RPC if you're prototyping, running very low volume, doing occasional reads, or working on something that isn't latency-sensitive. It's free and it's the right tool for learning and early development - there's no reason to pay for infrastructure before you need it.

// not mutually exclusive - many teams run both, one for the product surface and one for the latency-critical path.

Frequently asked questions

Can I run a trading bot on Solana's public RPC?
You can start one there, but it won't hold up. The public endpoints are rate-limited per IP, shared with the entire ecosystem, and carry no SLA - the Solana docs say plainly they are not intended for production. Under real volume you'll hit 429s and dropped requests at exactly the moments that matter, and you have no co-location, no first-seen shreds, and no support. For a bot whose returns depend on landing transactions fast, that's the wrong foundation. rpc edge exists for that job; public RPC is for getting started.
Why pay for an RPC when the public one is free?
Because free has real costs once you're past prototyping: hard rate limits, no uptime guarantee, no support, shared capacity, and no proximity to the leader. For low-volume or experimental work none of that bites, and you shouldn't pay. For a desk or fund, a throttle or an outage during a move is far more expensive than the bill - that's where co-location, single tenancy, first-seen shreds, and an SLA earn their keep.
What are the rate limits on Solana's public RPC?
The public endpoints enforce per-IP request limits and will return 429 when you exceed them and 403 if your traffic gets blocked, and the limits can change without notice. The exact numbers are published in the Solana docs and are deliberately conservative because the capacity is shared. The practical takeaway is that they're fine for occasional reads and small scripts, but not something to build a high-volume or latency-sensitive workload on.
Is rpc edge just a faster public RPC?
No - it's a different shape of infrastructure. The public RPC is a generic shared node that serves standard JSON-RPC at standard commitments. rpc edge is a co-located, single-tenant trading stack: nodes racked beside stake and Jito, Yellowstone gRPC, multi-source decoded shreds read first-seen from the propagation layer, and a direct-to-leader transaction sender. It's built for the latency-critical path, not as a drop-in upgrade for casual reads.
When should I move off the public RPC?
When you start seeing rate-limit errors, when downtime would cost you money, or when latency starts affecting outcomes - that's the signal you've outgrown shared infrastructure. For app and indexer workloads, a developer platform with a free tier is often the next step. For latency-sensitive trading specifically, the next step is co-located infrastructure like rpc edge, where proximity and first-seen data are the point.

◆ GET ACCESS

Benchmark rpc edge against public RPC.

Public RPC is the right place to start and a fine fallback - free, neutral, and good enough for low-volume work. When rate limits, reliability, or latency start costing you, scope a co-located endpoint with rpc edge. Match the tool to the stakes.

Get Started →Talk to the infra team →

WHERE rpc edge WINS

  • Rate limits
  • Reliability / SLA
  • Co-location with stake + Jito
  • Decoded shreds (first-seen)
  • Tenancy