Summary
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
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | Requests per second (RPS) or daily cap | Exceeding limits causes errors; choose a plan matching your peak traffic |
| Archive data | Support for eth_getBalance at historical blocks, eth_getLogs with large ranges | Required for analytics, auditing, and dApp features like historical portfolio views |
| Debug/trace methods | debug_traceTransaction, trace_block | Needed for MEV analysis, gas optimization, and advanced debugging |
| WebSocket support | WSS endpoint availability | Essential for real-time event subscriptions (e.g., pending transactions, log filters) |
| Geographic distribution | Multiple regions or edge nodes | Reduces latency for global user base and improves failover |
| Uptime SLA | reliability expectations percentage (if any) | Critical for production apps; verify with independent monitoring |
| Pricing model | Free tier, pay-as-you-go, dedicated node | Match to your budget and scaling needs; watch for hidden overage fees |
| Support | Community vs. dedicated support | Production 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. Useeth_getTransactionCountwith 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.