Solana

Solana Beta is live. Try BoltRPC Solana endpoints free - start your trial now.

Polygon RPC Guide: How to Connect and Build on Polygon (2026)

A complete 2026 developer guide to Polygon RPC endpoints. Learn how to connect with ethers.js and Web3.py, use key JSON-RPC methods, fix common issues, choose a reliable provider.

BoltRPC
BoltRPC Team
9 min read
Polygon RPC Guide: How to Connect and Build on Polygon (2026)

Polygon RPC Guide: How to Connect and Build on Polygon (2026)

Polygon is one of the most widely used EVM-compatible networks, offering fast block times and low transaction costs compared to Ethereum mainnet. To interact with Polygon programmatically, whether reading balances, sending transactions, or subscribing to events, you need an RPC endpoint. This guide covers everything a developer needs to connect to Polygon, use its JSON-RPC methods effectively, avoid the most common pitfalls in production.

What is a Polygon RPC Endpoint

An RPC (Remote Procedure Call) endpoint is a URL that gives your application access to the Polygon network. Instead of running a full node yourself, you send JSON-RPC requests to a provider’s infrastructure and receive responses in real time.

Polygon supports two connection types:

HTTP (HTTPS): Best for stateless, request-response interactions. Use this for reading data (balances, contract state, transaction receipts) and submitting transactions. HTTP is simpler to work with and sufficient for most use cases.

WebSocket (WSS): Best for persistent, event-driven connections. Use this when you need to subscribe to new blocks, pending transactions, or contract events via eth_subscribe. WebSocket keeps a long-lived connection open so the node pushes data to your app as it happens, rather than requiring you to poll repeatedly.

Rule of thumb: use HTTPS by default, switch to WebSocket when you need real-time event subscriptions.

Public Polygon RPC Endpoints

The following public endpoints are available for testing and exploration. Do not use them in production.

NetworkRPC URLChain ID
Polygon Mainnethttps://polygon-rpc.com137
Polygon Amoy Testnethttps://rpc-amoy.polygon.technology80002

Public endpoints are rate-limited and run on shared infrastructure. They are suitable for local development and quick tests, but will throttle under production load. For any application with real users or meaningful transaction volume, use a dedicated authenticated endpoint from a provider like BoltRPC.

Polygon RPC Methods: What You Need to Know

Polygon is fully EVM-compatible, so the standard Ethereum JSON-RPC spec applies. These are the methods you will use most often:

eth_getBalance: Returns the MATIC (or POL) balance of an address at a given block. Use "latest" for the current balance.

eth_call: Executes a read-only smart contract call without submitting a transaction. Use this for view and pure functions.

eth_sendRawTransaction: Broadcasts a signed transaction to the network. This is the method your wallet or signing library calls after building and signing locally.

eth_getLogs: Fetches event logs matching a filter (address, topic, block range). This is the backbone of event-driven applications on Polygon. Note that public endpoints typically enforce a block range limit on eth_getLogs queries. Keep your ranges to a few thousand blocks per request to avoid errors.

eth_subscribe: Available over WebSocket only. Supports newHeads (new block headers), logs (filtered event logs), newPendingTransactions.

Polygon-specific considerations

Polygon produces a new block roughly every 2 seconds, compared to Ethereum’s 12 seconds. This means:

  • Your application will see significantly more blocks per hour. Polling with eth_blockNumber or eth_subscribe newHeads generates high request volume.
  • MATIC (being rebranded to POL) is the gas token. Always fetch eth_gasPrice or use EIP-1559 fee estimation (eth_maxFeePerGas) before submitting transactions.
  • Polygon has had historical reorg depth up to 30+ blocks during chain instability. For financial applications, wait for more confirmations than you would on Ethereum mainnet before treating a transaction as final.

ethers.js example: reading a balance

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(
  "https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_KEY"
);

const address = "0xYourAddressHere";
const balanceWei = await provider.getBalance(address);
const balanceMatic = ethers.formatEther(balanceWei);

console.log(`Balance: ${balanceMatic} MATIC`);

ethers.js example: calling a contract

const abi = ["function balanceOf(address) view returns (uint256)"];
const contract = new ethers.Contract("0xTokenAddress", abi, provider);

const balance = await contract.balanceOf("0xYourAddress");
console.log(`Token balance: ${balance.toString()}`);

Connecting to Polygon RPC: Step by Step

ethers.js

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(
  "https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_KEY"
);

// Verify connection
const blockNumber = await provider.getBlockNumber();
console.log(`Connected to Polygon. Current block: ${blockNumber}`);

For WebSocket connections:

const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/polygon?auth=YOUR_KEY"
);

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

Web3.py

from web3 import Web3

w3 = Web3(Web3.HTTPProvider(
    "https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_KEY"
))

if w3.is_connected():
    print(f"Connected. Block: {w3.eth.block_number}")

# Read balance
balance_wei = w3.eth.get_balance("0xYourAddress")
balance_matic = w3.from_wei(balance_wei, "ether")
print(f"Balance: {balance_matic} MATIC")

Direct JSON-RPC with curl

curl -X POST \
  "https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

Expected response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x2f1a4c6"
}

The result is a hex-encoded block number. Convert with parseInt("0x2f1a4c6", 16).

For MetaMask setup with BoltRPC, see the Polygon RPC endpoint page.

Common Polygon RPC Issues and Fixes

Rate limits on public endpoints

Free, unauthenticated public endpoints throttle aggressively, often to a few requests per second. In production, this causes intermittent errors under load. The fix is to use a dedicated authenticated endpoint, which is built for high-throughput workloads without the shared-pool congestion of public nodes.

Log range limits on eth_getLogs

Most providers cap eth_getLogs to a range of 2,000 to 10,000 blocks per request. If you need to backfill events over a large range, paginate manually:

async function getLogsInRange(provider, filter, fromBlock, toBlock, chunkSize = 2000) {
  const logs = [];
  for (let start = fromBlock; start <= toBlock; start += chunkSize) {
    const end = Math.min(start + chunkSize - 1, toBlock);
    const chunk = await provider.getLogs({ ...filter, fromBlock: start, toBlock: end });
    logs.push(...chunk);
  }
  return logs;
}

Handling reorgs on Polygon

Polygon can reorg several blocks during periods of validator instability. For any application where finality matters (exchanges, payment processors, bot strategies), do not treat a transaction as final at 1 confirmation. A conservative approach is to wait 30+ blocks before acting on a receipt.

To detect reorgs in your listener:

let lastBlockHash = null;

wsProvider.on("block", async (blockNumber) => {
  const block = await provider.getBlock(blockNumber);
  if (lastBlockHash && block.parentHash !== lastBlockHash) {
    console.warn("Potential reorg detected at block", blockNumber);
    // Re-fetch state from a safe block
  }
  lastBlockHash = block.hash;
});

WebSocket reconnection

WebSocket connections drop for many reasons: network hiccups, provider restarts, idle timeouts. Always implement reconnection logic. With ethers.js v6:

function createProvider() {
  const ws = new ethers.WebSocketProvider(
    "wss://eu.endpoints.matrixed.link/ws/polygon?auth=YOUR_KEY"
  );

  ws.websocket.on("close", () => {
    console.log("WebSocket closed. Reconnecting...");
    setTimeout(() => createProvider(), 3000);
  });

  return ws;
}

Choosing a Polygon RPC Provider

Not all RPC providers are the same. Here is what to evaluate before committing to one for production:

Reliability. Polygon’s high block rate means your application makes a lot of RPC calls. Provider downtime translates directly into missed blocks, failed transactions, or stale state. Look for providers with automatic failover built into their infrastructure.

Throughput. Polygon DeFi applications and trading bots generate significant request volume. A provider that throttles shared users or drops requests under load is a liability in production. Look for dedicated endpoints, not shared public pools.

EU infrastructure. If your application or team is based in Europe, EU-located nodes reduce round-trip latency meaningfully. Latency compounds at Polygon’s 2-second block time.

Support. When something breaks in production at 2am, community forums are not enough. Professional support with actual response times is worth the cost for any application with real users or real money at stake.

BoltRPC offers dedicated Polygon RPC endpoints built for production workloads, with EU infrastructure, automatic failover, professional support across all plans. Trusted by teams including Chainlink, Tiingo, Gains Network, Enjin.

Try it free for two weeks at trial.boltrpc.io.

FAQ

What is the best Polygon RPC endpoint?

For production applications, the best Polygon RPC endpoint is one that is dedicated (not shared with the public), supports both HTTPS and WebSocket, comes with professional support. BoltRPC’s Polygon endpoint (https://eu.endpoints.matrixed.link/rpc/polygon?auth=YOUR_KEY) is built for high-throughput workloads with EU-based infrastructure and automatic failover.

Is Polygon RPC compatible with Ethereum tools?

Yes. Polygon is fully EVM-compatible, so any tool or library that works with Ethereum’s JSON-RPC spec works with Polygon. This includes ethers.js, Web3.py, viem, Hardhat, Foundry. The only differences are the network’s chain ID (137 for mainnet), the gas token (MATIC/POL), Polygon-specific performance characteristics like 2-second block times.

What is the Polygon Amoy testnet RPC?

Polygon Amoy is the official Polygon testnet, replacing Mumbai. BoltRPC provides a dedicated Amoy endpoint at https://eu.endpoints.matrixed.link/rpc/polygon-amoy?auth=YOUR_KEY. Use this for testing smart contracts and integrations before deploying to mainnet. Amoy uses test MATIC, available from the Polygon faucet.

How do I use WebSocket with Polygon?

Connect to the WSS endpoint and use eth_subscribe to receive real-time events. With ethers.js:

const provider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/polygon?auth=YOUR_KEY"
);

// Subscribe to new blocks
provider.on("block", (blockNumber) => {
  console.log("New block:", blockNumber);
});

// Subscribe to contract events
const filter = {
  address: "0xContractAddress",
  topics: [ethers.id("Transfer(address,address,uint256)")]
};
provider.on(filter, (log) => {
  console.log("Transfer event:", log);
});

Always implement reconnection handling for WebSocket connections in production.


Start your free 2-week trial at trial.boltrpc.io.

Frequently asked questions

Ready to build with high-performance RPC?

Start your free trial today. No credit card required. Access 20+ networks instantly.

Disclaimer: The content in this article is for informational purposes only and does not constitute financial, legal, or technical advice. Code examples and configurations are provided as-is. Always verify information with official documentation and test thoroughly in your own environment before deploying to production.

Continue reading