Base Network RPC: How Do I Connect and Which Endpoint Should I Use?

Base is an Ethereum Layer 2 built on the OP Stack. For developers, that means the RPC surface looks almost exactly like Ethereum: the same JSON-RPC methods, the same eth_ namespace, and the same client libraries. If you already have Ethereum code, connecting to Base is usually a matter of changing the chain ID and the RPC URL.

This page is a working reference for the Base network RPC. It covers the chain settings you need, request examples you can run immediately, the failure modes that show up most often, and how to decide between a public endpoint, a managed RPC API, and a dedicated node as your traffic grows.

Which Base endpoint should you use?

Start by matching the endpoint to your workload. The right choice depends less on the chain and more on how much traffic you send, whether you need archive or trace data, and how much downtime costs you.

A quick rule: if a failed request means a user sees an error, you have outgrown a shared public endpoint. If a failed request means a trading position or a bridge transfer is at risk, you should be looking at dedicated infrastructure with a failover path.

OnFinality offers Base through its RPC API service for managed access and dedicated nodes for isolated capacity. You can compare plans on the RPC pricing page and see the full list of supported RPC networks.

Base chain settings at a glance

These are the values you plug into a wallet, a library, or a config file.

Base Sepolia is the testnet you use before shipping to mainnet. It has its own chain ID and its own faucet ecosystem, so make sure your config does not mix the two. The OnFinality network pages for Base and Base Sepolia list the endpoints and details you need.

Making your first Base JSON-RPC request

Base speaks standard JSON-RPC over HTTP. The simplest possible check is a curl call to the public endpoint.

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_blockNumber",
    "params": []
  }'

A healthy response returns the latest block height in hex. From there, the usual Ethereum methods apply: eth_getBalance, eth_call, eth_getLogs, eth_getTransactionReceipt, and so on. Because Base is EVM-equivalent, most Ethereum tooling works without modification.

If you are using a managed endpoint with an API key, the URL usually carries the key as a path or query parameter. Keep that key out of client-side code and out of public repositories.

Connecting from JavaScript with viem

In practice you will connect through a library rather than raw curl. Here is a minimal viem setup for Base mainnet.

import { createPublicClient, http } from 'viem'
import { base } from 'viem/chains'

const client = createPublicClient({
  chain: base,
  transport: http('https://base.api.onfinality.io/public')
})

const blockNumber = await client.getBlockNumber()
console.log('Base block:', blockNumber)

For a managed endpoint, swap the URL for your keyed endpoint. For ethers, the pattern is the same: construct a provider with the Base RPC URL and the chain ID, then call your usual methods. The important detail is that the chain ID in your config matches the endpoint you are calling. Pointing a mainnet chain ID at a testnet endpoint is one of the most common setup mistakes.

Adding Base to a wallet

Wallets that support custom networks accept the same values. A typical network configuration looks like this:

{
  "chainId": "0x2105",
  "chainName": "Base",
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "rpcUrls": ["https://base.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://basescan.org"]
}

Note that 0x2105 is the hex form of 8453. Wallets expect the hex value, while most JavaScript libraries accept the decimal. If a wallet rejects your network, check the chain ID format first.

Where Base RPC requests usually fail

Most Base RPC problems fall into a small number of categories. Knowing them shortens debugging considerably.

Two of these deserve more detail. First, eth_getLogs is the method most likely to hit limits, because a wide block range can mean a very large result set. If you are indexing Base, plan for pagination from the start rather than discovering the limit in production. Second, nonce and gas issues on Base behave much like they do on Ethereum; if you are debugging a stuck transaction, the same nonce and replacement rules apply.

Public, managed, and dedicated: choosing for production

A public endpoint is the fastest way to start and the easiest to outgrow. It is shared, it has no commitment to your traffic, and it is the right tool for scripts, prototypes, and occasional reads.

A managed RPC API sits in the middle. You get a keyed endpoint, more predictable throughput, and support for the methods most applications need. This is the common choice for dApps with real users, where reliability matters but you do not want to run infrastructure yourself.

A dedicated node gives you isolated capacity. You are not sharing throughput with other tenants, which matters for high request volume, heavy log queries, or workloads where a failed request has a direct cost. The tradeoff is that you take on more operational responsibility, or you work with a provider that manages it for you.

OnFinality's RPC API service covers the managed case, and dedicated nodes cover the isolated case. If you are still weighing providers in general, the guide to choosing an RPC provider walks through the criteria in more depth.

A production readiness checklist for Base

Before you point real traffic at a Base endpoint, confirm the following:

• Your chain ID and endpoint match, and mainnet and testnet configs are clearly separated.
• You have retry logic with backoff for transient failures.
• You have at least one failover endpoint, or a documented plan for one.
• Your eth_getLogs usage is paginated and bounded.
• API keys are server-side only and rotated when needed.
• You monitor error rates and latency, not just uptime.
• You know which methods you depend on, including any trace or debug calls.

If any of these are missing, they are worth fixing before launch rather than after an incident.

Monitoring and failover

A simple health probe keeps you ahead of problems. Poll the latest block number on a schedule and alert if it stops advancing or if requests start failing.

#!/usr/bin/env bash
RESP=$(curl -s -o /dev/null -w "%{http_code}" https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
if [ "$RESP" != "200" ]; then
  echo "Base RPC probe failed: $RESP"
fi

For failover, keep a second endpoint configured and switch on repeated failures rather than on a single error. A single timeout is normal; a run of them is a signal.

Key Takeaways

• Base is an OP Stack L2 with an Ethereum-compatible JSON-RPC interface, so existing EVM tooling works with minimal changes.
• Base mainnet uses chain ID 8453; Base Sepolia uses 84532. Mixing them is a common source of empty or wrong data.
• Public endpoints are fine for prototypes but are shared and easy to outgrow.
• Managed RPC APIs suit dApps with real users; dedicated nodes suit high-volume or latency-sensitive workloads.
• eth_getLogs is the method most likely to hit limits, so paginate from the start.
• Always plan for failover and monitor error rates, not just availability.

Frequently Asked Questions

What is the Base network RPC URL?

For OnFinality's public Base mainnet endpoint, use https://base.api.onfinality.io/public. For Base Sepolia, use https://base-sepolia.api.onfinality.io/public. For production workloads, a keyed managed endpoint or a dedicated node is usually a better fit than a shared public URL.

What is the Base chain ID?

Base mainnet uses chain ID 8453, which is 0x2105 in hex. Base Sepolia uses 84532.

Is Base RPC the same as Ethereum RPC?

Base is EVM-equivalent and built on the OP Stack, so the JSON-RPC methods are largely the same as Ethereum's. Most Ethereum libraries and tools work against Base with only a chain ID and URL change.

Why does my Base RPC request return a 429?

A 429 usually means you have hit a rate limit on a shared endpoint. Move to a keyed managed endpoint or dedicated capacity, and add retry with backoff for transient cases.

Does Base support WebSocket subscriptions?

Transport support depends on the endpoint. Check the Base network page for the transports available, and confirm whether your provider offers WebSocket access if you need subscriptions.

How do I get testnet ETH for Base Sepolia?

Base Sepolia has its own faucet ecosystem. Use a recognized Base Sepolia faucet to fund a test wallet, and keep testnet keys separate from mainnet keys.

Can I use OnFinality for Base?

Yes. OnFinality provides Base RPC through its RPC API service and dedicated node offerings. See RPC pricing for plan details and supported RPC networks for the full network list.