Logo
RPC Assistant

How to choose a Polygon RPC provider for production apps

Resumen

Selecting a Polygon RPC provider is critical for dApps, DeFi protocols, and infrastructure that depend on reliable access to the Polygon PoS chain. This guide covers evaluation criteria—including rate limits, archive data support, and dedicated node options—and provides a decision framework to match providers to your workload.

Polygon RPC provider decision checklist

Before evaluating providers, clarify your requirements:

  • Traffic volume: Estimate daily request count. Shared RPCs may suffice for under 1M requests/day; dedicated nodes or premium plans are better for higher throughput.
  • Data needs: Do you need archive state (historical balances, logs) or debug/trace methods? Not all providers offer these.
  • Latency sensitivity: Real-time applications (trading, gaming) require consistent low latency. Check WebSocket support.
  • Reliability: Look for providers with multiple endpoints, load balancing, and transparent uptime history.
  • Budget: Compare free tiers, pay-as-you-go, and dedicated node pricing. Factor in overage costs.
  • Support: For production, ensure access to technical support via chat, ticket, or dedicated account manager.

What is a Polygon RPC provider?

A Polygon RPC provider is a service that exposes JSON-RPC endpoints for interacting with the Polygon PoS chain (chain ID 137) and its testnet Amoy (chain ID 80002). Instead of running your own node, you connect to a provider's infrastructure to send transactions, query state, and subscribe to events. Providers handle node maintenance, scaling, and uptime, letting you focus on application logic.

Why your choice of Polygon RPC provider matters

Polygon processes millions of transactions daily. A poorly chosen RPC endpoint can become a bottleneck: rate limits throttle your app during spikes, unreliable nodes cause failed transactions, and missing archive data blocks analytics. The right provider ensures your dApp remains responsive and trustworthy.

Key criteria for evaluating Polygon RPC providers

CriterionWhat to checkWhy it matters
Rate limitsRequests per second (RPS) or daily capExceeding limits causes errors; choose a plan matching your peak traffic
Archive dataSupport for eth_getBalance at historical blocks, eth_getLogs with large rangesRequired for analytics, auditing, and dApp features like historical portfolio views
Debug/trace methodsdebug_traceTransaction, trace_blockNeeded for MEV analysis, gas optimization, and advanced debugging
WebSocket supportWSS endpoint availabilityEssential for real-time event subscriptions (e.g., pending transactions, log filters)
Geographic distributionMultiple regions or edge nodesReduces latency for global user base and improves failover
Uptime SLAreliability expectations percentage (if any)Critical for production apps; verify with independent monitoring
Pricing modelFree tier, pay-as-you-go, dedicated nodeMatch to your budget and scaling needs; watch for hidden overage fees
SupportCommunity vs. dedicated supportProduction apps need responsive support to resolve issues quickly

Types of Polygon RPC providers

Shared (public) RPC endpoints

Free or low-cost endpoints shared among many users. Suitable for development, testing, and low-traffic apps. Limitations include rate limits, no archive data, and potential instability during high demand. Examples include the official Polygon public RPC and community-run endpoints.

Premium shared RPC

Paid plans with higher rate limits, priority access, and often archive support. Good for growing dApps that need more headroom without managing dedicated infrastructure.

Dedicated nodes

A private node (or cluster) reserved for your use. Offers full control over resources, clear rate limits, and consistent performance. Ideal for high-throughput applications, enterprise deployments, and workloads requiring custom configurations.

RPC aggregators / load balancers

Services that route requests across multiple providers for redundancy and failover. Useful for production apps that cannot tolerate downtime.

How to connect to a Polygon RPC provider

Once you have an endpoint URL, configure your Web3 library. Example using ethers.js:

const { ethers } = require("ethers");

// Replace with your Polygon RPC URL
const provider = new ethers.providers.JsonRpcProvider("https://polygon.api.onfinality.io/public");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current block number:", blockNumber);
}

getBlockNumber();

For WebSocket subscriptions:

const provider = new ethers.providers.WebSocketProvider("wss://polygon.api.onfinality.io/public-ws");

provider.on("block", (blockNumber) => {
  console.log("New block:", blockNumber);
});

Common pitfalls and how to avoid them

  • Ignoring rate limits: Always check the provider's rate limit policy. Implement retry logic with exponential backoff.
  • Using public RPC for production: Public endpoints are unreliable under load. Invest in a paid plan or dedicated node.
  • Not testing WebSocket stability: Some providers have flaky WebSocket connections. Test reconnection logic.
  • Assuming archive support: Not all providers offer full archive data. Verify before building features that depend on historical state.
  • Single point of failure: Use multiple providers or a load balancer to avoid downtime.

Troubleshooting Polygon RPC issues

Common errors

  • 429 Too Many Requests: You've hit the rate limit. Reduce request frequency or upgrade your plan.
  • 503 Service Unavailable: Provider overloaded. Switch to a different endpoint or implement failover.
  • Invalid JSON-RPC response: Network issue or malformed request. Check your payload and network connectivity.
  • Nonce too low: Transaction nonce mismatch. Use eth_getTransactionCount with the correct block parameter.

Quick checks

# Test endpoint with curl
curl -X POST https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

When to consider a dedicated Polygon node

Consider a dedicated node if:

  • Your app makes over 10M requests per month.
  • You need consistent low latency for real-time features.
  • You require custom node configurations (e.g., pruning, tracing).
  • You want to avoid noisy neighbors affecting performance.
  • You need full control over node software and upgrades.

Dedicated nodes from providers like OnFinality offer isolated resources, private endpoints, and often include archive data and debug methods.

Key Takeaways

  • Evaluate Polygon RPC providers based on rate limits, archive support, latency, and pricing.
  • Shared RPC is fine for development; production apps need premium or dedicated solutions.
  • Always test WebSocket stability and implement failover for critical applications.
  • Use the decision checklist to match provider features to your workload.
  • For high-throughput or enterprise use cases, consider a dedicated node for maximum reliability.

Frequently Asked Questions

What is the best Polygon RPC provider? There is no single "best" provider—it depends on your traffic, data needs, and budget. Compare features like rate limits, archive support, and pricing to find the right fit.

Can I use a free Polygon RPC for production? Free public RPCs are not recommended for production due to rate limits and potential instability. Use a paid plan or dedicated node for reliable service.

Does OnFinality support Polygon RPC? Yes, OnFinality provides Polygon mainnet and testnet RPC endpoints. Visit the Polygon network page for details and RPC pricing for plan options.

How do I get Polygon testnet tokens? Use the official Polygon Amoy faucet or your provider's faucet if available.

What is the difference between Polygon PoS and Polygon zkEVM? Polygon PoS is a sidechain with its own RPC endpoints (chain ID 137). Polygon zkEVM is a ZK-rollup on Ethereum with separate endpoints. This guide focuses on Polygon PoS.

How can I monitor my Polygon RPC performance? Use tools like Tenderly, Alchemy's dashboard, or custom monitoring with Prometheus to track latency, error rates, and throughput.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar