Summary
# Polygon Amoy RPC: Complete Guide to Endpoints, Providers, and Best Practices The Polygon Amoy testnet is the official replacement for Mumbai, anchored to Ethereum Sepolia. This guide provides everything you need to connect to Polygon Amoy RPC endpoints, choose a provider, and avoid common pitfalls. Whether you're deploying a smart contract or testing a dApp, you'll find practical endpoint references, provider comparisons, and troubleshooting tips.
In practice, the useful question is not just whether an endpoint exists. Teams should check Polygon endpoint access, testnet-to-mainnet workflow, archive or trace needs, and app traffic patterns. That turns the page from a definition into a decision tool: it helps you decide what to test first, what belongs in staging, and when a production workload may need stronger isolation or clearer request visibility. If you already know the network you need, open /networks/polygon after using this checklist so you can test the endpoint against your real methods.
Key Takeaways
- Polygon Amoy is the official testnet for Polygon PoS, replacing Mumbai and using Sepolia as its root chain.
- Chain ID 80002, native token POL, and block explorer at amoy.polygonscan.com.
- Multiple public RPC endpoints are available, but they often have rate limits and no support terms.
- Paid RPC providers offer higher rate limits, dedicated nodes, and better reliability for production testing.
- OnFinality provides a public Amoy RPC endpoint and dedicated node options for consistent performance.
- Common issues include rate limiting, incorrect chain ID, and stale endpoints; always verify endpoint status.
- Use WebSocket endpoints for real-time event listening and faster transaction confirmation.
What is Polygon Amoy?
Polygon Amoy is the official testnet for Polygon PoS, launched in January 2024 to replace the deprecated Mumbai testnet. It uses Ethereum Sepolia as its root (L1) chain, ensuring long-term sustainability as Goerli is phased out. Developers can test smart contracts, dApps, and infrastructure in a low-stakes environment with access to essential validators, faucets, and tooling.
Key network details: Chain ID 80002 (0x13882), native token POL, and block explorer at https://amoy.polygonscan.com. Testnet tokens are available from the official Polygon faucet.
- Network Name: Polygon Amoy
- Parent Chain: Ethereum Sepolia
- Chain ID: 80002
- Gas Token: POL
- Block Explorer: https://amoy.polygonscan.com
- RPC Endpoint: https://polygon-amoy.drpc.org (example)
- WSS Endpoint: wss://polygon-amoy.drpc.org (example)
Polygon RPC decision checklist
Use this checklist to turn the Polygon RPC question into a practical infrastructure decision instead of a generic provider comparison.
Shortlist providers only after you know which methods, environments, traffic patterns, and support expectations matter to the workload.
- List the exact RPC methods, chains, and environments your app will call.
- Test with the same request pattern your frontend, backend, bot, dashboard, or indexer will use.
- Check whether archive, trace, WebSocket, testnet, analytics, or dedicated-node access is actually required.
- Review pricing, usage visibility, and upgrade paths before moving sustained traffic.
| Criterion | What to check | Why it matters |
|---|---|---|
| Workload fit | Does the provider support the Polygon RPC methods and environments your product depends on? | A provider that works for a quick read may still be a poor fit for wallets, trading systems, indexers, or release pipelines. |
| Operational visibility | Can the team see request volume, errors, limits, and usage patterns? | Visibility makes it easier to debug failed requests and plan capacity before users feel the problem. |
| Scaling path | Is there a clear path from shared RPC to higher-capacity plans or dedicated nodes? | The right starting point should not force a rebuild when traffic or reliability requirements increase. |
Polygon Amoy RPC Endpoints
Multiple RPC endpoints are available for Polygon Amoy, both public and private. Public endpoints are free but often have rate limits and no clearer infrastructure expectations. Paid providers offer higher rate limits, dedicated nodes, and SLAs suitable for production testing.
Below is a list of commonly used Polygon Amoy RPC endpoints. Always verify the latest endpoint status from the provider's documentation.
| Criterion | What to check | Why it matters |
|---|---|---|
| Provider | Endpoint URL | Reliability and rate limits |
| PublicNode | https://polygon-amoy-bor-rpc.publicnode.com | Free, no registration, but rate limited |
| dRPC | https://polygon-amoy.drpc.org | Free tier available, paid plans for higher limits |
| Tenderly | https://polygon-amoy.gateway.tenderly.co | Gateway with Web3 infrastructure |
| OnFinality | https://polygon-amoy.api.onfinality.io/public | Public endpoint with dedicated node options |
| Nodies | https://polygon-amoy-public.nodies.app | Free public endpoint |
| ZAN | https://api.zan.top/polygon-amoy | Enterprise-grade with free tier |
How to Choose an RPC Provider for Polygon Amoy
Selecting the right RPC provider depends on your testing requirements. For light testing, a public endpoint may suffice. For consistent performance, consider a dedicated node or a paid plan with rate limit documents.
Key factors to evaluate: rate limits, support and monitoring options, geographic distribution, WebSocket support, and pricing. OnFinality offers both a public endpoint and dedicated nodes for Polygon Amoy, giving you flexibility as your testing needs grow.
- Rate Limits: Public endpoints typically allow 10-100 requests per second; paid plans offer higher limits.
- support and monitoring options: Paid providers often documents documented availability availability; public endpoints have no support terms.
- WebSocket Support: Essential for real-time applications; verify WSS endpoint availability.
- Geographic Distribution: Global nodes reduce latency; check provider's node locations.
- Pricing: Compare free tiers and paid plans; some providers charge per request or monthly.
How to Connect to Polygon Amoy RPC
Connecting to Polygon Amoy is straightforward. You can use the RPC endpoint in your dApp, wallet, or directly via curl. Below is an example using curl to check the latest block number.
- Using curl: curl -X POST https://polygon-amoy.drpc.org -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
- Using Web3.js: const web3 = new Web3('https://polygon-amoy.drpc.org'); web3.eth.getBlockNumber().then(console.log);
- Using ethers.js: const provider = new ethers.providers.JsonRpcProvider('https://polygon-amoy.drpc.org'); provider.getBlockNumber().then(console.log);
- Adding to MetaMask: Network Name: Polygon Amoy, RPC URL: https://polygon-amoy.drpc.org, Chain ID: 80002, Currency Symbol: POL, Block Explorer: https://amoy.polygonscan.com
Common Issues and Troubleshooting
Developers may encounter issues when connecting to Polygon Amoy RPC. Below are common problems and solutions.
- Rate Limiting: If you receive '429 Too Many Requests', reduce request frequency or switch to a paid provider with higher limits.
- Incorrect Chain ID: Ensure your wallet or dApp uses Chain ID 80002 (0x13882). Using the wrong chain ID will cause transaction failures.
- Stale Endpoint: Public endpoints may go offline or become slow. Always verify endpoint status from the provider's status page.
- WebSocket Disconnections: Use reconnection logic in your code to handle temporary disconnections.
- Transaction Not Mined: Check gas price and nonce; Amoy uses POL as gas token. Use the gas station at https://gasstation.polygon.technology/.
Polygon Amoy vs. Mumbai: Key Differences
Amoy replaces Mumbai as the primary testnet for Polygon PoS. The main difference is the root chain: Amoy uses Sepolia, while Mumbai used Goerli. As Goerli is deprecated, Mumbai is no longer supported. Developers should migrate to Amoy.
| Criterion | What to check | Why it matters |
|---|---|---|
| Feature | Amoy | Mumbai |
| Root Chain | Ethereum Sepolia | Ethereum Goerli (deprecated) |
| Chain ID | 80002 | 80001 |
| Launch Date | January 2024 | 2021 |
| Status | Active | Deprecated |
Best Practices for Using Polygon Amoy RPC
Follow these best practices to ensure a smooth development experience on Polygon Amoy.
- Use a dedicated node or paid RPC provider for consistent performance during heavy testing.
- Implement fallback endpoints in your dApp to handle provider outages.
- Monitor your RPC usage to avoid hitting rate limits unexpectedly.
- Keep your Web3 libraries updated to support the latest JSON-RPC methods.
- Test thoroughly on Amoy before deploying to Polygon mainnet.
Frequently Asked Questions
What is the Polygon Amoy RPC endpoint?
The Polygon Amoy RPC endpoint is the URL used to interact with the Amoy testnet. Common endpoints include https://polygon-amoy.drpc.org, https://polygon-amoy-bor-rpc.publicnode.com, and https://polygon-amoy.api.onfinality.io/public. Always verify the latest endpoint from the provider.
How do I get POL testnet tokens for Amoy?
You can obtain POL testnet tokens from the official Polygon faucet at https://faucet.polygon.technology/. You'll need to connect your wallet and request tokens.
Can I use the same code for Amoy and Polygon mainnet?
Yes, the RPC methods are identical. You only need to change the RPC endpoint URL and chain ID. However, ensure your smart contracts are tested thoroughly on Amoy before deploying to mainnet.
What is the difference between Bor and Heimdall RPC?
Bor is the block producer layer (execution layer) and Heimdall is the validator layer (consensus). For most dApp interactions, you only need the Bor RPC endpoint. Heimdall is used for staking and governance operations.
Why is my transaction stuck on Amoy?
Stuck transactions are often due to low gas price or nonce issues. Check the gas price using the Polygon Gas Station and ensure your nonce is correct. You can also use the 'eth_getTransactionByHash' method to check transaction status.