Polygon Node RPC: Endpoints, Chain Settings, and Provider Selection

Quick decision guide: which Polygon RPC setup fits your app?

Before you copy an endpoint into your config, decide what your application actually needs. The right choice depends on request volume, data depth, and whether you can tolerate rate limits.

• Prototyping or low traffic: a public RPC endpoint is fine. It costs nothing and is enough for wallet connections, simple reads, and test transactions. Expect rate limits and possible downtime during congestion.
• Production app with moderate traffic: a shared or managed RPC service adds reliability, load balancing, and usually WebSocket support. This is the most common choice for dApps, indexers, and backend services.
• High throughput, archive data, or custom needs: a dedicated Polygon node gives you exclusive access, no noisy neighbors, and full control over tracing or historical queries. Use this when you need consistent performance under load.

If you are unsure, start with a managed RPC service that offers both shared and dedicated options. That way you can scale without re-architecting your stack. OnFinality provides RPC services for Polygon and many other networks, with pricing that scales from free public endpoints to dedicated nodes.

Polygon chain settings at a glance

Polygon is an EVM-compatible sidechain that settles on Ethereum. The mainnet and the Amoy testnet have distinct chain IDs and endpoints. Use the correct chain ID in your wallet or dApp to avoid sending transactions to the wrong network.

Note: Polygon migrated from MATIC to POL as the native gas token. Always use POL in your transaction configuration.

What is a Polygon node RPC?

A Polygon node RPC is a server that exposes the Polygon blockchain's data and transaction submission capabilities through the JSON-RPC protocol. Applications send HTTP or WebSocket requests to an RPC endpoint to read balances, query contract state, estimate gas, and broadcast transactions.

Running a full Polygon node yourself is possible, but it requires syncing the entire chain, maintaining hardware, and monitoring uptime. Most developers use an RPC provider to avoid this operational overhead. The trade-off is trusting a third party with your requests, so provider reliability and data accuracy matter.

How to connect to Polygon RPC

You can interact with a Polygon RPC endpoint using any Ethereum-compatible library, such as ethers.js or viem. Here is a basic example using ethers.js:

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

const provider = new ethers.JsonRpcProvider("https://polygon.api.onfinality.io/public");

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

getBlockNumber();

For a raw JSON-RPC call, you can use curl:

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

If you need real-time updates, use a WebSocket connection:

const { WebSocket } = require("ws");
const ws = new WebSocket("wss://polygon.api.onfinality.io/public");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    method: "eth_subscribe",
    params: ["newHeads"],
    id: 1
  }));
});

ws.on("message", (data) => {
  console.log("New head:", JSON.parse(data));
});

Public vs. shared vs. dedicated Polygon RPC

Understanding the difference between public, shared, and dedicated RPC nodes helps you match infrastructure to your workload.

• Public RPC endpoints are free and open to anyone. They are convenient for testing but often have strict rate limits, no SLA, and can become unreliable during network congestion. They are not suitable for production apps.
• Shared RPC services (also called managed or API services) pool multiple users on the same infrastructure. Providers add load balancing, caching, and failover to improve reliability. You get a dedicated API key and higher rate limits than public endpoints, but you still share resources with other customers.
• Dedicated RPC nodes give you a single-tenant node or cluster. You have exclusive access to the node's compute and bandwidth, which means consistent performance and no "noisy neighbor" issues. This is the best choice for high-throughput applications, archive data needs, or custom RPC methods.

How to choose a Polygon RPC provider

When evaluating RPC providers, focus on the criteria that directly affect your application's performance and reliability. Here is a comparison of common provider types:

Key evaluation criteria:

• Uptime and reliability: Look for providers that publish uptime stats or offer SLAs. Avoid making absolute claims; instead, check their status pages and historical performance.
• Rate limits and throughput: Understand the request-per-second (RPS) limits for your plan. Public endpoints often cap at a few requests per second, while dedicated nodes can handle much more.
• Data availability: Do you need archive data (historical state) or trace methods? Not all providers offer these. Check if the provider supports eth_getLogs with large ranges or debug_traceTransaction.
• WebSocket support: For real-time applications, ensure the provider offers a stable WebSocket endpoint.
• Pricing model: Compare per-request, per-RPS, or flat monthly pricing. Estimate your monthly request volume to choose the most cost-effective plan.
• Geographic distribution: Providers with multiple regions can reduce latency for your users.

Setting up a Polygon node with OnFinality

OnFinality offers both shared and dedicated Polygon RPC nodes. To get started:

1. Create an account on the OnFinality platform.
2. Navigate to the Polygon network page and select the network (mainnet or Amoy testnet).
3. Choose a shared or dedicated node plan. For production, a dedicated node gives you a private endpoint and higher throughput.
4. Copy your API key and endpoint URL into your application configuration.

For a dedicated node, you can also enable archive mode to access historical state. This is useful for analytics, indexers, and applications that need past balances or events.

Common pitfalls and troubleshooting

Even with a reliable RPC provider, you may encounter issues. Here are common problems and how to fix them:

• Incorrect chain ID: Using chain ID 137 for Amoy or 80002 for mainnet will cause transactions to fail. Always verify your network configuration.
• Rate limiting: If you see 429 Too Many Requests, you are hitting the rate limit. Reduce request frequency, use batching, or upgrade to a higher-tier plan.
• WebSocket disconnects: WebSocket connections can drop due to network issues or server restarts. Implement reconnection logic with exponential backoff.
• eth_getLogs timeouts: Querying logs over a large block range can time out. Use smaller ranges and paginate.
• Nonce errors: If you send multiple transactions from the same address, ensure you are using the correct nonce. See our nonce guide for details.

Monitoring your Polygon RPC usage

Once your app is live, monitor your RPC usage to avoid surprises. Track metrics like:

• Request volume: How many requests per second/minute are you sending?
• Error rate: Percentage of failed requests (timeouts, rate limits, etc.).
• Latency: Average and p95 response times.
• WebSocket connection stability: How often do connections drop?

Most RPC providers offer a dashboard with these metrics. OnFinality's platform includes usage analytics for both shared and dedicated nodes.

Key Takeaways

• Polygon mainnet uses chain ID 137, and Amoy testnet uses 80002. Always use the correct chain ID.
• Public RPC endpoints are fine for testing but not for production. Use a managed or dedicated service for reliable performance.
• Evaluate providers based on uptime, rate limits, data availability, WebSocket support, and pricing.
• OnFinality offers shared and dedicated Polygon RPC nodes with flexible pricing and multi-network support.
• Monitor your RPC usage to optimize costs and performance.

Frequently Asked Questions

What is the difference between Polygon mainnet and Amoy testnet RPC?

Mainnet RPC connects to the live Polygon network with real POL tokens. Amoy testnet RPC connects to a test network where you can use free test tokens for development. They have different chain IDs and endpoints.

Can I use a public Polygon RPC for production?

It is not recommended. Public endpoints have rate limits and no uptime guarantees, which can cause your app to fail under load. A managed RPC service is a safer choice.

Does OnFinality support Polygon WebSocket?

Yes, OnFinality supports both HTTP and WebSocket connections for Polygon mainnet and Amoy testnet.

How do I get test POL for Amoy?

You can use the official Polygon faucet to request test POL on Amoy. Check the Polygon network page for more details.

What is a dedicated Polygon node?

A dedicated Polygon node is a single-tenant node provisioned exclusively for your use. It provides consistent performance, higher throughput, and optional archive data access.

How much does a Polygon RPC cost?

Pricing varies by provider and plan. OnFinality offers a free public endpoint and paid plans for shared and dedicated nodes. See RPC pricing for current rates.