Summary
A MATIC RPC node is a Polygon PoS endpoint exposed through JSON-RPC for reading chain state and broadcasting transactions. This reference covers Polygon Mainnet and Amoy chain settings, how to test endpoints with curl, and how to compare public RPCs against managed providers and dedicated nodes.
Use the checklist and chain IDs here to avoid the most common Polygon RPC mistakes, then decide when you need predictable throughput, WebSocket support, or archive methods for production workloads.
MATIC RPC Node Decision Checklist
Before you wire an endpoint into a wallet, dApp, or backend, decide the following:
- Which network are you targeting? Polygon Mainnet uses chain ID
137; testnet is Amoy (chain ID80002). They are not interchangeable. - Do you need WebSocket? Wallets and indexers often use pub/sub for pending transactions and new heads; not every public RPC exposes a stable WSS URL.
- What methods do your users call? Standard
eth_*methods cover most apps. Debug/trace methods and archive state often require a paid or dedicated endpoint. - What is your traffic pattern? Bursty traffic from an indexer or bot behaves differently than steady UI load; rate limits and throughput caps matter.
- Do you need an access key or URL rotation? Public endpoints can be blocked or rate-limited without notice. A managed RPC API gives you a stable URL, keys, and failover.
- How will you monitor failures? Plan a fallback RPC for critical paths; don't let a single endpoint become a single point of failure.
The rest of this reference walks through chain settings, test requests, and evaluation criteria so you can answer those questions quickly.
What Is a MATIC RPC Node?
A MATIC RPC node is another way of saying a Polygon PoS full node exposed through JSON-RPC. Even though Polygon has transitioned its native gas token from MATIC to POL, the string "matic" is still widely used in RPC URLs, wallet network names, and API documentation. You will see it on endpoints such as https://1rpc.io/matic, https://rpc-mainnet.matic.quiknode.pro, and in legacy concepts like MATIC RPC.
When someone searches for a "MATIC RPC node", they usually need one of three things:
- A URL to connect a wallet or dApp to Polygon Mainnet or Amoy.
- A node provider that can handle production traffic without hard rate limits.
- Instructions for making the first JSON-RPC call against Polygon.
This article focuses on all three. If you need a broader comparison of RPC providers for multiple networks, see How to choose an RPC provider.
Polygon Mainnet and Amoy Chain Settings
When you configure a network in MetaMask, wagmi, or a backend RPC client, chain settings must match. Polygon Mainnet is the production EVM chain with chain ID 137. Amoy is the primary testnet, with chain ID 80002, and it replaced Mumbai after the Mumbai deprecation.
The table below lists commonly used endpoints from Polygon documentation and chain registries. They are fine for testing, but verify the current URL, token symbol, and rate-limit policy before relying on any public endpoint in production.
| Network | Chain ID | Gas token | HTTPS RPC (public) | WSS | Explorer |
|---|---|---|---|---|---|
| Polygon Mainnet | 137 | POL (formerly MATIC) | https://polygon-rpc.com | wss://polygon-rpc.com if available | PolygonScan |
| Polygon Amoy | 80002 | POL | https://polygon-amoy.drpc.org | wss://polygon-amoy.drpc.org | Amoy PolygonScan |
Before going further, compare these values with any RPC URL you already have. A mismatched chain ID is the most common cause of "wrong network" errors in EVM wallets.
How to Test a MATIC RPC Endpoint with curl
A quick health check for any Polygon RPC endpoint is eth_blockNumber. It confirms that the node is synced and reachable without requiring an API key on most endpoints.
Use curl with a JSON-RPC body:
curl https://polygon-rpc.com \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
A normal response contains a hex block number, for example:
{"jsonrpc":"2.0","id":1,"result":"0x57c0f2d"}
Next, compare eth_chainId with the chain ID you configured:
curl https://polygon-rpc.com \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
The result should be 0x89 (137) on Mainnet and 0x13880 (80002) on Amoy. If the returned chain ID does not match, you are connected to the wrong network.
For dApp code, you can use the same JSON-RPC over a configured provider. With ethers v6, you can keep the chain settings in one place:
import { JsonRpcProvider } from "ethers";
const maticRpcNode = "https://polygon-rpc.com";
const provider = new JsonRpcProvider(maticRpcNode, 137, {
staticNetwork: true
});
const block = await provider.getBlockNumber();
console.log(block);
Public vs Managed MATIC RPC Nodes
A public RPC like the ones in the table above is a shared endpoint operated by a third party. It works for experiments, hackathon projects, and light wallet integrations, but public endpoints usually carry community rate limits and can be throttled during congested periods.
Managed RPC providers run Polygon nodes on your behalf and expose them through stable URLs. OnFinality, for example, offers Polygon RPC access through the OnFinality API service and dedicated nodes. With a managed provider you typically get:
- A stable HTTPS and WSS URL you can share with clients.
- API keys to track usage and debug issues.
- Access to additional methods (including debug/trace and archive data on supported plans).
- Redundant endpoints to reduce the risk of connection loss.
When traffic grows, you can move from shared API keys to a dedicated MATIC RPC node. Dedicated nodes give you a single-tenant endpoint, which removes noisy-neighbor effects, and are useful for indexers, validators, and high-volume applications.
The choice depends on your workload, not on "free vs paid" alone. A high-traffic DEX frontend and a testnet script have different needs. If you want a systematic comparison, read How to choose an RPC provider.
How to Evaluate a MATIC RPC Node
Use the following table to compare any MATIC RPC node—public or managed. Keep the checklist in mind as you test candidates.
| Criterion | What to check | Why it matters |
|---|---|---|
| Chain ID | Confirm eth_chainId returns 0x89 (mainnet) or 0x13880 (Amoy) | Prevents accidentally sending transactions to the wrong network |
| Method coverage | Try eth_getLogs, eth_call, eth_getProof, and any debug/trace methods your app needs | Missing methods cause runtime failures deep in your code |
| WebSocket stability | Connect to WSS and subscribe to newHeads for a few minutes | Unstable WSS breaks event-driven dApps and indexers |
| Rate limits | Read the provider's documented limits or send a burst of requests | Sudden HTTP 429s make the endpoint unreliable under load |
| Archive state | Request a historical balance or state at an old block | New apps often need more than the latest head |
| Transaction propagation | Measure how quickly eth_sendRawTransaction returns a tx hash | Slow broadcast can cause stuck wallet transactions |
| Latency and region | Compare time-to-first-byte from your user regions | High latency affects UI performance and bot strategies |
| Pricing model | Check per-request, per-second, and capacity pricing | Predictable costs matter when you scale |
Common MATIC RPC Pitfalls
- Wrong chain ID: Reusing Ethereum Mainnet config in a Polygon wallet causes "wrong network" errors. Double-check
0x89vs0x1. - Mixing testnet and mainnet: After Mumbai retirement, most testnet tutorials use Amoy (80002). Code that hardcodes Mumbai will fail.
- Assuming public endpoints are archive nodes: Public RPCs usually serve recent state only. Querying old blocks may return missing trie node errors.
- Rate limits appearing as timeouts: Some endpoints return 429, others drop connections without a clear error. Wrap calls in retry logic with backoff.
- No WebSocket fallback: If your app requires real-time data, you need both HTTPS and WSS supported. Not every endpoint provides both.
- Token symbol confusion: After the MATIC to POL migration, transactions and gas are denominated in POL. An app showing "MATIC" as the only symbol may confuse users, though "MATIC" remains the ticker used in many RPC endpoint URLs and third-party wallets.
Key Takeaways
- A MATIC RPC node is a Polygon PoS node exposed via JSON-RPC; "MATIC" appears in many endpoint URLs even though the network now uses POL as its gas token.
- Polygon Mainnet uses chain ID
137; Amoy testnet uses80002. - Public endpoints are good for development, but hard to rely on for production traffic because of rate limits and method restrictions.
- Manage your own failover: test
eth_chainId,eth_blockNumber, and WSS subscriptions before launch. - When you need predictable limits, archive methods, or dedicated capacity, evaluate managed RPC providers such as OnFinality's Polygon RPC and dedicated nodes.
- Compare cost and limits carefully; see current details on RPC pricing and supported RPC networks.
Frequently Asked Questions
What is a MATIC RPC node used for?
A MATIC RPC node is used to read Polygon blockchain data and send transactions from dApps, wallets, indexers, and backend services. The name comes from the MATIC ticker, which is still common in RPC URLs like 1rpc.io/matic.
Is a free Polygon RPC endpoint enough?
Free public endpoints work for development and small projects, but they usually have rate limits and may not support archive, debug, or trace methods. For anything that depends on low-latency, high-volume, or historical data, a managed RPC API is safer.
How do I get a Polygon RPC URL?
You can either use a public endpoint from the Polygon documentation or create one from a provider. Providers give you a URL, often with a key, for the Mainnet or Amoy chain. OnFinality exposes Polygon RPC through its API service; check the Polygon network page for current endpoints and methods.
Does OnFinality support Polygon testnet RPC?
You should check the supported networks list to see current testnet coverage. If Amoy RPC is available, the settings above use chain ID 80002.
What’s the difference between MATIC and POL?
Polygon expanded MATIC into POL as a unified gas and staking token, but many RPC endpoint paths and wallet labels still say "matic". Chain ID, not token symbol, determines which network you connect to.
Why am I getting rate-limited on a Polygon RPC?
Shared public endpoints have community limits; if you are hitting them with parallel requests, you will eventually get throttled. A dedicated RPC node or managed provider with a higher tier gives you more headroom.