Chains List: How to Find Chain IDs, RPC Endpoints, and Reliable Networks for Your App

What a chains list actually contains

A chains list is a structured directory of blockchain networks. For EVM chains, each entry typically includes the chain name, chain ID (decimal and hex), short name, native currency symbol and decimals, block explorer URLs, and one or more RPC endpoints. Non-EVM chains appear in broader lists but use different metadata because they do not share the EVM JSON-RPC interface.

The most widely referenced source is the ethereum-lists/chains repository. Each chain has its own JSON file named by its CAIP-2 identifier, and directories like Chainlist render that data into a searchable interface. When you see a chain ID in a wallet or a dApp, it usually traces back to this repository or a mirror of it.

The important distinction: a chains list tells you how to identify a network, not how to operate against it. The chain ID is stable protocol metadata. The RPC URL is an operational choice that changes with your workload, and the public endpoints in a directory are shared by everyone reading that page.

• Chain ID: the numeric identifier used in transactions and wallet configs.
• Native currency: symbol and decimals used for display and gas calculations.
• RPC URLs: one or more endpoints, often public and rate-limited.
• Explorer URLs: block explorer links for verification and debugging.
• CAIP-2 identifier: the namespace:reference format used in the upstream repository.

Quick recommendation: directory lookup vs production endpoint

Use a chains list when you need to configure a wallet, verify a chain ID, or add a testnet to a development environment. Use a managed RPC provider when you need an endpoint that will handle application traffic, archive queries, or WebSocket subscriptions without competing with anonymous users.

The table below maps common tasks to the right source. If your task is in the right-hand column, a directory entry is not the final answer.

The fields that cause the most configuration errors

Most chains-list mistakes come from three fields: chain ID, RPC URL, and currency decimals. A wrong chain ID sends a transaction to the wrong network or causes a wallet to reject a signature. A stale RPC URL produces timeouts that look like application bugs. Wrong decimals display balances incorrectly without breaking transactions, which makes the error harder to notice.

Chain ID deserves special attention because it appears in two formats. Wallets and JSON-RPC expect a hex quantity such as 0x1 for Ethereum mainnet, while many lists display the decimal form 1. Converting between them is trivial but easy to skip, and a mismatch between the configured chain ID and the endpoint's actual network will surface as an invalid chain ID error.

For RPC URLs, treat any public endpoint in a directory as a development convenience. Check whether the endpoint supports the methods you need, whether it is archive or pruned, and whether it accepts WebSocket connections before you build around it.

• Verify chain ID in both decimal and hex before configuring a wallet.
• Confirm the RPC endpoint's network by calling eth_chainId, not by trusting the label.
• Check native currency decimals; do not assume 18 for every chain.
• Prefer HTTPS endpoints; avoid mixed-content failures in browser dApps.
• Record the source and date of any chain metadata you hardcode.

Verifying a chain entry with a single request

Before you wire a chain into an application, confirm that the endpoint actually serves the network you expect. The eth_chainId method returns the chain ID as a hex quantity, which you can compare against the decimal value in the chains list.

The example below uses a placeholder endpoint. Replace it with the endpoint from your provider or the chain's official documentation; do not assume a public directory URL is production-ready.

• curl -X POST https://your-rpc-endpoint.example \
• -H "Content-Type: application/json" \
• -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
• Expected response shape: {"jsonrpc":"2.0","id":1,"result":"0x1"} for Ethereum mainnet.

From chains list to production RPC: what to evaluate

Once you move past directory lookups, the decision shifts from metadata to operations. A provider's value is in how it handles your specific workload: request volume, method mix, archive depth, and connection type. The evaluation below is a starting checklist, not a ranking.

OnFinality provides managed RPC API access and dedicated node infrastructure across a range of supported networks. For a chain-by-chain view, see supported RPC networks; for workload planning, see RPC pricing. If you need isolated capacity, dedicated nodes are the relevant option.

Reading non-EVM entries in a chains list

Not every chain in a list speaks EVM JSON-RPC. Solana, Polkadot, and other ecosystems have their own RPC interfaces and their own metadata conventions. A generic chains list may include them, but the fields will not map one-to-one to an EVM wallet config.

For non-EVM networks, the useful fields are the network identifier, the RPC endpoint, and the documentation for the chain's specific API. OnFinality's network pages for each supported chain are the better reference than a generic directory because they reflect the endpoint and method support the provider actually offers.

If you are building multi-chain, keep a per-ecosystem config rather than forcing everything into one EVM-shaped schema. That avoids silent failures when a chain does not support a method your EVM code assumes.

• EVM chains: chain ID, currency, explorer, JSON-RPC endpoint.
• Solana: cluster name, RPC endpoint, WebSocket endpoint.
• Polkadot and Substrate: network name, RPC endpoint, chain-specific methods.
• Keep separate config objects per ecosystem to avoid method mismatches.

A practical workflow for adding a new chain

When a new chain appears in your roadmap, the sequence below keeps metadata and infrastructure decisions separate. It also gives you a record of what you verified and when.

Start with the upstream repository or the chain's official documentation, not a third-party mirror. Confirm the chain ID with a live eth_chainId call. Then decide whether the chain is a testnet or production target, and choose an endpoint accordingly. For production, prefer a managed provider with documented limits over a public directory URL.

• 1. Find the chain in the upstream repository or official docs.
• 2. Record chain ID, currency decimals, and explorer URL.
• 3. Verify the endpoint with eth_chainId before configuring the app.
• 4. Decide testnet vs production and choose an endpoint class.
• 5. Add failover and monitoring before launch.
• 6. Re-check metadata when the chain announces upgrades.

Frequently Asked Questions