Summary
Polygon RPC providers expose JSON-RPC endpoints that let dApps, wallets, and backend services read chain data, send transactions, and interact with smart contracts. Polygon PoS mainnet uses chain ID 137, while Amoy testnet uses 80002. This guide compares public, shared managed, and dedicated access options without vendor rankings. Instead, evaluate providers by production fit: method coverage, rate limits, WebSocket reliability, monitoring, archive and Trace support, and the ability to move from shared to dedicated infrastructure when needed. Public endpoints suit prototyping and low-traffic development; shared managed plans add higher limits and operational visibility; dedicated nodes offer isolated capacity and custom configuration for high-volume or latency-sensitive workloads. Bor and Heimdall serve different layers—Bor handles execution and JSON-RPC, while Heimdall manages consensus and checkpoints. Understanding these roles helps you troubleshoot and plan capacity. Use the decision framework below to match infrastructure to your actual workload, test with Amoy, and review current plan details before production.
Key Takeaways
- Public endpoints are useful for prototyping, while managed and dedicated plans address production limits and isolation.
- Bor handles execution and JSON-RPC; Heimdall handles consensus and checkpoints—most dApp traffic targets Bor.
- Verify rate limits, WebSocket behavior, monitoring, and archive/trace support against your workload before launch.
- Use a production decision framework based on actual traffic, latency, and scaling needs, not a vendor top-10 list.
Polygon RPC nodes and the role of Bor and Heimdall in operations
Polygon operates a dual-layer architecture: Bor is the execution layer that produces blocks and processes transactions, exposing the standard Ethereum JSON-RPC interface used by dApps. Heimdall is the consensus layer that manages validators, checkpoints to Ethereum, and bridge operations. For most developers, only Bor endpoints are needed for RPC calls.
Node operators must maintain both Bor and Heimdall to keep a node in sync. Managed providers abstract this complexity, but understanding the separation helps when diagnosing sync issues or planning dedicated infrastructure. If you run your own nodes, you need both components; if you use a provider, you interact with Bor only.
- Bor: execution layer, handles eth_* JSON-RPC methods, WebSocket subscriptions, and transaction broadcasting.
- Heimdall: consensus layer, manages validator set, checkpoints, and staking; not required for standard dApp RPC.
- Full nodes store recent state; archive nodes keep historical state for deep queries.
- Check /networks/polygon for endpoint details and supported methods.
Rate limits, latency, regions, WebSocket behavior, monitoring, and support
Operational readiness hinges on more than a single fast response. You need to understand request limits, typical latency from your deployment regions, WebSocket subscription stability, and what visibility you have into errors and usage. Public endpoints may not document limits clearly, while managed plans often provide dashboards and support.
Test with realistic traffic patterns: bursts during mints or market events, backend backfills, and sustained WebSocket subscriptions. Check whether the provider offers endpoints in regions near your users or backend workers. Monitoring should show request volume, error rates, and throttling events. Support quality matters during incidents—look for clear escalation paths.
- Rate limits: verify plan-specific limits and whether overages throttle or fail requests.
- Latency: measure from your user and worker regions; consider provider region coverage.
- WebSocket: confirm wss:// support, subscription concurrency, and reconnection behavior.
- Monitoring: request logs, usage analytics, and alerting are essential for production.
- Support: check response times and incident communication before committing.
| Criterion | What to check | Why it matters |
|---|---|---|
| Rate limits | Requests per second/day, per-key vs per-IP, burst allowances | Limits directly affect user experience during traffic spikes. |
| Latency | Response times from your deployment regions | Low, consistent latency improves dApp responsiveness. |
| WebSocket behavior | Connection limits, subscription stability, reconnection guidance | Real-time features require reliable message delivery. |
| Monitoring | Dashboards for usage, errors, and throttling | Visibility helps debug issues before users report them. |
| Support | Channels, SLA (if any), and incident communication | Production incidents need quick resolution. |
Archive and Trace requirements for historical data and debugging
Standard nodes prune historical state, but many applications need access to data at past blocks—for analytics, compliance, or backfilling. Archive nodes retain full state history, enabling methods like eth_getBalance at a specific block or eth_getLogs over large ranges. Trace methods such as debug_traceTransaction or trace_block provide execution-level details for debugging and gas optimization.
Not all plans include archive data or Trace support; often they are add-ons or available only on higher tiers or dedicated nodes. Before building features that rely on historical state, confirm the provider exposes archive nodes and the required trace methods. The /rpc-assistant/polygon-blockchain-api page details available methods for Polygon.
- Archive nodes: store all historical state, required for queries like historical balances and large log ranges.
- Trace methods: debug_traceTransaction and trace_block enable transaction-level debugging.
- Check plan-specific availability: archive and trace may be add-ons.
- Use archive for analytics, indexers, and compliance; use trace for internal debugging.
A practical production decision framework without unsupported vendor rankings
Instead of choosing a provider from a ranked list, follow a workload-first framework. Define the methods you need, estimate traffic, identify latency sensitivity, and determine whether archive or trace is necessary. Then test providers with your actual request patterns, including WebSocket subscriptions and burst traffic. Finally, compare plan limits, monitoring, support, and the path to dedicated infrastructure if needed.
This approach avoids overfitting to marketing claims or a single benchmark. For Polygon, also test Amoy testnet support; a reliable testnet is critical for staging and QA. Use the checklist below as a starting point, and revisit it as your product grows.
- List exact RPC methods, chains, and environments your app will call.
- Test with realistic traffic: bursts, WebSocket subscriptions, and backend jobs.
- Check archive, trace, WebSocket, testnet, analytics, and dedicated-node access.
- Review pricing, usage visibility, and upgrade paths before moving sustained traffic.
- Avoid vendor rankings; focus on workload fit and operational data.
| Criterion | What to check | Why it matters |
|---|---|---|
| Workload fit | Does the provider support all needed methods and environments? | A provider that works for quick reads may fail for wallets, trading, or indexers. |
| Operational visibility | Can you monitor errors, limits, and usage patterns? | Visibility enables proactive debugging and capacity planning. |
| Scaling path | Is there a clear path from shared to dedicated infrastructure? | You shouldn't need a rebuild when traffic or reliability requirements increase. |
Quick start: connect and test Polygon RPC
Use the following examples to verify your endpoint with a simple request. Replace the URL with your own from /networks/polygon or your provider dashboard. For Amoy testnet, see /rpc-assistant/polygon-amoy-guide for endpoint and faucet details.
Test from multiple regions and monitor response codes. If you plan to use WebSocket, test subscription and reconnection separately.
- Use curl for a quick block number check.
- Use ethers.js or web3.js for application integration.
- Always use environment variables for API keys and endpoints.
Frequently Asked Questions
What is the difference between Polygon Bor and Heimdall RPC?
Bor RPC is the execution layer endpoint for standard blockchain interactions like sending transactions and querying state. Heimdall RPC is for consensus layer operations such as staking and governance. Most dApps only need Bor RPC.
Should I use a public Polygon RPC endpoint in production?
Public endpoints are usually rate-limited and lack availability guarantees. They are suitable for development and testing, but production apps should use managed shared or dedicated endpoints for better reliability and support.
How do I know if I need archive data for Polygon?
If your app queries historical state (e.g., balance at a past block, logs across large ranges) or requires trace/debug methods, you need archive node support. Check your provider's plan details for archive availability.
Does OnFinality support Polygon Amoy testnet?
Yes, OnFinality provides Amoy testnet endpoints. See /rpc-assistant/polygon-amoy-guide for current endpoint URLs and faucet details.
What should I evaluate when choosing a Polygon RPC provider?
Evaluate workload fit (methods, chains, traffic), rate limits, latency from your regions, WebSocket behavior, monitoring, support, and the ability to scale to dedicated nodes if needed. Avoid provider rankings; test with your actual patterns.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
