Summary
Base mainnet uses chain ID 8453, and Base Sepolia uses chain ID 84532. You need the correct chain ID plus an RPC URL whenever you add Base to a wallet or point a client at the network. OnFinality offers a free public Base RPC endpoint at https://base.api.onfinality.io/public, so you can connect and test without signing up. For production traffic, a dedicated Base node gives you predictable capacity and isolation. See RPC pricing and supported networks for details.
If you searched for a free Base chain ID, you probably need two things at once: the numeric chain ID to register the network, and an RPC URL that actually responds. This page gives you both, then explains when a free public endpoint is enough and when you should move to dedicated Base infrastructure.
Chain settings at a glance
Base is an Ethereum Layer 2 built on the OP Stack. That matters for configuration because Base uses EVM-compatible tooling: the same JSON-RPC methods, the same wallet flows, and the same client libraries you already use on Ethereum. The only things that change are the chain ID, the RPC URL, and the block explorer.
| Setting | Base mainnet | Base Sepolia (testnet) |
|---|---|---|
| Chain ID | 8453 | 84532 |
| Chain name | Base | Base Sepolia Testnet |
| Native currency | ETH (18 decimals) | ETH (18 decimals) |
| Block explorer | https://basescan.org | https://sepolia.basescan.org |
| OnFinality public RPC | https://base.api.onfinality.io/public | https://base-sepolia.api.onfinality.io/public |
Use mainnet (8453) for anything touching real funds. Use Sepolia (84532) for development, staging, and contract testing before you deploy. Mixing the two is one of the most common configuration mistakes, and it usually shows up as a transaction that "succeeds" against the wrong network.
Which endpoint should you actually use?
The chain ID answers "which network." The RPC URL answers "how do I talk to it." Those are separate decisions, and the right RPC choice depends on your workload.
- Local development and quick tests: the free public endpoint is fine. You can point a script or a wallet at it and start sending requests immediately.
- Testnet and CI pipelines: use the Base Sepolia public endpoint. It keeps test traffic off mainnet and is easy to reset.
- Production apps with steady traffic: move to a managed or dedicated endpoint. Public endpoints are shared, so throughput and rate behavior are not something you control.
- Heavy read workloads (indexers, analytics,
eth_getLogs): plan for archive access and higher request volume, which is where dedicated nodes help most.
If you are not sure yet, start on the public endpoint, measure your request patterns, then decide. The Base network page lists the current endpoint and transport details, and RPC pricing shows what managed plans look like when you outgrow the free tier.
Add Base to a wallet
Most wallets let you add a custom network with the same four fields. Here is the mainnet configuration:
Network name: Base
RPC URL: https://base.api.onfinality.io/public
Chain ID: 8453
Currency symbol: ETH
Block explorer: https://basescan.org
For testnet, swap in the Sepolia values:
Network name: Base Sepolia
RPC URL: https://base-sepolia.api.onfinality.io/public
Chain ID: 84532
Currency symbol: ETH
Block explorer: https://sepolia.basescan.org
If a wallet rejects the network, the usual cause is a chain ID typo (8453 vs 84532) or an RPC URL that has been copied with a trailing space. Re-enter both fields carefully before assuming the endpoint is down.
Verify the endpoint with a request
The fastest way to confirm your chain ID and RPC URL agree is to ask the node directly. eth_chainId returns the chain ID as a hex string, so 0x2105 should decode to 8453.
curl -s https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
A healthy response looks like this:
{"jsonrpc":"2.0","id":1,"result":"0x2105"}
You can also confirm the latest block is advancing, which tells you the endpoint is synced and serving fresh data:
curl -s https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
If eth_chainId returns 0x2105 but your app still fails, the problem is almost always in the client config rather than the endpoint.
Configure a JavaScript client
With ethers or viem, the chain ID is usually passed as a number while the RPC URL is a string. Keeping them in one config object avoids drift between environments.
import { createPublicClient, http } from "viem";
import { base, baseSepolia } from "viem/chains";
const client = createPublicClient({
chain: base, // chain ID 8453
transport: http("https://base.api.onfinality.io/public"),
});
const blockNumber = await client.getBlockNumber();
console.log("Base head block:", blockNumber);
For testnet, switch the chain object to baseSepolia and the URL to the Sepolia endpoint. If you prefer ethers, the pattern is the same: pass 8453 as the chainId and the RPC URL as the provider URL. Mismatches between the two throw errors like chainId mismatch or network changed, which are configuration bugs, not node failures.
Common failure modes and how to read them
When something breaks, the error message usually points to one of a few root causes. This table maps the symptom to the likely fix.
| Symptom | Likely cause | What to do |
|---|---|---|
chainId mismatch | Client chain ID does not match the RPC | Confirm 8453 (mainnet) or 84532 (Sepolia) |
| Transactions fail instantly | Wrong network in wallet | Switch the wallet to the matching Base network |
eth_getLogs times out | Large block range or shared endpoint limits | Narrow the range or move to a dedicated node |
| Intermittent 429 responses | Shared public endpoint under load | Add retries, then plan a managed endpoint |
| Stale block number | Endpoint not synced or wrong URL | Re-check the RPC URL and retry |
| Contract call reverts unexpectedly | Deployed on a different network than you query | Verify the contract address per network |
A useful habit is to log the chain ID your app resolves at startup. That single line catches most misconfiguration before it reaches a user.
When the free endpoint stops being enough
Public endpoints are a good default for learning, testing, and low-volume tools. They are shared infrastructure, so you should not treat them as a capacity guarantee. As your app grows, a few signals tell you it is time to move on:
- You see rate-limit responses during peak traffic.
- Your indexer or analytics job needs large
eth_getLogsranges or archive data. - You need consistent latency for user-facing transactions.
- You want isolation so another team's traffic cannot affect yours.
At that point, a dedicated Base node gives you a private endpoint with capacity you control. OnFinality provides both a managed RPC API and dedicated node options, so you can start on the public endpoint and scale without changing your client code. Review supported RPC networks to confirm Base and Base Sepolia coverage, and dedicated nodes for isolation and throughput details.
Testnet workflow: from Sepolia to mainnet
A clean promotion path reduces surprises on launch day:
- Develop against Base Sepolia (84532) using the public testnet endpoint.
- Run integration tests in CI with the same chain ID and RPC URL your staging environment uses.
- Verify contract addresses and constructor arguments per network before deploying.
- Switch the chain ID and RPC URL to mainnet (8453) in one config change, not scattered across files.
- Re-run
eth_chainIdand a read call against mainnet to confirm the switch.
Keeping chain ID and RPC URL in a single environment-driven config is the simplest way to avoid deploying to the wrong network.
Key Takeaways
- Base mainnet chain ID is 8453; Base Sepolia is 84532.
- The free OnFinality Base RPC endpoint is
https://base.api.onfinality.io/public; the Sepolia endpoint ishttps://base-sepolia.api.onfinality.io/public. - Verify configuration with
eth_chainId(0x2105= 8453) before debugging anything else. - Public endpoints suit development and low-volume use; production and data-heavy workloads benefit from managed or dedicated nodes.
- Keep chain ID and RPC URL in one config object to prevent network mismatches.
Frequently Asked Questions
Is the Base chain ID free to use? Yes. A chain ID is just a public network identifier. There is no cost to read or use it; you only pay for the infrastructure you choose to run against it.
What is the Base mainnet chain ID?
8453. In hex it is 0x2105, which is what eth_chainId returns.
What is the Base Sepolia chain ID? 84532. Use it for testnet development and staging.
Can I use a free Base RPC endpoint in production? You can start there, but public endpoints are shared. For steady production traffic, plan for a managed or dedicated endpoint so capacity is predictable.
Why does my app say chain ID mismatch? Your client's configured chain ID does not match the network the RPC URL points to. Confirm 8453 for mainnet or 84532 for Sepolia and that both values come from the same config.
Do I need a different RPC URL for testnet? Yes. Base Sepolia uses a separate endpoint. Pointing a testnet chain ID at a mainnet URL (or the reverse) will fail.
Where can I see which networks OnFinality supports? The supported RPC networks page lists current coverage, including Base and Base Sepolia.