HostHostDeFi › Library › Public vs private RPC
Free RPC vs paid RPC — an honest tier breakdown
Every chain has free endpoints and every provider sells "premium" tiers, and the actual difference between them is poorly documented anywhere. This is the decision page: what a keyless public endpoint really promises (nothing), what paying actually buys (a quota and someone accountable), when per-call metered reads are the right shape, and when you should stop paying providers entirely and run the node yourself.
The three lanes, honest version
Shared / keyless. Public endpoints answer anyone, with no account and no commitment — you get whatever capacity the operator's shared pool has left after everyone else's traffic. It is the correct lane for humans clicking in wallets, hobby scripts, and anything where a 429 is an annoyance rather than a loss. The unwritten terms: rate limits, no uptime promise, and a provider who owes you nothing.
Keyed / subscription. An API key buys a dedicated quota — a stated calls-per-minute or calls-per-month budget, an SLA of some flavor, and usually heavier methods (archive reads, batch calls, trace/debug endpoints) that free tiers exclude. You are paying for predictability, not speed: the same node software answers, but your requests stop competing with the crowd.
Your own node. Full control: archive depth of your choosing, no rate limit but your own hardware, and — the part people forget — nobody else's trust assumption. Also the part people forget first: you now own the ops problem — sync time, disk growth, upgrades, failover.
There is a fourth lane that didn't exist a few years ago: metered per-call reads (x402-style) — pay $0.002 per request at call time, no key, no subscription. It is the missing middle for traffic that is too serious for free and too sparse for a subscription.
What "public" actually guarantees
Let us be blunt about the free tier, because we run one: a public keyless endpoint is best-effort shared infrastructure. Our own relay — /rpc/ — serves JSON-RPC reads across 82 chains without a key, and the honest scope is right in the endpoint's contract: reads only (sends and signs are refused), baseline throughput, first-come-first-served. It is excellent for wallets, explorers, checks, and development. It is not a promise about your production traffic at 3 AM on a Sunday when the market is moving and everyone else just hit the same endpoint.
The failure is never dramatic, which is what makes it dangerous — a free lane under load degrades by slowing, not by erroring: latency climbs, the tip goes stale, occasional 429s appear. Your application keeps "working" while quietly answering with data that's seconds old.
Rate-limit tripwires — how you know you've outgrown free
You don't get a warning email; you get symptoms. The honest list:
— HTTP 429s or silent throttle windows. The obvious one. A free endpoint sheds load by refusing or delaying; if your error budget has one, you're already over.
— Latency that varies by time of day. Shared quota means your P99 tracks other people's traffic, not yours. If your app's tail latency swings with market hours, that's the crowd you're sharing with.
— Archive-depth errors. Free tiers commonly serve recent state only — eth_call at an old block height, or historical balance reads, start failing or returning empty. If your workload reads history, this tripwire arrives fast.
— Stale-tip reads. A load-shedding endpoint can return state a few blocks behind and still look healthy. If you trade, index, or alert on data, measure the tip's lag — it's the cheapest correctness check there is.
— Batch/method restrictions. Free lanes cap batch sizes and exclude heavy methods (trace, debug, some archive forms). If you found yourself splitting calls to fit a limit, the tier is telling you something.
| Shared keyless | Keyed subscription | x402 per-call | Own node | |
|---|---|---|---|---|
| Cost model | Free | Flat fee (ours: $25 one-time) | Per call ($0.002 here) | Hardware + ops |
| Throughput | Shared, contended | Dedicated quota (ours: 3,000/min + batch 100) | Whatever you pay for | Your hardware's ceiling |
| Archive depth | Recent state | Provider-dependent | Provider-dependent | Full — you decide |
| Trust | Provider sees all queries | Same, plus contract | Same, pay-per-call | No third party |
| Ops burden | None | None | None | Sync, disk, upgrades, failover |
| Right for | Wallets, browsing, dev | Bots/backends with steady load | Agents, spiky or tiny workloads | Infra-critical, archive-heavy, sovereignty |
Where metered per-call reads fit
The x402 lane exists for a specific shape: traffic that is real but doesn't justify a subscription — an agent that scans 50 tokens a day, a CI job, a tool that makes a burst of calls once a week. The mechanics: the endpoint answers 402 with a price, the client pays in USDC (our lane settles on Solana via a facilitator, receipt in the response headers), the call returns. No signup, no key to leak, no quota to track. On our relay it's POST /api/v1/x402/rpc/<chain> at a flat $0.002 per call — the pricing manifest is public at /.well-known/x402, and our x402 explainer covers the protocol itself. The honest math: at $0.002/call, $25 buys 12,500 calls — so per-call beats the subscription only below that volume; above it the flat key wins. That crossover point is the decision.
When to run your own node instead
The honest case for self-hosting isn't performance — it's sovereignty and depth: full archive from genesis, zero third-party visibility into your queries, no provider roadmap risk, and reads that never leave your own rack. The honest case against: you now operate stateful infrastructure — sync times measured in days on big chains, terabytes of disk growth, client upgrades on the network's schedule, and a failover story that's your problem. For most teams the right answer is a provider for the lane plus a node for the audit trail — and for almost nobody is it "free tier, but we'll just retry harder." If a silent stall or a wrong answer costs you money, the endpoint is infrastructure; treat it like it. Chains where we run our own validators carry the extra credibility of operating the underlying infra — the footprint is on /validators/.
Try the free lane right now
One call, no key — Solana's current slot off our relay:
curl -X POST https://hostdefi.com/api/rpc/solana -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'
Frequently asked
Is a free RPC endpoint safe to use?
For reads — balances, quotes, history — a reputable free endpoint is fine. The honest limits are availability (shared quota means throttling under load) and honesty (a hostile endpoint can lie about state or log your queries). Anything you're about to sign should go through an endpoint you trust, and anything where a wrong answer costs money deserves a second endpoint's cross-check. Free tiers are infrastructure for humans; production traffic needs a lane someone is accountable for.
What does a paid RPC plan actually buy?
Predictability, mainly — a dedicated quota sized to your traffic instead of a shared pool, heavier methods (archive reads, larger batches, trace/debug) that free tiers exclude, and a service commitment with someone answerable when it breaks. The underlying node software is the same; you're buying out of the contention. On our relay it's $25 one payment (rk1_ key, ~3,000 calls/min, batch 100) — paid once in USDC, no signup, no KYC.
What is x402 and why would I pay per RPC call?
x402 is an open payment-required standard: the server answers HTTP 402 with a price and payment instructions, you pay a tiny amount of USDC, retry the request with the payment proof, and get the resource — no account, no key, no subscription. Per-call pricing wins when your volume is low or spiky: at $0.002/call it beats the $25 one-time key below ~12,500 total calls and loses above it. It's the right shape for agents, one-off scripts, and anything that can't predict its traffic.
How do I know if I'm hitting a rate limit vs the chain being slow?
Check the response, not the vibe. Rate limiting shows up as HTTP 429s, or as a latency cliff that correlates with busy market hours rather than your own load; the chain being slow shows up as uniform slow responses across independent endpoints. The cheap diagnostic: make the same call against two different providers at once — if only one is slow or refused, it's the lane, not the chain. If both return different state, you have a worse problem than rate limits.
What is archive data and when do I need it?
Archive depth = how far back the node can answer historical state queries — eth_call at a two-year-old block, an account's balance at a past height, old logs. Free tiers commonly serve recent state only; if your workload touches history (audits, tax tooling, forensics, indexer backfills), you need an archive-capable lane or your own archive node. It's the first thing to check in any RPC plan, and the usual reason 'the endpoint stopped working' for historical reads.
Should I run my own node instead of paying a provider?
If your queries must be private from providers, you need full archive history, or your volume is large and steady enough that hardware is cheaper than a subscription — yes. The cost is ops: sync time, disk growth, client upgrades, failover. A common honest answer is both: a provider lane for production traffic plus your own node as the independent source you verify critical state against. 'We'll just use the free endpoint and retry' is not a third option — it's the first option failing slowly.