Free RPC Endpoints: When They Break Down at Scale

TL;DR

Free RPC endpoints are good at what they are for: prototypes, scripts, testnets, and the first months of a product. They break down at scale in five predictable ways: rate limiting, shared-infrastructure congestion, inconsistent or stale data, no SLA or escalation path, and deprecation on short notice. The usual response is to swap the free endpoint for a paid one. That raises the ceiling and leaves the architecture unchanged: still one endpoint, still one point of failure. The more durable move is to keep cheap capacity in the pool, put a routing, failover, and validation layer in front of it, and add caching so you make fewer upstream calls in the first place.

What free and public RPC endpoints are

Two different things get called free RPC endpoints, and the distinction matters once you start hitting limits.

A public RPC endpoint is an unauthenticated URL, usually operated by a chain foundation, a client team, or a community project, that anyone can point a wallet or a script at. There is no signup and no API key. Everyone using it shares the same infrastructure and, in most cases, the same per-IP quotas.

A provider free tier is the entry plan of a commercial RPC service. You create an account, you get a key, and you get an allowance. Sizes vary widely; ethereum.org's node services page lists free tiers ranging from tens of thousands of requests a day to hundreds of millions of compute units a month, depending on the provider.

Teams start on both for good reasons. There is nothing to procure, nothing to expense, and nothing to configure beyond pasting a URL. For read-light workloads they genuinely work. The problem is not that free endpoints are bad infrastructure. It is that the properties you need at scale, predictable throughput, a support path, and a guarantee the URL still exists next quarter, are the exact properties nobody promised you.

Where to find free RPC endpoints

Most teams find their first endpoint through a search result, but a handful of maintained directories do the job better, and it helps to know which kind you are looking at.

Non-EVM ecosystems are less well served. Cosmos has a real community registry, but there is no Solana equivalent to Chainlist; the Solana documentation lists the foundation's own clusters and everything else is vendor roundups.

Separately from the directories, several operators publish free public endpoints of their own. At the time of writing, PublicNode by Allnodes advertises 79 chains, Ankr's public RPC pages cover 80 or more, and 1RPC by Automata covers 63 or more networks behind a privacy-focused relay with a small unauthenticated daily allowance. Most commercial providers also offer a free tier behind an API key, which is a different thing from an open public endpoint even though both end up in the same config file. Several providers publish their own pages titled "chainlist," which catalogue that provider's endpoints rather than aggregating across the ecosystem. Useful, but not a directory in the same sense.

Three things none of these lists tell you. First, whether an endpoint is healthy for your workload: Chainlist's latency and height columns are measured by your own browser when the page loads, which is a single probe from one location at one moment rather than a monitoring history. Second, whether the entry is still current, since directories lag behind reality by their nature. Third, and least obvious, whether two entries are actually independent. Several distinct hostnames can front the same underlying node fleet, so a pool assembled by taking the top four rows of a directory can carry far less redundancy than it appears to. That last point comes back later, when you configure a quorum.

Where free RPC endpoints break down at scale

Rate limiting. The first wall is almost always HTTP 429, and it arrives without warning because the limits are per-IP rather than per-account. Solana's own documentation is unusually specific about this: the public mainnet endpoint caps traffic at 100 requests per 10 seconds per IP, 40 requests per 10 seconds per IP for any single RPC method, 40 concurrent connections per IP, and 100 MB of data per 30 seconds. The same page states plainly that "the public RPC endpoints are not intended for production applications" and that "rate limits may change without prior notice." Most public endpoints enforce something similar; Solana is just candid enough to publish the numbers.

The shape of the failure matters more than the numbers. Rate limits do not degrade smoothly. You are under the limit and everything works, then you are over it and a percentage of calls fail outright. If your client library retries into the same endpoint, you make the congestion worse.

Shared-infrastructure congestion. Per-IP limits assume one IP is one user. In practice your services sit behind a NAT gateway or a small set of cloud egress addresses, so every pod in your cluster shares one budget. On a public endpoint you also share the underlying node fleet with everyone else on the chain, which means your latency during a mint, a liquidation cascade, or a major launch is a function of what strangers are doing, with no signal about it and no lever to pull.

Inconsistent and stale data. A single public hostname is normally a load balancer in front of many nodes. Two consecutive calls can land on two nodes at different block heights. That produces the failure class that costs the most debugging time: a transaction you just broadcast is not visible on the next call, eth_getLogs returns different results on retry, and a balance read disagrees with itself seconds apart. Nothing errored. The data was simply wrong for your purposes, and a plain load balancer cannot tell the difference because a node that is 40 blocks behind still returns HTTP 200. That is the gap health-aware routing exists to close.

No SLA and no escalation path. A free endpoint owes you nothing: no uptime commitment, no support ticket, no one to page at 3am. That is reasonable given the price, and incompatible with a workload where a stalled read costs money. The business impact of RPC failures is rarely the RPC bill. It is the failed transactions, the stuck withdrawals, and the engineering hours spent on incidents a supported provider would have absorbed.

Deprecation on short notice. This is the one teams never model, and it is not hypothetical. In July 2026 the Polygon team announced the deprecation of its public mainnet and Amoy testnet endpoints, including polygon-rpc.com, with the testnet endpoints stopping on 17 July and mainnet on 31 July. That is roughly two weeks of notice for a mainnet URL hardcoded across a large amount of production software, tooling, and documentation. The general lesson holds well beyond Polygon: a URL you do not pay for is a URL somebody else can retire on their own schedule.

A free endpoint is a single point of failure

Strip away the pricing and every one of these failure modes reduces to the same structural fact. When your application has one RPC URL in its config, the availability of that URL is the availability of your product. Free endpoints make this worse in two ways: they are more likely to degrade, and because they cost nothing, the dependency rarely gets the scrutiny a paid vendor would attract in a review.

This is the same problem we covered in the risk of a single RPC provider, and the reasoning does not change when the provider is free. If anything it sharpens. With a paid provider you at least have a contract, a status page, and someone to escalate to. With a public endpoint you have a URL and hope.

Free RPC vs paid RPC is the wrong comparison

The instinct when the 429s start is to upgrade. That is a reasonable step and an incomplete one, because it treats throughput as the only variable. Comparing the three architectures side by side makes the gap visible.

The third column is not "pay more." It is the observation that endpoint quality stops being a procurement decision once something in front of the endpoints is making a routing decision on every call. Cheap upstreams become useful again, because their worst behavior no longer reaches your application.

The graceful path, a layer in front of cheap endpoints

You do not have to throw away the free endpoints. You have to stop trusting any single one of them. Concretely, that means five mechanisms, all of which live in an RPC proxy layer rather than in your application code.

Failover, so one endpoint failing is not one product failing. Smart Router's failover pipeline composes five policies. Retry rotates to a different node on retryable errors, tolerating a configurable count that defaults to two. Hedging fires a parallel attempt when a request has not returned within a tick and takes whichever response arrives first. Timeouts bound both each attempt and the overall request, so a hung upstream cannot hold your caller. Integrity runs a lag check before selection, so an out-of-sync node is skipped rather than tried and discarded. A circuit breaker trips the relay early when the pool is exhausted instead of retrying forever. A 429 becomes a routing event rather than an incident.

Health-aware and cost-aware selection. Rotating blindly through endpoints of wildly different quality just spreads the pain evenly. Selection policies score each upstream on observed latency, sync freshness, and availability, then pick per request. The strategy is configurable, and one of the available strategies optimizes for cost per compute unit, which is precisely the behavior you want with a mixed pool: send the bulk of traffic to the cheap upstreams while they are healthy, and let the expensive ones earn their keep during spikes and degradations.

Caching, because the cheapest call is the one you never make. Rate limits are a volume problem, so the highest-leverage fix is volume reduction. Smart Router's cache is block-aware rather than a blunt TTL: entries are keyed by chain, API interface, method, params, and resolved block, and lifetime follows finality. A call against a block at or beyond the chain's finalization distance is immutable and held long-term, one hour by default. Latest-style reads get 500 milliseconds by default, enough to deduplicate bursts without serving anything meaningfully stale. Block-hash-to-height mappings are held for 48 hours, and writes are never cached. The cache runs as its own process and can be shared across router instances, so a fleet of services deduplicates against one another rather than each burning quota separately. How much this saves depends on workload shape: repetitive historical reads benefit heavily, a pure write path barely notices.

Cross-validation for the calls where being wrong is expensive. Failover answers "did we get a response." It does not answer "was the response correct," which is the exact weakness of a shared public endpoint whose nodes you cannot inspect. Cross-validation sends the same request to several upstreams in parallel and returns only once enough of them agree, governed by MaxParticipants and AgreementThreshold. It is off by default, at 1 and 1, because fanning out multiplies upstream cost, so you enable it where it pays: the docs recommend it for critical writes, eth_getLogs ordering, and eth_call at fixed blocks, and recommend against it for latest-block reads and non-deterministic methods. Group diversity is the part that matters most with free endpoints. Label upstreams by their underlying source and require a quorum to span distinct groups, and three endpoints that turn out to resell the same fleet cannot outvote the truth.

Observability, so you see which endpoint is degrading before your users do. Once all RPC traffic passes through one layer, one place can measure per-upstream latency, error rate, lag behind the head, retry and hedge counts, cache hit rate, and cross-validation mismatches. Prometheus series such as smartrouter_cross_validation_mismatch_total turn "one of our endpoints is serving bad data" from a hypothesis into an alert. Which of these signals deserve a page is covered in monitoring RPC health.

The mechanics behind each of these terms, retry versus hedging, integrity versus cross-validation, quorum and group diversity, are defined in the RPC reliability glossary.

What this looks like in practice

The end state is not "we replaced our free endpoints." It is a list of upstreams in a config file, mixing public endpoints, provider free tiers, paid plans, and any self-hosted nodes you run, with one URL exposed to your applications. Smart Router is one implementation of that layer: open source, chain-agnostic across EVM and non-EVM networks, deployable as a Docker image, a Helm chart, or a static binary, and provider-agnostic by design so it sits in front of whatever you already use rather than replacing it.

Adding a second and third upstream is then a config change rather than a project. That is the actual difference between a free endpoint being a dependency and a free endpoint being one option among several.

Smart Router is open source. You can deploy it in front of the endpoints you already use, free ones included, or talk to us about the enterprise edition.

Sources: Solana clusters and public RPC endpoints; Deprecation of Polygon's public RPC endpoints; ethereum.org nodes as a service; Chainlist; ethereum-lists/chains; CompareNodes; Cosmos chain-registry; Smart Router failover; Cross-validation; Caching; Selection policies.