Every developer starts on free RPC, and most production incidents we hear about start there too. Not because free endpoints are bad — some are excellent — but because "free" covers at least four different deals, each with different limits and, more importantly, different failure modes that only show up under load. We operate infrastructure that talks to hundreds of endpoints across 75+ chains, so we see these failure modes professionally. Here's the field guide.
The four kinds of free
1. Public endpoints. The URLs on Chainlist, in chain docs, or baked into wallets: official foundation RPCs (mainnet.datarpc.io, rpc.monad.xyz), community nodes, and the public gateways some commercial providers run. No signup, no key, no contract — and no promises.
2. Provider free tiers. A real account with a real key, capped: Alchemy meters ~300M compute units a month, Infura uses a daily credit bucket, Ankr's freemium plan allocates method-weighted credits. (We've written deep dives on compute units, API credits, and daily caps — the metering math is its own topic.)
3. Keyless access. A small category we just joined: endpoints from commercial providers that answer without any signup, throttled per IP. https://rpc.swiftnodes.io/rpc/eth works in a bare curl now — free-tier rate, no account.
4. "Free" that's actually rationed. Trial credits, time-boxed tiers, or free tiers that quietly require a card. Read the fine print; a free tier that expires is a trial.
The limit models, compared
| Model | Typical shape | What breaks first |
|---|---|---|
| Requests per second | 2–25 rps per key or IP | Bursts: your indexer backfill or a traffic spike hits 429s immediately |
| Daily credit bucket | N credits, resets midnight UTC | Availability: one busy afternoon and you're dark until midnight |
| Monthly credits/CU | N units/month, method-weighted | Budget math: a debug_trace or wide eth_getLogs costs 10–100× an eth_call
|
| Monthly request cap | Flat N requests/month | Predictable — the easiest model to reason about (it's what our free tier uses: 250k/month) |
The key insight: rate limits and volume caps fail differently. A rate limit degrades your app during bursts but recovers in seconds. A drained daily bucket takes your app offline for hours. A method-weighted budget fails as a surprise bill or a mid-month cutoff. Pick the failure mode you can live with.
The limits nobody documents
These are the ones that actually cause the 2am incidents, and they mostly apply to public endpoints:
-
Method restrictions. Many public endpoints reject
eth_getLogswithout an address filter, cap ranges tightly (our range-caps guide), or don't servedebug_/trace_at all. The error often looks like your bug ("method not found") rather than a policy. - Archive gating. Requests touching old state suddenly return "archive requests require a personal token" — we've watched a public endpoint silently break a payment-processing pipeline this way for weeks, because the cursor fell behind and every catch-up query became an "archive" query.
- IP and provider blocks. Public endpoints block cloud-provider IP ranges without notice. Your laptop works; your server doesn't. We've measured the same endpoint serving one of our data centers and rejecting another.
- Staleness. A public node can respond fast and still be hours behind the chain tip — a liveness check is not a freshness check. Nobody alerts you; your app just reads old state.
- Disappearance. Public endpoints die when their operator loses interest or the chain's economics change. There is no deprecation notice, just connection refused one morning.
None of this is villainy — running free public infrastructure is expensive, and operators protect themselves however they can. But every one of these is invisible on the day you integrate and expensive on the day it triggers.
How to choose
- Prototyping, learning, low-traffic scripts: public or keyless endpoints are genuinely fine. Add retry logic with fallback endpoints and you're covered.
- Anything with users: get a key — any provider, including free tiers. A key gets you a rate limit that's yours instead of shared with the internet, and a dashboard that tells you when you're near a cap.
- Indexers, bots, log-heavy or trace-heavy workloads: model the metering before choosing. This is where method-weighted credit systems produce surprise costs, and where flat-rate pricing (metered by nothing) or a plain request cap is easiest to predict.
- Whatever you choose: treat the public-vs-paid decision as reversible. Abstract the endpoint URL into config on day one and switching costs you nothing later.
Try the keyless tier
The fastest way to evaluate any provider is a request that costs you nothing — not even a signup:
curl -X POST https://rpc.swiftnodes.io/rpc/eth \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
That works on any of our 75+ chains (/rpc/base, /rpc/solana, /rpc/polygon…), throttled per IP at free-tier rates. When you want your own limits, the free tier is 250,000 requests a month with a key, no card and no KYC — and paid plans are flat-rate: the one pricing model where this entire article's metering math stops mattering.
Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.
