Polygon RPC Nodes: How to Choose and Connect to the Best Endpoints

Understanding Polygon Node Architecture

Polygon is a sidechain-based scaling solution for Ethereum that uses a dual-node architecture: Bor (block producer) and Heimdall (consensus). Bor nodes are responsible for producing blocks and executing transactions, while Heimdall nodes manage the checkpointing and staking mechanisms. For most RPC interactions, developers connect to Bor nodes, which expose the standard Ethereum JSON-RPC interface.

This architecture allows Polygon to achieve high throughput and low transaction costs while maintaining security through periodic checkpoints to Ethereum mainnet. Understanding this structure helps when troubleshooting RPC issues or optimizing node performance.

• Bor nodes: Handle transaction execution and block production; expose JSON-RPC, WebSocket, and gRPC endpoints.
• Heimdall nodes: Manage validator set, checkpointing, and bridge operations; expose REST API and WebSocket endpoints.
• Full nodes store the entire blockchain state and are required for most RPC queries; archive nodes retain historical state for deep data analysis.

Polygon Mainnet and Testnet Endpoints

Polygon mainnet (chain ID 137) is the production network where real assets and applications operate. The testnet, Amoy (chain ID 80002), replaced the older Mumbai testnet and uses Sepolia as its parent chain. Both networks expose RPC endpoints that follow the Ethereum JSON-RPC standard, making it easy to use familiar tools like ethers.js, web3.js, or viem.

When connecting to Polygon, you will need an RPC URL and optionally a WebSocket URL for real-time events. Public endpoints are available for free but often come with rate limits and no guaranteed uptime. For production applications, a managed RPC service like OnFinality provides reliable endpoints with higher throughput and support.

• Mainnet RPC: https://polygon.api.onfinality.io/public (public) or dedicated endpoints via OnFinality.
• Mainnet WebSocket: wss://polygon.api.onfinality.io/public/ws (public).
• Amoy testnet RPC: https://polygon-amoy.api.onfinality.io/public (public).
• Chain ID: 137 (mainnet), 80002 (Amoy testnet).
• Native token: POL (formerly MATIC).

Public vs Private RPC Nodes: Pros and Cons

Public RPC nodes are free and easy to use, making them ideal for development, testing, and low-traffic applications. However, they often impose rate limits (e.g., 10-100 requests per second) and may experience downtime or degraded performance during network congestion. Private or dedicated RPC nodes offer guaranteed resources, higher rate limits, and better reliability, but come at a cost.

For production dApps handling real user transactions, a dedicated node or a managed RPC service is strongly recommended. OnFinality provides both public endpoints for getting started and dedicated nodes for scaling your application.

• Public nodes: Free, no setup, rate-limited, shared resources, suitable for development.
• Private nodes: Paid, dedicated resources, higher throughput, SLA-backed, ideal for production.
• Managed services: Balance of cost and performance; often include load balancing, caching, and analytics.

How to Connect to Polygon RPC Nodes

Connecting to a Polygon RPC node is straightforward using standard Ethereum libraries. Below is an example using ethers.js to connect to the Polygon mainnet via a public endpoint. Replace the URL with your own endpoint from a provider like OnFinality for production use.

Always use environment variables or secure configuration to store your API keys and RPC URLs. For WebSocket connections, use the wss:// protocol to enable real-time event subscriptions.

• Install ethers.js: npm install ethers
• Create a provider: const provider = new ethers.providers.JsonRpcProvider('https://polygon.api.onfinality.io/public');
• For WebSocket: const provider = new ethers.providers.WebSocketProvider('wss://polygon.api.onfinality.io/public/ws');
• Always handle connection errors and implement reconnection logic for production apps.

Key Considerations When Choosing a Polygon RPC Provider

Selecting the right RPC provider is critical for your dApp's performance and reliability. Factors to evaluate include latency (time to first byte), throughput (requests per second), geographic distribution, support for archive data, and pricing model. Some providers offer free tiers with limited usage, while others charge based on compute units or flat monthly fees.

OnFinality offers a global network of Polygon nodes with low-latency endpoints, support for both full and archive data, and flexible pricing plans. You can start with a free public endpoint and upgrade to a dedicated node as your project grows.

• Latency: Choose providers with nodes close to your user base or use geo-routing.
• Throughput: Ensure the provider can handle your peak request volume.
• Archive support: Required if your app needs historical state data.
• Pricing: Compare free tiers, pay-as-you-go, and flat-rate plans.
• Support: Look for 24/7 support and clear SLAs for production use.

Common RPC Methods for Polygon

Polygon RPC endpoints support standard Ethereum JSON-RPC methods, plus some Polygon-specific extensions. The most commonly used methods include eth_blockNumber, eth_getBalance, eth_call, eth_sendRawTransaction, and eth_getLogs. For real-time data, eth_subscribe allows listening to new blocks, pending transactions, and log events.

When using archive nodes, you can query historical state with eth_call at past block numbers. Note that some public endpoints may restrict archive access or charge extra for it.

• eth_blockNumber: Get the latest block number.
• eth_getBalance: Query POL balance for an address.
• eth_call: Execute a read-only contract function.
• eth_sendRawTransaction: Broadcast a signed transaction.
• eth_getLogs: Retrieve event logs for a contract or topic.
• eth_subscribe: Subscribe to newHeads, logs, or pendingTransactions (WebSocket only).

Troubleshooting Polygon RPC Issues

Common RPC issues include rate limiting, connection timeouts, and incorrect chain ID. If you encounter errors like '429 Too Many Requests', you have hit the rate limit—consider upgrading to a higher-tier plan or using a dedicated node. Timeouts may indicate network congestion or a misconfigured endpoint.

Always verify that you are using the correct chain ID (137 for mainnet, 80002 for Amoy) and that your RPC URL is valid. For WebSocket connections, ensure your firewall allows outbound connections on port 443.

• Rate limit errors: Reduce request frequency or upgrade your plan.
• Connection timeouts: Check network connectivity and endpoint URL.
• Incorrect chain ID: Double-check network configuration in your wallet or dApp.
• Missing methods: Some public endpoints disable certain methods; use a full-featured provider.
• Stale data: Ensure your node is fully synced; archive nodes may lag behind.

Frequently Asked Questions