What Is the Base Chain ID?
The Base mainnet chain ID is 8453, or 0x2105 in hexadecimal. Base Sepolia, the test network, uses chain ID 84532, or 0x14a34. A chain ID identifies the network in every signed transaction, so a signature made for one network cannot be replayed on another, and wallets and libraries use it to route requests correctly.
What a chain ID does
EVM networks share the same transaction format, address format, and key types. Without something distinguishing them, a transaction signed for one network would be equally valid on another that shares the account, and anyone could rebroadcast it there. That is a replay attack.
The chain ID solves this. Since the change standardised as EIP-155, the chain ID is part of the data that is signed. A signature made for chain 8453 is only valid on chain 8453. Broadcasting it to Ethereum mainnet, chain 1, or to any other network fails verification.
Chain IDs also appear outside transactions.
Typed data signatures. Structured signing messages, such as permits and payment authorisations, include a domain that usually contains the chain ID, so an off-chain authorisation for one network cannot be used on another.
Wallet network configuration. Wallets use the chain ID to identify a network when it is added or when an application asks to switch.
Library clients. Web3 libraries use it to select network settings and to check that the connected endpoint is the one intended.
The numbers
Base mainnet: 8453, hex 0x2105. Base Sepolia: 84532, hex 0x14a34. Ethereum mainnet, for comparison: 1. The public RPC endpoints Base publishes are mainnet.base.org and sepolia.base.org. They are rate limited and meant for light use; production systems usually use a dedicated RPC provider.
Configuring it
In a wallet. Most wallets already list Base. If adding it manually, you need the network name, the chain ID 8453, an RPC URL, ETH as the currency symbol, and a block explorer URL. Get the RPC and explorer values from Base's documentation, not from an unfamiliar website, since a malicious RPC can misreport balances and transaction status.
In application code. Set the chain ID explicitly in the client configuration rather than relying on whatever the RPC reports, then compare the two at startup. Most libraries include a predefined Base chain object with the correct ID; use it where available.
In typed data domains. Put the chain ID in the signing domain for any off-chain authorisation. A permit or payment authorisation without a chain ID in its domain can be valid on more networks than intended.
Per environment. Keep mainnet and testnet chain IDs in separate configuration, and make it impossible for a testnet deployment to pick up mainnet keys or the reverse.
Checking a library's built-in chain definition
Predefined chain objects in libraries are convenient and occasionally carry stale RPC URLs or explorer links. The chain ID itself does not change, but confirm the other fields against Base's documentation when upgrading a library version.
Verifying and troubleshooting
Ask the endpoint. The standard eth_chainId RPC method returns the chain ID of the connected network as a hexadecimal string. A Base mainnet endpoint returns 0x2105. Check this every time a process starts, and refuse to sign if it does not match configuration.
Wrong network errors. A wallet that rejects a request with a chain mismatch usually means the application expects Base and the wallet is on another network, or the reverse. Prompt a network switch rather than retrying.
Signatures that do not verify. An authorisation signed with the wrong chain ID in its domain produces a valid signature that fails verification on the intended network. Compare the domain used for signing with the one the verifying contract expects.
Funds that seem missing. If a transaction was signed and sent on a different network, the funds are at the same address on that other chain. The chain ID in the transaction record in a block explorer shows where it went.
For payment systems, including agents that pay per call, a startup check that the endpoint's chain ID equals the configured one is a few lines of code that prevent a whole class of expensive mistakes.
Why agents should pin it
An agent that selects networks dynamically, for example from a server's payment requirements, should compare any requested network against an allowlist of chain IDs it is configured to pay on. CryptoCadet settles on Base only, so the only acceptable mainnet chain ID is 8453.
Frequently asked questions
- What is the Base chain ID?
- Base mainnet uses chain ID 8453, which is 0x2105 in hexadecimal. The Base Sepolia test network uses chain ID 84532, which is 0x14a34. Wallets, libraries, and signed transactions use these numbers to identify which network a request or signature belongs to.
- Why does a chain ID matter?
- It is included in signed transactions and in typed data signing domains, so a signature made for one network cannot be replayed on another. It also lets wallets and libraries confirm they are connected to the network the application intends to use.
- How do I check which chain an RPC endpoint is on?
- Call the standard eth_chainId RPC method. It returns the chain ID as a hexadecimal string, and a Base mainnet endpoint returns 0x2105. Run this check whenever a process starts and refuse to sign anything if the result differs from configuration.
- What is the chain ID for Base Sepolia?
- Base Sepolia uses chain ID 84532, or 0x14a34 in hexadecimal. It is the test network for Base, using test assets with no value, and should be configured separately from mainnet so test deployments can never pick up mainnet keys. Circle provides test USDC on it for exercising payment flows.
