TL;DR
Send a request to the wrong Avalanche chain endpoint and you get silent errors that look like network problems — not a clear message telling you that C-Chain, X-Chain, and P-Chain each require a different URL. Avalanche’s three-chain architecture means a single base node URL exposes three separate APIs, and routing the wrong operation to the wrong one is the most common source of integration failures. This guide covers all three chains, when each matters for RPC selection, and how to deploy infrastructure that handles the full Avalanche API surface without the guesswork.
What is an Avalanche RPC endpoint
An Avalanche RPC endpoint is a chain-specific URL — not a single address that handles everything. Each of Avalanche’s three primary chains has its own endpoint path appended to a base node URL, and each speaks a different API dialect:
- C-Chain (
/ext/bc/C/rpc) — EVM-compatible JSON-RPC, same interface as Ethereum. This is where smart contracts live, DeFi protocols run, and alleth_*calls go. - X-Chain (
/ext/bc/X) — Avalanche-native API for asset creation and transfers using the DAG-based Avalanche consensus. Not EVM-compatible. - P-Chain (
/ext/P) — Platform chain API for staking, validator management, and subnet creation. Also not EVM-compatible.
Every production action routes through one of these:
- Deploying and calling smart contracts via C-Chain JSON-RPC (
eth_call,eth_sendRawTransaction) - Reading DeFi protocol state, token balances, and event logs via C-Chain
- Transferring AVAX between chains or interacting with native assets via X-Chain
- Querying validator sets, delegator balances, or subnet configurations via P-Chain
- Monitoring real-time C-Chain transactions via WebSocket subscriptions
The operational consequence: if you build a wallet or exchange that handles native AVAX transfers across all three chains, you are not talking to one endpoint — you are managing three separate API surfaces with different authentication, different method namespaces, and different data models.
Beyond the three primary chains, Avalanche supports subnets — customizable, application-specific blockchains that run on Avalanche infrastructure with their own validator sets, virtual machines, and tokenomics. Each subnet exposes its own RPC endpoint, independent from the C/X/P-Chain endpoints. If you are building on or integrating with an Avalanche subnet, you will need a separate managed endpoint for that subnet in addition to your primary chain endpoints. For a deeper look at subnet architecture and development, see the Avalanche subnet series on the Chainstack Blog.
How Avalanche RPC differs from Ethereum RPC
For C-Chain development, Avalanche is intentionally Ethereum-equivalent — the same tooling, the same methods, the same mental model. The differences that matter for RPC selection are below the application layer.
| What | Avalanche C-Chain | Ethereum |
|---|---|---|
| Block time | ~2 seconds | ~12 seconds |
| Finality | ~1–2 seconds (Snowman consensus) | ~12 seconds (single slot) |
| Throughput | Hundreds of TPS, peaks above 1,000 | ~15–30 TPS (L1) |
| Gas token | AVAX | ETH |
| Consensus (C-Chain) | Snowman (linear, probabilistic BFT) | Proof of Stake |
| Chain ID | 43114 (mainnet) / 43113 (Fuji) | 1 (mainnet) |
| Multi-chain API | C-Chain + X-Chain + P-Chain (separate endpoints) | Single chain, single endpoint |
| WebSocket on public API | C-Chain only | Full support |
The finality difference is significant for RPC infrastructure design. Snowman consensus finalizes transactions probabilistically in under two seconds — there is no waiting for multiple block confirmations the way Ethereum applications often do. Applications that implement Ethereum-style confirmation polling on Avalanche are adding unnecessary latency and request volume. The right pattern is to treat a single confirmed block as final on C-Chain.
Avalanche RPC endpoint options
Public vs private Avalanche RPC endpoints
The three-chain architecture means provider evaluation is not just about C-Chain performance — it is about whether the provider covers all three chains and whether WebSocket is available beyond C-Chain. The public API handles light workloads well, but drops WebSocket streams under heavy load and does not offer WebSocket for X-Chain.
Official public Avalanche endpoints (Mainnet):
- C-Chain:
https://api.avax.network/ext/bc/C/rpc - X-Chain:
https://api.avax.network/ext/bc/X - P-Chain:
https://api.avax.network/ext/P
Fuji Testnet:
- C-Chain:
https://api.avax-test.network/ext/bc/C/rpc
⚠️ WebSocket limitation: The public API supports WebSocket only on the C-Chain. X-Chain and P-Chain WebSocket connections are not available on the public API node. For applications that subscribe to X-Chain events, managed infrastructure is required.
| Feature | Public API (api.avax.network) | Private RPC (Chainstack) |
|---|---|---|
| Access | Free, no auth required | Authenticated, isolated |
| Resources | Shared, load-balanced | Dedicated resources |
| C-Chain coverage | Full JSON-RPC | Full JSON-RPC |
| X-Chain coverage | Available, throttled | Available, stable |
| P-Chain coverage | Available, throttled | Available, stable |
| WebSocket | C-Chain only | C-Chain + X-Chain |
| Archive access | Not available | C-Chain archive available |
| Best use case | Testing, light reads | All production workloads |
For DeFi protocols and smart contract applications that only touch the C-Chain, the public API is a reasonable starting point. The moment your application needs reliable X-Chain or P-Chain access — or sustained WebSocket subscriptions — managed infrastructure becomes necessary.
📖 For a detailed provider comparison including performance benchmarks and feature analysis, see Best Avalanche RPC providers in 2026.
Full node vs archive Avalanche node
Archive support on Chainstack is available for the C-Chain only. X-Chain and P-Chain archive access is not currently offered. Plan your data architecture around this boundary.
| Full node access | Archive node access (C-Chain only) |
|---|---|
| Current C-Chain contract state | Historical C-Chain state at any block height |
| Recent DeFi protocol queries | Long-range eth_getLogs backfills for analytics |
| X-Chain and P-Chain API calls | DeFi protocol TVL history and liquidation audits |
| Real-time event monitoring | Block explorer-grade data for C-Chain |
| Transaction broadcasting | Compliance and regulatory reporting |
Archive access starts at $49/month on Chainstack — confirm whether your use case requires historical C-Chain state queries before choosing a plan. For subnet development and most DeFi applications, full node access is sufficient.
📖 Learn more about Chainstack archive data and what it enables for C-Chain historical queries.
HTTPS vs WebSockets
Avalanche’s sub-two-second finality changes the calculus on WebSocket usage compared to slower chains. Real-time monitoring matters more when blocks come fast — a two-second polling interval on C-Chain already feels sluggish for latency-sensitive applications.
| Feature | HTTPS | WebSocket |
|---|---|---|
| Model | Request/response | Persistent connection |
| Complexity | Simple operationally | Requires reconnect/heartbeat logic |
| Best for | C-Chain contract calls, P-Chain/X-Chain queries, batch reads | C-Chain real-time tx monitoring, DeFi event streams, MEV bots |
| Latency | Standard | Lower for high-frequency C-Chain updates |
| Connection overhead | Per request | One-time handshake |
A critical constraint: WebSocket subscriptions are available on C-Chain only — both on the public API and on Chainstack. If your application needs event streaming from X-Chain transactions, you must poll over HTTPS. Design for this upfront rather than discovering it when you try to subscribe to X-Chain events in production.
How to get a private Avalanche RPC endpoint with Chainstack
- Log in to the Chainstack console (or create an account)
- Create a new project
- Select Avalanche as your blockchain protocol
- Choose network: Avalanche Mainnet or Fuji Testnet
- Deploy the node
- Open Access/Credentials and copy your C-Chain, X-Chain, and P-Chain endpoint URLs
- Run a connectivity check on each chain you plan to use before wiring into production
Connect to the C-Chain with ethers.js using your Chainstack endpoint:
const { ethers } = require("ethers");
const provider = new ethers.providers.JsonRpcProvider(
"YOUR_CHAINSTACK_ENDPOINT/ext/bc/C/rpc",
43114 // C-Chain Mainnet chain ID — use 43113 for Fuji Testnet
);
// Confirm connectivity: fetch the latest block number
provider.getBlockNumber().then((blockNumber) => {
console.log("Latest C-Chain block:", blockNumber);
});
📖 For the full integration guide including X-Chain with AvalancheJS, WebSocket setup, Hardhat, Foundry, and Brownie configuration, see the Chainstack Avalanche tooling documentation.
Using Chainlist
Chainlist lists the Avalanche C-Chain (chain ID 43114) and Fuji Testnet (chain ID 43113), and can be used to add them to MetaMask or Rabby in one click. It does not list the X-Chain or P-Chain, as those are not EVM networks. Chainlist is not an infrastructure provider — any public RPC URL added through Chainlist should be replaced with your managed endpoint before going to production.
Chainstack pricing for Avalanche RPC
Chainstack counts requests uniformly across all three Avalanche chains — a C-Chain eth_call, an X-Chain avm.getBalance, and a P-Chain platform.getCurrentValidators all draw from the same monthly request pool at a flat rate per request unit.
| Plan | Cost | Requests/Month | RPS | Overage (per 1M extra) |
|---|---|---|---|---|
| Developer | $0 | 3M (~25 RPS) | ~25 | $20 |
| Growth | $49 | 20M | ~250 | $15 |
| Pro | $199 | 80M | ~400 | $12.5 |
| Business | $499 | 200M | ~600 | $10 |
| Enterprise | From $990 | 400M+ | Custom | From $5 |
Advanced options:
- C-Chain Archive Node: Complete C-Chain historical data starting at $49/month
- Unlimited Node add-on: Flat monthly pricing for unmetered usage within your RPS tier
- Dedicated Nodes: From $0.50/hour (+ storage) — recommended for high-frequency DeFi bots and MEV applications that need consistent sub-second response times
How to estimate monthly cost
- Separate your C-Chain, X-Chain, and P-Chain request volumes — they add up to a single pool but sizing them individually prevents surprises
- Factor in WebSocket subscription keepalives — persistent connections generate periodic heartbeat requests
- Account for Avalanche’s block speed: at ~2-second blocks, a bot polling every block hits ~1.3M requests/month per polling loop
- Add 25–35% buffer for DeFi protocol activity spikes — Avalanche traffic correlates with AVAX price movements and cross-chain bridge volume
- If you use archive for historical
eth_getLogsbackfills, estimate query volume separately — wide-range log queries can be expensive per call
For Avalanche specifically: Applications that also interact with subnets add a separate endpoint and request stream per subnet. If you are building multi-subnet infrastructure, account for each subnet’s traffic independently from the primary chain endpoints.
Production readiness checklist
Before launch, validate these basics:
- Primary + fallback RPC provider configured — use Chainstack Compare to benchmark endpoint latency across providers before committing
- Request timeout set — P-Chain queries for validator sets can be slower than C-Chain reads
- Retry logic with exponential backoff implemented
- Credentials stored in env/secret manager, never hardcoded
- Monitoring and alerting in place for latency, error rate, and throttling
Avalanche-specific items:
- Separate endpoint URLs configured for C-Chain, X-Chain, and P-Chain — do not send all requests to the C-Chain URL
- Chain ID validated at startup (
eth_chainIdreturns 43114 on mainnet, 43113 on Fuji) — fail fast on mismatch - WebSocket reconnect logic and heartbeat handling in place for C-Chain subscriptions
- Snowman finality model applied — treat one confirmed block as final on C-Chain instead of waiting for multiple confirmations
- X-Chain WebSocket limitation documented in your runbooks — polling fallback implemented if you need X-Chain event monitoring
Troubleshooting common Avalanche RPC issues
| Issue | Likely Cause | How to Fix |
|---|---|---|
| X-Chain or P-Chain calls return 404 | Request sent to C-Chain /ext/bc/C/rpc endpoint | Use chain-specific paths: /ext/bc/X for X-Chain, /ext/P for P-Chain |
| WebSocket fails on X-Chain | X-Chain WebSocket not available on public API | Switch to HTTPS polling for X-Chain events; use managed provider for WSS |
eth_getLogs returns empty on old blocks | Full node queried beyond its retained history | Switch to C-Chain archive node for historical log queries |
| Wrong chain ID in MetaMask | Connected to Fuji (43113) instead of Mainnet (43114) | Validate eth_chainId at startup; enforce correct chain ID in wallet connection logic |
| High latency on validator queries | P-Chain getCurrentValidators is a heavy call | Cache validator set responses locally; reduce polling frequency to minutes, not seconds |
429 Too Many Requests | Public API rate limit hit during burst | Move to managed endpoint; public API drops WebSocket streams and throttles under load |
Conclusion
Most Avalanche integration failures are not network issues — they are routing issues. A request to /ext/bc/C/rpc that should have gone to /ext/bc/X returns an error that tells you nothing useful. A WebSocket subscription that works on C-Chain silently fails on X-Chain because the public API never supported it there. These are not edge cases; they are the standard failure modes for teams who treat Avalanche as a single-endpoint EVM chain without reading the architecture first.
The pattern that works: start on C-Chain with the public API, lock down your endpoint routing per chain before writing application logic, and move to managed infrastructure the moment your workload involves X-Chain, sustained WebSocket connections, or historical data queries against the C-Chain archive. That last step is not optional for production — it is the point where the public API’s limitations become your users’ problem.
Start with Chainstack’s free tier (3M requests/month across all three chains), validate your chain-specific endpoint routing and WebSocket behavior in staging, then scale to dedicated infrastructure as DeFi or subnet traffic grows.
FAQ
For pure smart contract development — deploying contracts, reading DeFi state, monitoring events — yes. The C-Chain is fully EVM-compatible and your existing Ethereum tooling works without modification. You only need X-Chain if your application handles native AVAX asset transfers between chains, and P-Chain only if you interact with staking, validators, or subnet management.
Yes, meaningfully. Snowman consensus finalizes C-Chain transactions in approximately one to two seconds, so the standard Ethereum pattern of waiting for multiple block confirmations adds unnecessary latency and doubles or triples your polling request volume. For most applications, treating one confirmed Avalanche block as final is the correct and safe approach.
For C-Chain development, any Ethereum-compatible SDK works without modification — ethers.js, web3.js, viem, Hardhat, and Foundry all connect to the C-Chain endpoint using standard Ethereum JSON-RPC. For X-Chain and P-Chain operations, AvalancheJS is the primary SDK, providing typed methods for asset transfers, staking queries, and subnet interactions that are not available in EVM tooling.
Yes — MetaMask connects to the C-Chain using the standard EVM network configuration (chain ID 43114, RPC URL pointing to your C-Chain endpoint). MetaMask does not support the X-Chain or P-Chain, as those are not EVM-compatible. For native AVAX cross-chain transfers, Core Wallet is the recommended alternative as it natively supports all three chains.
For low-volume C-Chain applications, the public API is a reasonable starting point. The hard limits arrive when you need reliable WebSocket connections (public streams drop under load), X-Chain WebSocket subscriptions (not available publicly), archive data for historical queries, or consistent throughput for DeFi bots and MEV strategies. Any of these requirements means moving to managed infrastructure.
Track latency separately per chain — C-Chain reads, X-Chain queries, and P-Chain validator calls have very different response time profiles. Monitor WebSocket reconnect frequency on C-Chain subscriptions, 429 response rates, and archive query response times if you use historical data. For DeFi applications, also track eth_getLogs query latency — wide block ranges against the archive are the most common source of unexpected slowdowns.