Astar Network is a multi-chain smart contract platform that connects Polkadot to Ethereum and other major blockchains. To interact with Astar—whether querying on-chain data, sending transactions, or deploying smart contracts—you need a reliable RPC (Remote Procedure Call) endpoint. This guide explains what Astar RPC endpoints are, how to choose between public and private options, and best practices for production use.
Whether you are building a dApp on Astar's EVM or Substrate layer, selecting the right RPC provider is critical for performance, reliability, and scalability. We'll cover the available endpoints, their trade-offs, and how services like OnFinality can help you get started quickly.
Key takeaways
- Astar RPC endpoints allow dApps to read blockchain data and submit transactions without running a full node.
- Public endpoints are free but rate-limited, suitable for development and light usage.
- Private or dedicated RPC endpoints provide higher throughput, lower latency, and better reliability for production dApps.
- Astar supports both EVM and Substrate RPC interfaces; choose endpoints accordingly.
- OnFinality offers public Astar RPC endpoints and dedicated node options for scalable infrastructure.
- Always monitor RPC performance and have fallback endpoints to ensure high availability.
- Use WebSocket endpoints for real-time event listening and state updates.
What is an Astar RPC Endpoint?
An RPC (Remote Procedure Call) endpoint is a URL that allows your dApp or wallet to communicate with the Astar blockchain. It acts as a gateway for sending queries (e.g., account balances, transaction history) and transactions (e.g., token transfers, smart contract calls).
Astar Network runs on Substrate, but also provides an EVM-compatible layer. Therefore, Astar RPC endpoints support both standard Ethereum JSON-RPC methods and Substrate-specific RPCs. This dual compatibility means you can use familiar Web3 libraries like ethers.js or web3.js alongside Polkadot.js.
- EVM RPC: For Ethereum-compatible interactions (e.g., eth_call, eth_sendTransaction).
- Substrate RPC: For chain-specific queries (e.g., state_getStorage, chain_getBlock).
- WebSocket RPC: For real-time subscriptions (e.g., newHeads, logs).
Access reliable Astar RPC endpoints instantly with OnFinality's API service. Try OnFinality RPC.
Public vs Private Astar RPC Endpoints
Public RPC endpoints are freely available and easy to use. They are great for development, testing, and low-traffic applications. However, they often have rate limits, no SLA, and can become congested during peak usage. Examples include the official Astar Team endpoints and community-run nodes.
Private or dedicated RPC endpoints are provisioned for a single user or project. They offer higher rate limits, better performance, and dedicated support. Providers like OnFinality offer both shared (API-key based) and dedicated node options for Astar, ensuring consistent throughput and low latency.
| Criterion | What to check | Why it matters |
|---|---|---|
| Cost | Free vs paid plans | Public endpoints are free but limited; private endpoints require a subscription. |
| Rate Limits | Requests per second (RPS) | Public endpoints may throttle; private endpoints offer higher or unlimited RPS. |
| Reliability | Uptime and redundancy | Private endpoints often have SLAs and failover mechanisms. |
| Latency | Geographic proximity and node performance | Lower latency improves user experience for time-sensitive dApps. |
| Support | Technical support availability | Private providers offer dedicated support for troubleshooting. |
View supported networks, endpoints, and documentation for Astar on OnFinality. Astar Network Page.
How to Choose an Astar RPC Provider
When selecting an Astar RPC provider, consider your application's requirements: expected traffic, need for real-time data, budget, and geographic distribution. For production dApps, prioritize providers with proven uptime, low latency, and scalable infrastructure.
OnFinality provides public Astar RPC endpoints (HTTPS and WebSocket) that are reliable for development. For production, you can upgrade to a dedicated node or use the API service with higher rate limits. OnFinality's infrastructure is designed for Polkadot and Substrate chains, making it a natural choice for Astar.
- Check the provider's supported endpoints: EVM, Substrate, or both.
- Evaluate rate limits and pricing models (pay-as-you-go vs monthly).
- Look for WebSocket support if your dApp needs real-time updates.
- Consider multi-region availability for global user bases.
- Read documentation and test endpoints with your development stack.
For high-traffic dApps, consider a dedicated Astar node with guaranteed resources. Dedicated Nodes.
Setting Up Astar RPC in Your dApp
To connect to Astar, you need to configure your Web3 library with the correct RPC URL. For EVM-based dApps, use the chain ID 592 (0x250) and an appropriate RPC endpoint. For Substrate-based dApps, use the Polkadot.js API with the endpoint URL.
Here's a quick example using ethers.js with an Astar EVM RPC endpoint:
const provider = new ethers.providers.JsonRpcProvider('https://astar.api.onfinality.io/public');
const signer = provider.getSigner();
// Now you can interact with the chain.
- Always use HTTPS for production to avoid man-in-the-middle attacks.
- For high-traffic apps, implement a fallback mechanism with multiple endpoints.
- Use WebSocket endpoints for subscriptions to reduce polling overhead.
Learn how to evaluate RPC providers for your Web3 project. RPC Selection Guide.
Best Practices for Astar RPC Usage
To ensure optimal performance and reliability, follow these best practices when using Astar RPC endpoints:
Monitor your RPC usage and set up alerts for rate limit hits or latency spikes. Use caching for frequently queried data (e.g., token prices, account balances) to reduce RPC calls. For production, always have a backup endpoint in case your primary provider experiences downtime.
- Implement exponential backoff and retry logic for failed requests.
- Batch requests when possible to reduce overhead.
- Use archive nodes if you need historical state data.
- Test your dApp on testnet (Shibuya) before deploying to mainnet.
- Keep your provider's API keys secure and rotate them regularly.
Troubleshooting Common Astar RPC Issues
Developers may encounter issues like 'rate limit exceeded', 'connection timeout', or 'invalid response'. These often stem from using overloaded public endpoints or misconfigured requests.
If you face rate limiting, consider upgrading to a private endpoint or reducing request frequency. For timeouts, check your network connection and try a geographically closer endpoint. Invalid responses may indicate an incorrect chain ID or unsupported method.
- Rate limit errors: Switch to a private provider or implement request throttling.
- Connection errors: Verify the endpoint URL and your internet connectivity.
- Data inconsistencies: Ensure you are using the correct chain ID (592 for Astar mainnet).
- WebSocket disconnections: Implement reconnection logic with exponential backoff.
FAQ
What is the Astar chain ID for EVM?
The Astar mainnet chain ID is 592 (0x250). For testnet Shibuya, the chain ID is 81.
Can I use Astar RPC with ethers.js?
Yes, Astar's EVM layer is fully compatible with ethers.js and web3.js. Simply point your provider to an Astar EVM RPC endpoint.
What is the difference between public and private Astar RPC?
Public RPC endpoints are free but rate-limited and shared among users. Private RPC endpoints offer dedicated resources, higher limits, and better reliability, often for a fee.
Does OnFinality support Astar RPC?
Yes, OnFinality provides public Astar RPC endpoints (HTTPS and WebSocket) as well as dedicated node options for production use.
How do I get a dedicated Astar node?
You can request a dedicated Astar node through OnFinality's dedicated node service, which provides guaranteed resources and support.
Related resources
Originally published at OnFinality.
Top comments (0)