PublicNode Rate Limits: What to Expect and How to Plan Around Them

Quick Recommendation: When PublicNode Is Enough and When It Isn't

PublicNode is a free, community-oriented RPC service that supports dozens of chains. For prototyping, hackathons, and low-traffic dApps, it can be a reasonable starting point. But because it's free and shared, it applies rate limits that are often not published in detail. If your app needs consistent throughput, WebSocket subscriptions, or archive data, you should plan for those limits and have a fallback.

Here's a quick decision path:

• Use PublicNode for: development, testing, small personal projects, and non-critical read calls where occasional throttling is acceptable.
• Move to a dedicated or commercial RPC provider when: you're in production, you need predictable performance, you rely on WebSockets for real-time data, or you need archive/trace data.
• Always have a fallback: even if you stay on PublicNode, configure a secondary RPC endpoint so your app can failover gracefully.

If you're evaluating providers, compare rate limits, pricing, and network coverage. OnFinality offers RPC pricing with transparent tiers and supports a wide range of networks.

How PublicNode Rate Limits Typically Work

PublicNode does not publish a single, universal rate limit. Like most free RPC services, limits are applied per IP address and can vary by chain and endpoint type (HTTP vs WebSocket). The exact numbers may change without notice, so you should treat them as "best effort" and design your app to handle throttling.

Common patterns across free RPC services include:

• Requests per second (RPS): a cap on how many requests you can send per second from one IP.
• Requests per time window: e.g., a maximum number of requests per minute or hour.
• Concurrent connections: limits on how many simultaneous WebSocket connections you can open.
• Method-based limits: some heavy methods (like eth_getLogs or trace_*) may have stricter limits.

When you exceed a limit, the server typically responds with an HTTP 429 (Too Many Requests) or a JSON-RPC error. Your client library may also see timeouts or connection resets.

Detecting Rate Limits: Symptoms and Diagnostic Steps

If your app starts failing intermittently, rate limiting is a likely culprit. Here are common symptoms and how to confirm them:

• HTTP 429 responses: the clearest sign. Check your client logs for status code 429.
• JSON-RPC errors: some providers return an error object with a message like "rate limit exceeded" or "too many requests."
• Timeouts: if requests hang and then fail, you may be hitting connection limits.
• WebSocket disconnects: frequent disconnects or inability to subscribe can indicate connection limits.

To diagnose, run a simple load test from your server IP. For example, using curl to send a burst of requests:

for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://rpc.publicnode.com \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
done | sort | uniq -c

If you see a significant number of 429 responses, you've hit the limit. You can also monitor response times; a sudden spike often indicates throttling.

Comparing PublicNode with Other Free and Paid RPC Options

When choosing an RPC provider, you're not just comparing price—you're comparing reliability, features, and support. Here's a practical comparison table:

For production apps, the lack of a documented rate limit and uptime guarantee is a risk. A commercial provider like OnFinality offers predictable limits and support. See our RPC pricing for details.

How to Handle Rate Limits in Your Application

Even if you stay on PublicNode, you can reduce the impact of rate limits with client-side strategies:

• Implement retries with exponential backoff: when you get a 429, wait and retry.
• Cache responses: for read-heavy data like token prices or block numbers, cache to reduce request volume.
• Batch requests: use JSON-RPC batch to send multiple calls in one HTTP request.
• Use WebSockets sparingly: if you need real-time data, consider a dedicated provider for WebSocket connections.

Here's a simple retry example in JavaScript using fetch:

async function rpcCall(url, method, params, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const res = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ jsonrpc: '2.0', method, params, id: 1 })
    });
    if (res.status === 429) {
      const delay = Math.pow(2, i) * 1000;
      await new Promise(resolve => setTimeout(resolve, delay));
      continue;
    }
    return res.json();
  }
  throw new Error('Rate limited after retries');
}

When to Upgrade: Signs You've Outgrown PublicNode

Here are clear signals that it's time to move to a dedicated or commercial RPC provider:

• Your app is in production: free endpoints are not designed for production traffic.
• You're seeing frequent 429s: your user base is growing, and the limits are too tight.
• You need WebSocket reliability: for trading apps or real-time dashboards, dropped connections are unacceptable.
• You need archive data: historical state queries are often not supported on free endpoints.
• You need a support channel: if your app goes down, you need someone to contact.

When you upgrade, you'll want a provider that offers:

• Documented rate limits and fair usage policies.
• Multiple endpoints for failover.
• WebSocket and archive support.
• Transparent pricing.

OnFinality's dedicated node service gives you isolated resources, while our shared RPC offers a balance of cost and reliability.

Migration Checklist: Moving from PublicNode to a Dedicated RPC

If you decide to move, here's a checklist to make the transition smooth:

1. Evaluate your usage: measure your current request volume and methods used.
2. Choose a provider: compare features and pricing. OnFinality supports many networks.
3. Set up your new endpoint: create an API key and get your endpoint URL.
4. Update your app configuration: replace the PublicNode URL with your new endpoint.
5. Test thoroughly: run your test suite and monitor for errors.
6. Implement failover: keep PublicNode as a backup or use multiple endpoints.
7. Monitor performance: track latency and error rates after migration.

Here's an example of updating a wallet or dApp config:

// Before
const RPC_URL = 'https://rpc.publicnode.com';

// After
const RPC_URL = 'https://your-endpoint.onfinality.io';

Key Takeaways

• PublicNode rate limits are real but not always documented; treat them as best-effort.
• Detect limits by watching for 429s, timeouts, and WebSocket disconnects.
• Use client-side strategies like retries and caching to mitigate throttling.
• For production, choose a provider with documented limits and support.
• Always have a fallback RPC endpoint to ensure uptime.

Frequently Asked Questions

What is PublicNode's rate limit?

PublicNode does not publish a single rate limit. Limits vary by chain and endpoint type, and are typically applied per IP address. You may see 429 responses when you exceed them.

Is PublicNode free?

Yes, PublicNode offers free RPC endpoints for many blockchains. However, free services often have stricter rate limits and no uptime guarantees.

Can I use PublicNode for production apps?

It's not recommended. Free public endpoints are shared and rate-limited, which can cause downtime and performance issues. For production, consider a commercial RPC provider like OnFinality.

How do I know if I'm being rate limited?

Look for HTTP 429 responses, JSON-RPC errors mentioning rate limits, or sudden timeouts. You can also run a load test to see when limits kick in.

What should I do if I hit PublicNode's rate limit?

Implement retries with backoff, cache responses, and reduce request volume. If you consistently hit limits, upgrade to a dedicated RPC provider.