How to get a Polygon RPC endpoint for AI Agents (2026 guide)

Created Jul 31, 2026 Updated Aug 3, 2026

Chainstack

TL;DR

A single autonomous agent action on Polygon — read a pool, check approvals, simulate a route, broadcast — fans out into 50 to 200 RPC calls fired in a burst, and the public endpoint starts returning 429 the moment that fan-out crosses ~40 requests per second. Polygon’s two-second blocks and sub-cent gas make it the cheapest chain to run an agent on, which is exactly why the shared endpoint is the first thing to break. This guide shows how to get a Polygon RPC endpoint that survives agentic burst traffic, and why finality timing matters when a bot acts on its own.

What is a Polygon RPC endpoint

A Polygon RPC endpoint is the JSON-RPC interface your code talks to in order to read and write to the Polygon PoS network. Polygon runs the standard Ethereum JSON-RPC API surface on top of its own two-layer architecture: Bor, the EVM block producer that serves your eth_call, eth_getLogs, and eth_sendRawTransaction requests, and Heimdall, the validator layer that periodically checkpoints Bor’s state to Ethereum. When an AI agent or a dApp calls an endpoint, it is reaching a Bor node — and the answer it gets depends on whether that node is keeping up with the chain and whether the data has been checkpointed yet.

Practically every user-facing action on Polygon routes through the endpoint:

Reading POL and ERC-20 balances before an agent decides whether it can act
Running eth_call against a contract to price a swap or read a Polymarket position
Pulling event history with eth_getLogs to reconstruct state an agent missed while offline
Simulating a transaction with eth_estimateGas or a trace before committing real funds
Broadcasting a signed transaction with eth_sendRawTransaction and polling for its receipt

You can review the full list of supported JSON-RPC methods in the Polygon PoS developer documentation.

Endpoint quality on Polygon is not about average latency in a quiet moment — it is about what happens during a burst. An agent does not send one request and wait; it issues a dozen reads in parallel, and a shared endpoint that looks fine in a curl test collapses into rate-limit errors the instant a real workload hits it.

How Polygon RPC differs from Ethereum RPC

Polygon speaks the same JSON-RPC dialect as Ethereum, so your tooling works unchanged — but the operational characteristics that decide which endpoint you need are different.

Property	Ethereum mainnet	Polygon PoS
Block time	~12 s	~2 s
Gas token	ETH	POL (formerly MATIC)
Typical tx cost	Dollars	Fractions of a cent
Consensus / execution	PoS, single layer	Heimdall (validators) + Bor (execution)
Hard finality	~13 min (2 epochs)	Bor block, then Ethereum checkpoint (~30 min)
Reorg surface	Low after a few blocks	Bor blocks can reorg before checkpoint

Two of these rows drive provider selection. The two-second block time means an agent polling every block makes six times as many requests as the same agent on Ethereum, so the RPS ceiling on your endpoint matters six times more. And the checkpoint-based finality means a fast eth_getTransactionReceipt confirmation on Bor is not the same guarantee an agent gets on Ethereum — the state can still reorg before Heimdall checkpoints it. A provider that serves stale or lagging Bor state will quietly feed an agent the wrong answer.

Polygon RPC endpoint options

Public vs private Polygon RPC endpoints

The public-versus-private decision on Polygon is really a question of whether your endpoint can absorb a burst. A human clicking through a dApp generates requests one at a time; an autonomous agent generates them in fans of dozens. The public endpoint is built for the former.

Official public endpoints:

Mainnet: https://polygon-rpc.com
Testnet (Amoy): https://rpc-amoy.polygon.technology/

⚠️ The public Polygon mainnet endpoint begins returning 429 Too Many Requests at roughly 40 requests per second, and it offers no SLA, no dedicated throughput, and inconsistent WebSocket availability. A single agent action that fans out 50+ parallel reads can trip this ceiling on its own. The Polygon RPC endpoints documentation itself lists professional providers as the path for production workloads.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~40 req/s before `429`	No aggressive throttling
WebSocket support	Inconsistent / best-effort	Available
Archive access	Not available	Available

For an agentic workload the math is simple: if one action costs you 50 to 200 calls and your agent runs more than one action at a time, a shared endpoint with a ~40 req/s ceiling self-throttles before it does anything useful. Dedicated throughput is not an optimization here — it is the difference between an agent that runs and one that spends its time retrying.

📖 For a detailed comparison of Polygon RPC providers, see Best Polygon RPC providers for high-throughput apps in 2026.

Full node vs archive Polygon node

For an AI agent, historical access decides whether it can answer “what happened while I was offline?” — a full node only holds recent state, so any agent that reconstructs context from past events needs an archive node.

Full node access	Archive node access
Current POL and token balances	Historical balance at any past block
Real-time pool and price reads for live decisions	Backfilling `eth_getLogs` history beyond the recent window
Latest contract state via `eth_call`	Replaying an agent’s past on-chain actions for audit
Broadcasting and confirming transactions	Reconstructing Polymarket or DeFi position history

Chainstack supports archive nodes for Polygon, so an agent that needs to rebuild state from the full chain history — or a compliance process that audits every action a bot took — can query against a Chainstack archive node rather than stitching together a recent-blocks-only view. Archive requests bill at 2 RU per call versus 1 RU on a full node.

HTTPS vs WebSockets

For an AI agent that reacts to on-chain events, the question is whether it should poll or subscribe — and persistent connections change the latency and request-count math at scale.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Balance reads, `eth_call`, tx broadcast, agent decision loops	`eth_subscribe` for new blocks, pending tx, and contract event triggers
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

An AI agent that watches for a price threshold or a new market should subscribe over WebSocket rather than poll every two seconds over HTTPS — subscribing replaces hundreds of polling calls with one persistent stream. WebSocket support on the public Polygon endpoint is inconsistent and best-effort, so any production agent that relies on subscriptions needs a managed endpoint where WebSocket is a guaranteed feature.

How to get a private Polygon RPC endpoint with Chainstack

Log in to the Chainstack console (or create an account).
Create a new project
Select Polygon as your blockchain protocol
Choose network: Polygon Mainnet or Amoy testnet
Deploy the node
Open Access/Credentials and copy your HTTPS and WebSocket endpoints
Run a quick connectivity check before wiring it into production code

You can deploy a private Polygon RPC node on Chainstack in under a minute and point your agent at it with a standard ethers.js provider:

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

var urlInfo = {
    url: 'YOUR_CHAINSTACK_ENDPOINT'
};
// NETWORK_ID is 137 for Polygon Mainnet, 80002 for Amoy testnet
var provider = new ethers.providers.JsonRpcProvider(urlInfo, 137);

provider.getBlockNumber().then(console.log);

📖 For the full integration guide, see the Chainstack Polygon tooling documentation.

You can also access Chainstack Polygon RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Using Chainlist

Polygon is listed on Chainlist, which is convenient for adding the network to MetaMask or another wallet with one click. But Chainlist is a network registry, not an infrastructure provider — the public RPC URLs it surfaces carry the same ~40 req/s ceiling and no-SLA caveat as any shared endpoint. Use it to configure a wallet, then swap in a managed endpoint before any agent or production service touches it.

Chainstack pricing for Polygon RPC

Chainstack bills by request unit rather than by compute unit, so an agent’s cost scales with how many calls it makes, not with which methods it happens to call — one RU per request, two on archive, with no per-method multipliers. That predictability matters when an agent’s call volume is hard to forecast in advance. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3M	25	$20
Growth	$49	20M	250	$15
Pro	$199	80M	400	$12.50
Business	$499	200M	600	$10
Enterprise	from $990	400M+	Unlimited	$5

For workloads that need single-tenant throughput, Dedicated Nodes start at $0.50/hour per node plus storage and remove rate-limit contention entirely, while the Unlimited Node add-on offers flat-fee, RPS-tiered pricing. Global Nodes cut P99 latency through geo-routing — useful when an agent’s decision loop is latency-sensitive.

How to estimate monthly cost

Estimate the number of agent actions per day
Multiply by the calls-per-action for your agent (50 to 200 is a realistic range for a DeFi-style agent)
Convert to requests per month and map to a plan tier
Add archive volume separately at 2 RU per call if your agent backfills history
Size for the burst, not the average — an agent that runs several actions concurrently can spike well past its mean RPS, and on Polygon’s two-second blocks a per-block poller burns RU six times faster than the same loop on Ethereum

Production readiness checklist

Primary + fallback RPC provider configured
Request timeout policy set
Retry logic with exponential backoff implemented
Credentials stored in env/secret manager (never hardcoded)
Monitoring for latency, error rate, and throttling
Alerts for sustained degradation
A client-side rate limiter so a fan-out of parallel agent reads cannot self-throttle into 429s
Checkpoint-aware finality logic: an agent should not treat a fresh Bor confirmation as final for high-value actions until the state is checkpointed to Ethereum
WebSocket reconnect + missed-event backfill so an agent that drops a subscription does not silently skip a trigger

Benchmark endpoint latency under burst load with the Chainstack performance dashboard before you commit an agent to a provider.

Troubleshooting common Polygon RPC issues

Symptom	Cause	How to fix
`429 Too Many Requests`	Agent fan-out exceeds the public ~40 req/s ceiling	Move to a managed endpoint and add a client-side rate limiter ahead of parallel reads
WebSocket disconnects mid-run	Best-effort public WS or no heartbeat	Use a managed WS endpoint; add reconnect + backfill of missed events
Agent acts on a tx that later disappears	Treated a Bor confirmation as final before checkpoint	Wait for Ethereum checkpoint finality before high-value follow-on actions
`eth_getLogs` returns empty or errors on old ranges	Querying history beyond a full node’s retained state	Point historical queries at an archive node
Stale balances / prices feeding bad decisions	Lagging Bor node behind the chain head	Use a provider with synced, monitored nodes; verify block height before acting
Dropped transactions under load	Nonce collisions across concurrent agent actions	Serialize nonce assignment per signer and resubmit with the correct nonce

Conclusion

The failure mode that bites Polygon agent builders is not a crash — it is a slow, intermittent 429 storm that only appears under real load. Your AI agent passes every test in development because a test sends one request at a time. In production it fans out 50 to 200 calls per action across concurrent decisions, crosses the ~40 req/s public ceiling, and starts retrying — so it runs slower, acts late on stale data, and the logs blame the network instead of the endpoint. The second, quieter failure is finality: an agent that treats a two-second Bor confirmation as settled can act on a state that reorgs before it checkpoints to Ethereum.

The pattern that works: put a managed endpoint with real dedicated throughput in front of the agent from day one, add a client-side rate limiter so your own parallelism cannot self-throttle, subscribe over WebSocket instead of polling every block, and gate any high-value action behind checkpoint finality rather than a fresh Bor receipt. Treat dedicated throughput and checkpoint-aware logic as non-negotiable, not as things to add after the first outage.

Start free on the Developer plan to prototype, and move to dedicated infrastructure before your AI agent goes live.

Start building with Chainstack →

FAQ

Does my existing Ethereum tooling work on Polygon? Yes. Polygon PoS runs the standard Ethereum JSON-RPC API, so ethers.js, web3.py, viem, and Hardhat all work without modification — you only change the endpoint URL and the chain ID (137 for mainnet, 80002 for Amoy). The differences that matter for an agent are operational, not API-level: block time, finality, and how much burst throughput your endpoint can absorb.

Why isn’t the public Polygon endpoint enough for an AI agent? A single complex agent action can fan out into 50 to 200 RPC calls, and the public mainnet endpoint starts returning 429 at roughly 40 requests per second with no SLA. One agent running a couple of concurrent actions can exhaust that ceiling by itself, so the agent spends its time retrying instead of acting. The public endpoint is fine for development; production agents need dedicated throughput.

How does Polygon’s checkpoint finality affect an autonomous agent? Bor produces blocks every ~2 seconds, but those blocks only gain hard finality once Heimdall checkpoints them to Ethereum, roughly every 30 minutes. An agent that treats a fresh Bor confirmation as final can act on a transaction that later reorgs before its checkpoint. For high-value follow-on actions, gate the agent on checkpoint finality rather than the first receipt.

How many RPC calls will my agent actually make? It depends on the workload, but a DeFi-style agent that monitors pools, checks approvals, simulates a route, and executes commonly lands in the 50-to-200-calls-per-action range. Size your plan for the burst rather than the daily average, because concurrent actions spike RPS well above the mean — and on Polygon’s two-second blocks a per-block poller consumes request units six times faster than on Ethereum.

Do I need an archive node for an agent on Polygon? Only if the agent reconstructs context from history — backfilling eth_getLogs beyond the recent window, replaying its own past actions for audit, or reading historical balances. A full node covers live decision-making (current state, pricing, broadcasting). Archive calls bill at 2 RU each on Chainstack.

Should my agent poll over HTTPS or subscribe over WebSocket? Subscribe for anything event-driven. An agent watching for a price threshold or a new market should use eth_subscribe over WebSocket, which replaces hundreds of polling calls with one persistent stream and reacts faster. Use HTTPS for the request/response parts of the decision loop — balance reads, eth_call, and transaction broadcast.