Public RPC Endpoints: Limits and Fallbacks

Public RPC endpoints let anyone read blockchain data without signing up. They are perfect for prototypes, hobby projects and light production use. They also come with limits that surprise developers the first time a query fails in production. Knowing those limits in advance lets you design around them.

Rate limits

Public endpoints restrict how many requests a client can send in a period. Limits vary by provider and are not always documented. When you exceed them, you may receive HTTP 429 errors, JSON-RPC errors or silently slower responses.

To stay within limits:

• Cache results that do not change, such as confirmed receipts
• Avoid polling faster than the network produces blocks
• Batch reads where the provider supports it
• Throttle background jobs

Block range caps for logs

Log queries are the most common cause of failures. Many providers cap the number of blocks in a single eth_getLogs request. Some allow a few thousand blocks, others allow tens of thousands, and some public endpoints allow only small ranges.

The cap interacts with block time. A network producing a block every quarter second covers far fewer minutes per thousand blocks than a network producing one every twelve seconds.

Handle caps by querying in chunks:

1. Store the last block you scanned
2. Query the next chunk up to the provider's limit
3. Process results, then move to the next chunk
4. Stop after a fixed number of chunks per run to bound execution time

Archive data gaps

Many public nodes keep only recent state. Queries for old balances or historical contract state can fail with errors mentioning archive data. Some providers require a personal token for historical requests.

If your app needs deep history, use a provider that offers archive access, or rely on an indexing service. For payment detection, which only needs recent blocks, standard nodes usually suffice.

Reliability and consistency

Public endpoints can go down, lag behind the chain head or return slightly different latest block numbers than other providers. Load balancers may send consecutive requests to different backend nodes, which occasionally produces inconsistent results.

Design for that:

• Treat the latest block as approximate, and wait for confirmations
• Make processing idempotent so repeated checks do not create duplicate records
• Log provider errors with enough detail to spot patterns

Designing fallbacks

A simple fallback strategy covers most failures:

Strategy	How it works
Ordered list	Try the primary provider, then the next on error
Health tracking	Skip providers that failed recently for a short period
Per-method choice	Use providers with larger log ranges for log queries
Timeouts	Abandon slow requests quickly and move on

Keep fallback lists in configuration rather than code, so you can update providers without redeploying logic.

Testing limits yourself

Before relying on an endpoint, test it:

• Query logs across increasing block ranges until you hit the cap
• Request an old block to see whether archive data is available
• Send a burst of requests to observe rate limiting behaviour
• Compare latest block numbers with another provider

Write the results into your configuration, including a safe chunk size per network.

When to pay for a provider

Paid providers offer higher limits, archive access, better support and service level commitments. Consider upgrading when failures start affecting users, when you need history or when request volume grows. Keep a public endpoint as a fallback even then.

Proud Globe checks payments on six networks using public endpoints with per-network chunk sizes and fallbacks, all defined in one configuration file. Every tile order is detected through that setup.