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

TL;DR

The shared public Polygon endpoint starts returning HTTP 429s at roughly 40 requests per second — which is fine for a side project and fatal for a payment processor settling thousands of transfers a minute, with no SLA, no SOC 2 audit trail, and no one to call when it degrades. Polygon’s 2026 turn toward payments and tokenized assets (Rio upgrade, ~5-second finality, the Gigagas push toward 100k TPS) means enterprise workloads now demand sustained throughput and compliance guarantees that public infrastructure was never built to provide. This guide shows enterprise teams how Polygon RPC actually works, where shared endpoints break under regulated, high-volume load, and how to deploy a private endpoint with the SLA and isolation an audit will ask about.

What is a Polygon enterprise RPC endpoint

A Polygon RPC endpoint is the JSON-RPC interface your application uses to talk to the network’s execution layer. Polygon PoS runs two services under the hood: Bor, the EVM-compatible execution client that processes transactions and serves the standard eth_* method set, and Heimdall, the consensus layer that bundles Bor blocks into checkpoints and finalizes them. When your backend calls eth_sendRawTransaction or eth_getBalance, it is hitting Bor; the finality semantics behind those calls are governed by Heimdall. For an enterprise endpoint, “enterprise” is not a different protocol — it is the same JSON-RPC surface delivered on dedicated, contractually backed infrastructure instead of a shared free pool.

For an enterprise application on Polygon, the endpoint is the dependency every customer-facing action routes through:

• Broadcasting payment and settlement transactions with eth_sendRawTransaction
• Reading account and treasury balances with eth_getBalance and eth_call
• Backfilling transfer and event history for reconciliation with eth_getLogs
• Estimating gas in POL (Polygon’s native gas token since the MATIC migration) with eth_estimateGas and eth_gasPrice
• Confirming finality for high-value transfers via the finalized block tag, which reflects Heimdall checkpoints
• Tracing and replaying transactions for compliance and forensics via the debug_* namespace

You can review the full list of supported JSON-RPC methods in the Polygon developer documentation. The gap between a hobby endpoint and an enterprise one shows up precisely where these calls meet regulated, high-volume traffic: a missed eth_getLogs backfill is a reconciliation discrepancy your finance team has to explain, and a throttled eth_sendRawTransaction during a settlement window is a payment that silently didn’t go out.

How Polygon RPC differs from Ethereum RPC

Polygon is EVM-equivalent, so the method names match Ethereum — but the operating envelope that matters for enterprise capacity planning is very different.

Property	Ethereum mainnet	Polygon PoS
Block time	~12s	~2s (sub-second target post-Rio)
Finality	~13 min (2 epochs)	~5s fast finality (Rio upgrade)
Throughput	~15-30 TPS	~5,000 TPS today, Gigagas roadmap to 100k TPS
Gas token	ETH	POL (migrated from MATIC)
Consensus / clients	Beacon + execution clients	Heimdall (checkpoints) + Bor (execution)
Trace tooling	trace_* / debug_*	erigon_* and trace_* deprecating mid-2026 as providers migrate Erigon to Bor; debug_* going forward

The practical takeaway for provider selection: Polygon produces blocks roughly six times faster than Ethereum and is engineered for far higher throughput, so an enterprise endpoint is being asked to sustain a much higher steady-state request rate and absorb sharper bursts. And because the historical-tracing method set is actively changing, enterprises that rely on trace data for compliance need a provider that has already committed to the post-migration debug_* path rather than one still leaning on soon-to-be-removed erigon_* methods.

Polygon enterprise RPC endpoint options

Public vs private Polygon RPC endpoints

For an enterprise, the public-vs-private decision is not about whether the free endpoint “works” — it usually does, until it doesn’t — it is about whether you can put it in front of an auditor. A shared endpoint has no SLA to point at in a vendor risk review, no SOC 2 attestation, no isolation guarantee, and no audit log of who called what. None of that is solvable with application-level retry logic.

Official public endpoints:

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

⚠️ The public Polygon mainnet RPC begins returning HTTP 429 (“Too Many Requests”) at roughly 40 requests per second in aggregate across all callers, and public providers typically cap eth_getLogs to a 2,000–10,000 block range per request. For a payment or settlement workload, both limits are hit routinely — and the Polygon developer docs themselves direct production teams to professional RPC providers rather than the shared endpoints.

Public endpoint	Private (Chainstack) endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~40 req/s shared, then 429	No aggressive throttling
Compliance	No SLA, no SOC 2, no audit trail	Custom SLA + SOC 2 Type II and ISO 27001 attestation
Archive access	Not available	Available

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

Because Polygon is now the chain enterprises use to move real money — payments and tokenized assets settling in seconds — the question stops being “is the endpoint fast enough” and becomes “can this endpoint survive a settlement-window traffic spike while producing the SLA and compliance evidence my organization is contractually obligated to provide.” A shared pool answers no to both.

Full node vs archive Polygon node

For an enterprise on Polygon, historical data access is a compliance and reconciliation question, not a nice-to-have: regulators and finance teams ask for transfer histories, balances at past blocks, and replayable transaction traces that a full node simply no longer retains.

Full node access	Archive node access
Current treasury and customer balances	Historical balances at any past block for audits
Real-time payment confirmation	Multi-month eth_getLogs transfer backfills for reconciliation
Recent transaction status	Transaction replay and tracing for forensics and disputes

A full node serves current state and recent history, which covers live payment flows. The moment you need to reconstruct a balance as of a quarter-end, reconcile a multi-month transfer ledger, or replay a transaction for a compliance investigation, you need an archive node. Chainstack supports Polygon archive nodes (billed at 2 request units per call versus 1 for a full node), which is what makes point-in-time auditing and long-range backfills possible without stitching together third-party indexers.

HTTPS vs WebSockets

At enterprise request volumes, the cost of opening a fresh TLS connection for every call adds up — and for the parts of a payment system that need to react the instant a transfer confirms, polling over HTTPS wastes both latency and request budget. The two transports solve different problems and most enterprise stacks use both.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Transaction broadcasting, balance reads, batch reconciliation jobs	Live settlement confirmations, newHeads block tracking, mempool and event subscriptions
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket subscriptions on Polygon are a provider-level feature — the free public endpoints offer them inconsistently at best, so any enterprise design that depends on eth_subscribe for real-time confirmation should assume a managed endpoint from the start and build reconnect plus missed-event backfill logic around it.

How to get a private Polygon RPC endpoint with Chainstack

Deploying a private Polygon RPC node on Chainstack takes a few minutes:

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

Once you have the endpoint, connecting with ethers.js takes only a connection setup and a call:

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

// Network ID 137 = Polygon mainnet; use 80002 for Amoy testnet
const provider = new ethers.providers.JsonRpcProvider(
    'YOUR_CHAINSTACK_ENDPOINT',
    137
);

// Confirm connectivity by reading the latest block height
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.

For an enterprise rollout specifically, the same protocol is available on dedicated, isolated infrastructure with a custom SLA, SSO/MFA, and SOC 2 controls — see the Chainstack for Enterprise stack for the full set of organizational, security, and compliance capabilities.

Using Chainlist

Polygon is on Chainlist, which is convenient for adding the network to a wallet like MetaMask — it auto-populates chain ID 137 and the native POL token. But Chainlist is a network directory, not an infrastructure provider: the public RPC URLs it lists are the same throttled shared endpoints discussed above. For any enterprise workload, replace whatever Chainlist hands your wallet with a managed endpoint before it touches production traffic.

Chainstack pricing for Polygon RPC

Chainstack bills one request unit per request regardless of method, so an enterprise capacity model is a function of request volume rather than a per-method compute-unit puzzle you have to reverse-engineer. 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

Advanced options most relevant to enterprise Polygon workloads:

• Dedicated Nodes: isolated single-tenant infrastructure from $0.50/hour per node (plus storage), the right fit when noisy-neighbor isolation and predictable performance are compliance requirements rather than preferences.
• Unlimited Node: flat-fee, unlimited requests within a chosen RPS tier — removes per-request overage exposure for high, steady payment traffic.
• Archive add-on for point-in-time archive data (2 RU per request) when audit and reconciliation history is in scope.

How to estimate monthly cost

1. Count requests per user action (a single payment confirmation flow can be several calls: gas estimate, broadcast, receipt poll, log read).
2. Multiply by expected daily active volume to get a baseline monthly request count.
3. Map that to the smallest plan whose RPS ceiling covers your peak, not your average.
4. Add archive RU (2x) if reconciliation or audit backfills run against the same endpoint.
5. Enterprise-specific: settlement and payroll traffic on Polygon is bursty by nature — month-end and event-driven windows can spike request volume several times over baseline, so size to the peak window and consider an Unlimited Node tier so a settlement spike never turns into an overage bill or a throttle.

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
• eth_getLogs queries chunked to the provider’s block-range cap (keep ranges to a few thousand blocks) so reconciliation backfills don’t fail mid-job
• Trace/forensics tooling migrated off erigon_* and trace_* to the debug_* namespace ahead of the mid-2026 deprecation
• ~5-second fast finality (and Heimdall checkpoint timing for the finalized tag) reflected in payment confirmation UX for high-value transfers
• SLA and SOC 2 Type II and ISO 27001 evidence from your provider on file for vendor risk and audit reviews

Before committing to a provider, use the Chainstack performance dashboard to benchmark endpoint latency under realistic load.

Troubleshooting common Polygon RPC issues

Issue	How to fix
429 Too Many Requests	You have hit the ~40 req/s shared public ceiling; move to a managed endpoint with dedicated RPS.
WebSocket disconnects	Implement reconnect with heartbeat and backfill missed newHeads/events on reconnect.
eth_getLogs “query returned more than X results” / range too large	Chunk the query into 2,000-block windows (or smaller) and page through them; run long backfills against an archive node.
erigon_* / trace_* method not found	These are being removed mid-2026 as Erigon is replaced by Bor; switch to debug_traceTransaction on a trace-enabled dedicated node.
Transaction stuck or “underpriced” during congestion	Use a live gas estimate (POL-denominated), bump gas price, and manage nonce sequencing for queued sends.
Payment shows confirmed but reorgs before checkpoint	For high-value settlement, wait for the finalized tag (Heimdall checkpoint) rather than a single recent confirmation.

Conclusion

The failure mode that catches enterprise teams on Polygon is not a dramatic outage — it is the quiet one. A settlement batch fires during a month-end window, the shared endpoint crosses its ~40 req/s ceiling, a fraction of the eth_sendRawTransaction calls come back as 429s, and a handful of payments simply never broadcast. There is no alert, because nothing “crashed.” You find out during reconciliation, and then you discover the harder problem: there is no SLA to invoke and no audit trail to explain what happened to the people who will ask.

The pattern that works is to treat the endpoint as regulated infrastructure from day one. Run production traffic through a private, dedicated endpoint sized to your peak window, not your average. Keep an archive node in reach for reconciliation and point-in-time audits. Pin your provider to the post-migration debug_* trace path and get its SLA and SOC 2 Type II and ISO 27001 attestation on file before launch, not after the first incident. On a chain built for payments and tokenized assets, the endpoint is part of your compliance surface — provision it that way.

Spin up a Polygon node on the free tier to test the integration, then move to Dedicated Nodes with a custom SLA for production.

FAQ

Is the public Polygon RPC enough for an enterprise application? No. The public mainnet endpoint throttles at roughly 40 requests per second across all callers and ships with no SLA, no SOC 2 Type II and ISO 27001 attestation, and no audit trail — three things a vendor risk review will require. It is suitable for development and testing only; production payment and settlement traffic needs a private endpoint with dedicated throughput and contractual reliability guarantees.

Do enterprise teams on Polygon need an archive node? If you have reconciliation, audit, or compliance obligations, yes. A full node serves current and recent state, but reconstructing a balance as of a past block, backfilling multi-month transfer ledgers, or replaying a transaction for a dispute all require archive access. Chainstack supports Polygon archive nodes, billed at 2 request units per call.

How does Polygon’s finality affect payment confirmation? Bor produces blocks every ~2 seconds, and the Rio upgrade brought roughly 5-second fast finality, but true settlement finality is anchored when Heimdall checkpoints a block. For high-value transfers, confirm against the finalized block tag rather than a single recent confirmation so a reorg can’t reverse a payment your system already reported as complete.

The trace_* and erigon_* methods are being deprecated — how do I get trace data for compliance? As providers migrate Polygon from Erigon to Bor (deprecation lands mid-2026), the erigon_* and trace_* namespaces are going away. Move forensics and replay tooling to the debug_* namespace (for example debug_traceTransaction) on a trace-enabled dedicated node, and confirm your provider supports it before the cutover.

Which SDKs work with a Polygon enterprise endpoint? Polygon is EVM-equivalent, so the standard EVM stack works without modification: ethers.js, web3.js, web3.py, web3j, Hardhat, Foundry, and Brownie all connect by pointing at your endpoint and using chain ID 137. Polygon-specific helpers like Matic.js are also available for bridge and PoS-specific flows.

What should an enterprise monitor on its Polygon endpoint? Track latency and error rate per method, throttling/429 frequency (your early warning for hitting an RPS ceiling), WebSocket connection health, and eth_getLogs failure rate during backfills. Alert on sustained degradation rather than single spikes, and keep a fallback provider configured so a primary-endpoint incident doesn’t stop settlement.

Additional resources

• Polygon: Bridging ERC-20 from Ethereum to Polygon — Chainstack Docs tutorial
• Chainstack Polygon tooling documentation
• Polygon developer documentation
• Enterprise RPC infrastructure: nodes, SLA, and compliance — Chainstack Blog
• More Polygon tutorials and articles on the Chainstack Blog