All Blockchain Networks: Building a Working Inventory for Your Project

Why a Universal List of All Blockchains Does Not Stay True

Searches for all blockchain networks usually return two kinds of pages: encyclopedic lists that enumerate hundreds of chains, and explainers that define what a blockchain is. Both are useful starting points, but neither is a reliable operational reference. A list of blockchains is a dynamic document. New layer 1 and layer 2 networks launch, testnets are reset or deprecated, forks split existing chains, and some networks wind down entirely. Wikipedia's own list of blockchains carries an explicit incompleteness notice for this reason.

For engineering work, the question is not "what are all blockchains" in the abstract but "which networks does my system depend on, and what is the verified identity of each one?" A chain's identity is anchored in its chain ID, its genesis block, and its native currency metadata. Those are the fields you can test. Names and marketing descriptions are not testable and drift over time.

This guide therefore treats the topic as an inventory problem. You will scope the list to your project, verify each entry against a live RPC endpoint, and store the results in a table you can re-run whenever you suspect drift.

• Encyclopedic lists are snapshots and are explicitly incomplete.
• Chain identity is verifiable through chain ID and genesis data.
• Your inventory should be scoped to chains your code actually touches.

Scoping the Inventory Before You Collect Anything

Before collecting chain data, classify every network your project interacts with. Most multi-chain applications fall into four buckets: production layer 1 networks, production layer 2 rollups, testnets used in CI or staging, and archival or read-only chains used for analytics. Each bucket has different reliability requirements, and mixing them in one flat list makes verification noisy.

A useful scoping exercise is to grep your codebase and infrastructure configuration for chain identifiers. Look for chain ID constants, RPC URL environment variables, contract deployment records, and bridge configuration. Anything that appears in a deployment manifest is production-critical; anything that appears only in test fixtures can be verified less frequently.

Once scoped, assign each chain a role: primary settlement, execution, data availability, or read-only reference. This role determines how often you re-verify the entry and how much redundancy the endpoint needs. For endpoint selection across many chains, the multi-chain RPC endpoints guide at /en/learn/multi-chain-rpc-endpoints-guide covers the tradeoffs between shared gateways and per-chain providers.

• Production L1s, L2 rollups, testnets, and archival chains need separate verification cadences.
• Grep for chain IDs, RPC URLs, and deployment manifests to find implicit dependencies.
• Assign each chain a role so verification effort matches criticality.

The Mental Model: Chain Identity Versus Endpoint Identity

A common source of bugs is conflating a chain with the endpoint that serves it. The chain is the canonical ledger defined by its genesis block and consensus rules. The endpoint is a service that answers JSON-RPC calls about that chain. One chain can be served by many endpoints, and one endpoint provider can serve many chains. Your inventory must record both layers separately.

At the chain layer, record the chain ID, the genesis block hash where available, the native currency symbol and decimals, and the block explorer URL. At the endpoint layer, record the provider, the URL pattern, the authentication method, and the rate limits. When a call fails, this separation tells you whether the chain changed or the endpoint did.

This model also explains why chain ID checks matter so much. A misconfigured endpoint that points at the wrong network will happily accept transactions and sign them for the wrong chain. Verifying chain ID before every write path is cheap insurance. The nonce explainer at /en/learn/what-is-a-blockchain-nonce is a useful companion for understanding how transaction sequencing interacts with endpoint correctness.

• Chain identity: chain ID, genesis hash, native currency, explorer.
• Endpoint identity: provider, URL, auth, rate limits, supported methods.
• Verify chain ID on every write path to prevent cross-chain signing errors.

Collecting Candidate Chains from Multiple Sources

No single source lists all blockchains completely, so triangulate. Start with the chain registry maintained by your wallet or SDK vendor, cross-reference with block explorer directories, and add any chain that appears in your own dependency graph. Treat each source as a candidate generator, not as truth.

For each candidate, capture the source it came from and the date you captured it. This provenance matters when two sources disagree about a chain ID or currency symbol. Disagreements are common for forked chains and for testnets that reuse names.

When you need a concrete endpoint for a specific chain, the RPC Assistant covers individual network recommendations. For example, the Arbitrum RPC endpoints guide at /en/learn/arbitrum-rpc-endpoints and the Solana provider guide at /en/learn/best-solana-rpc-provider address per-chain endpoint choice. Use those for endpoint selection and keep this article focused on the inventory method.

• Triangulate from wallet registries, explorer directories, and your own code.
• Record provenance and capture date for every candidate.
• Resolve disagreements by testing against live chain data, not by trusting the louder source.

Verifying Chain IDs and Metadata with curl

The fastest verification is a direct JSON-RPC call. The eth_chainId method returns the chain ID as a hexadecimal string. Compare it against your expected value after converting to decimal. The following script iterates over a candidate list and prints a pass or fail for each entry.

Replace RPC_URL_* with your actual endpoints. Do not hardcode public endpoints in production scripts; use environment variables or a secrets manager.

#!/usr/bin/env bash
set -euo pipefail

declare -A CHAINS=(
  [ethereum]="${RPC_URL_ETHEREUM}"
  [arbitrum]="${RPC_URL_ARBITRUM}"
  [base]="${RPC_URL_BASE}"
)

declare -A EXPECTED=(
  [ethereum]=1
  [arbitrum]=42161
  [base]=8453
)

for name in "${!CHAINS[@]}"; do
  url="${CHAINS[$name]}"
  hex=$(curl -s -X POST "$url" \
    -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \
    | python3 -c 'import sys,json; print(json.load(sys.stdin)["result"])')
  actual=$((hex))
  if [[ "$actual" -eq "${EXPECTED[$name]}" ]]; then
    echo "PASS $name chainId=$actual"
  else
    echo "FAIL $name expected=${EXPECTED[$name]} actual=$actual"
  fi
done

Verifying Endpoint Health and Block Progress with JavaScript

Chain ID alone does not prove an endpoint is healthy. An endpoint can report the correct chain ID while lagging behind the chain head or failing to serve historical state. Add a second check that compares the endpoint's latest block number against a reference endpoint or against the chain's public explorer.

The script below queries eth_blockNumber and eth_getBlockByNumber for the latest block, then prints the block timestamp. A large gap between the block timestamp and wall-clock time indicates a lagging endpoint. Run this from the same region as your production workload, because latency and availability vary by geography.

This is a measurement you must run yourself. Do not assume a provider's published uptime reflects your region or your method mix.

const endpoints = {
  ethereum: process.env.RPC_URL_ETHEREUM,
  arbitrum: process.env.RPC_URL_ARBITRUM,
};

async function rpc(url, method, params = []) {
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params }),
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

for (const [name, url] of Object.entries(endpoints)) {
  const blockHex = await rpc(url, 'eth_blockNumber');
  const block = await rpc(url, 'eth_getBlockByNumber', [blockHex, false]);
  const ts = Number(BigInt(block.timestamp) * 1000n);
  const lagSeconds = Math.round((Date.now() - ts) / 1000);
  console.log(`${name} block=${Number(blockHex)} lag=${lagSeconds}s`);
}

Recording Results in a Reproducible Table

Store verification output in a table so you can compare runs over time. The table below is a template; fill it with the values your scripts produce. Do not copy numbers from any external source, including this article.

Run the table on a schedule, at minimum before each production deployment and after any provider change. Keep historical runs in version control so you can correlate incidents with endpoint drift. If you operate dedicated infrastructure, the dedicated node guide at /en/dedicated-node explains how to control the endpoint layer directly rather than depending on a shared gateway.

Troubleshooting Common Inventory Failures

When a verification fails, the cause usually falls into one of four categories. Distinguishing them quickly saves time.

First, chain ID mismatch. This almost always means the endpoint URL points at a different network than intended, often a testnet or a fork. Check the URL against your provider's documentation and confirm the environment variable is set in the right environment.

Second, block lag. A lagging endpoint may be rate-limited, geographically distant, or serving a pruned node. Compare against a second endpoint for the same chain. If both lag, the chain itself may be experiencing finality issues.

Third, method not supported. Some endpoints restrict historical queries or debug methods. If your inventory includes archival reads, verify those methods explicitly rather than assuming eth_chainId success implies full support.

Fourth, authentication failure. API keys expire, rotate, or are scoped to specific chains. A 401 or 403 response should be logged distinctly from a JSON-RPC error so you can route it to the right on-call rotation.

• Chain ID mismatch: wrong URL or wrong environment.
• Block lag: rate limits, distance, or pruned state.
• Unsupported method: verify archival and debug calls separately.
• Auth failure: expired or mis-scoped API keys.

Limitations and Tradeoffs of Any Chain Inventory

Every inventory is a snapshot. Chains launch, testnets reset, and providers change their supported network lists. A list that is accurate today may be wrong next quarter. Budget for re-verification rather than assuming completeness.

There is also a cost tradeoff. Verifying every chain on every deploy is expensive in time and API calls. Tier your checks: critical settlement chains on every deploy, execution chains daily, testnets weekly, archival chains on demand. This matches verification effort to blast radius.

Finally, be cautious about treating any third-party list as authoritative. Lists maintained by wallet vendors optimize for wallet compatibility, not for your application's needs. Lists maintained by explorers optimize for explorer coverage. Neither is a substitute for testing the specific methods your code calls.

Next Steps: Automating and Extending the Inventory

Move the verification scripts into your CI pipeline as a pre-deploy gate. Fail the build if a production chain's chain ID does not match the expected value. This catches configuration drift before it reaches users.

Extend the inventory with contract addresses per chain. A chain entry is incomplete without the addresses of the contracts your application calls, and those addresses differ across networks. Store them alongside the chain metadata so a single lookup returns everything needed to construct a transaction.

For endpoint selection across the chains in your inventory, review the pricing and network coverage at /en/pricing/rpc and /en/networks, and consult the RPC Assistant for per-chain recommendations. The blockchain node hosting guide at /en/learn/blockchain-node-hosting-guide covers the operational side of running your own nodes for chains where shared endpoints are insufficient.

Re-run the verification table after every provider change and after every major chain upgrade. Treat the inventory as a living artifact, not a one-time document.

• Add chain ID checks to CI as a pre-deploy gate.
• Record per-chain contract addresses alongside chain metadata.
• Re-verify after provider changes and chain upgrades.