Base is an Ethereum Layer 2 network. It executes transactions on its own chain and posts the resulting data back to Ethereum, which is where the term "L2 on Ethereum" comes from. For developers, the practical consequence is simple: Base speaks the same JSON-RPC dialect as Ethereum, so most tools, libraries, and contracts work with only a chain ID and RPC URL change.
This page answers the immediate question, then helps you decide how to connect. If you already know what Base is and just need settings, jump to the chain settings table. If you are evaluating how to run Base in production, the decision section below is the place to start.
Quick recommendation: which connection path fits your workload
Not every project needs the same Base setup. Use the table below to match your situation to a connection approach. The right answer depends on request volume, whether you need archive or trace data, and how much operational work you want to own.
| Your situation | Suggested approach | What to watch |
|---|---|---|
| Prototyping, scripts, low-volume reads | Public Base endpoint | Shared capacity; fine for testing, not for traffic spikes |
| Production dApp with steady traffic | Managed RPC API | Rate limits, failover, and monitoring matter |
| Heavy indexing, archive, or trace calls | Dedicated node | Storage and sync time are your responsibility |
| Compliance or data-residency needs | Dedicated node | You control the deployment environment |
| Multi-chain app including Base | Managed multi-chain RPC | Consistent tooling across chains reduces bugs |
If you are unsure, start with a managed endpoint and move to a dedicated node only when you can name the specific limit you are hitting. OnFinality provides both RPC API access and dedicated node infrastructure, so you can scale the same Base workload without changing your application code.
What Base actually is, in one paragraph
Base is a Layer 2 built on the OP Stack. It batches transactions, executes them off Ethereum mainnet, and posts compressed data back to Ethereum for settlement and data availability. Users pay fees in ETH on Base, and the network exposes an EVM-compatible interface. That means eth_call, eth_getLogs, eth_sendRawTransaction, and the rest of the standard Ethereum JSON-RPC method set behave as you expect.
The important nuance for developers is that Base is not Ethereum. It has its own chain ID, its own block explorer, and its own gas market. Contracts deployed to Ethereum mainnet are not automatically available on Base; you deploy them separately. Addresses can match if you use the same deployer and nonce, but that is a convenience, not a guarantee.
Chain settings at a glance
Use these values when adding Base to a wallet, a Hardhat config, a Foundry profile, or a viem client.
| Setting | Base mainnet | Base Sepolia testnet |
|---|---|---|
| Chain ID | 8453 | 84532 |
| Native currency | ETH (18 decimals) | ETH (18 decimals) |
| Block explorer | https://basescan.org | https://sepolia.basescan.org |
| Transport | HTTP | HTTP |
| OnFinality public RPC | https://base.api.onfinality.io/public | https://base-sepolia.api.onfinality.io/public |
For a full network reference, see the Base network page and the Base Sepolia network page.
Connecting with curl and JavaScript
The fastest way to confirm your endpoint works is a single JSON-RPC call. This returns the current block number:
curl -X POST https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
A successful response looks like {"jsonrpc":"2.0","id":1,"result":"0x..."}. If you get an error object instead, check the URL, the method name, and whether your client is sending a POST with a JSON body.
In JavaScript, the same call through viem looks like this:
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(blockNumber);
If you are using ethers, the pattern is similar: create a JsonRpcProvider with the Base RPC URL and call getBlockNumber(). The chain ID is validated by the library when you pass the chain object, which catches misconfigured endpoints early.
Wallet and network configuration
Adding Base to a wallet is a common first step for testers and support teams. The fields map directly to the chain settings table above. In MetaMask, choose "Add network manually" and enter the chain ID, RPC URL, and explorer URL. For Base Sepolia, use chain ID 84532 and the Sepolia explorer.
A frequent mistake is mixing mainnet and testnet values. If your wallet shows a balance of zero after a successful faucet claim, confirm you are on the testnet chain ID and that the faucet sent funds to the same address the wallet is displaying. Faucet availability changes over time, so check the current Base documentation rather than relying on a cached link.
Where Base fits in an Ethereum stack
Base is one of several L2s that share Ethereum tooling. If your application already supports Ethereum mainnet, adding Base is mostly a configuration change. The harder questions are operational: how do you handle reorgs, how do you index logs efficiently, and how do you keep latency predictable under load.
For teams running multiple chains, a consistent RPC layer matters more than any single chain's quirks. OnFinality supports Base alongside Ethereum and other networks, so you can use one provider and one set of credentials across your stack. See supported RPC networks for the current list.
Production readiness checklist
Before you point real users at a Base endpoint, work through these items. They are ordered by how often they cause incidents.
- Failover. Do you have a second endpoint configured? A single URL is a single point of failure.
- Rate limits. Do you know your requests per second ceiling, and does your client back off on 429 responses?
-
Archive and trace needs. Do you call
eth_getLogsover wide block ranges, or use trace methods? These are heavier and may need a dedicated node. - Reorg handling. Base, like other L2s, can reorg. Your indexer should confirm finality before treating data as settled.
- Monitoring. Do you alert on error rate and latency, not just on total downtime?
- Key management. Are RPC credentials stored outside your source tree?
If several of these are unanswered, a managed provider removes most of the operational burden. If you need control over the node itself, a dedicated node gives you that at the cost of running the infrastructure.
Common failure modes and how to read them
Most Base RPC problems fall into a small number of categories. The table below maps symptoms to likely causes.
| Symptom | Likely cause | Next step |
|---|---|---|
method not found |
Method not supported by the endpoint | Confirm the method is part of the standard EVM set |
429 Too Many Requests |
Rate limit reached | Add backoff and consider a higher tier |
Timeouts on eth_getLogs
|
Block range too wide | Narrow the range or use an indexer |
| Wrong chain data | Endpoint points to a different network | Verify chain ID with eth_chainId
|
| Stale block number | Caching or a lagging node | Compare against a second endpoint |
A quick diagnostic is to call eth_chainId and compare the result to the expected value. For Base mainnet it should return 0x2105 (8453 in decimal). For Base Sepolia it should return 0x14a34 (84532). If those do not match, you are talking to the wrong network.
Choosing between public, managed, and dedicated
The public endpoint is a good default for development and low-volume reads. It is shared, so it is not the right choice for production traffic that needs predictable latency.
A managed RPC API sits in the middle. You get a stable URL, monitoring, and the ability to scale without running nodes. This is the common choice for dApps, wallets, and backends that need Base plus a few other chains.
A dedicated node is for teams that need archive data, trace calls, custom configuration, or a specific deployment environment. The tradeoff is that you own sync time, storage, and upgrades. For most teams, the decision comes down to whether the workload justifies that ownership. OnFinality's RPC pricing page outlines the options if you want to compare cost models.
Key Takeaways
- Base is an Ethereum L2 with an EVM-compatible JSON-RPC interface, so Ethereum tooling works with a chain ID and URL change.
- Base mainnet uses chain ID 8453; Base Sepolia uses 84532.
- The OnFinality public endpoints are
https://base.api.onfinality.io/publicandhttps://base-sepolia.api.onfinality.io/public. - Public endpoints suit development; production workloads usually need managed or dedicated infrastructure.
- Always verify chain ID with
eth_chainIdwhen debugging unexpected data. - Plan for failover, rate limits, and reorg handling before launch.
Frequently Asked Questions
Is Base the same as Ethereum?
No. Base is a separate Layer 2 network that settles to Ethereum. It uses Ethereum tooling and ETH as its native currency, but it has its own chain ID and block explorer.
What is the Base chain ID?
Base mainnet is 8453. Base Sepolia is 84532.
Can I use Ethereum RPC methods on Base?
Yes. Standard EVM JSON-RPC methods such as eth_call, eth_getLogs, and eth_sendRawTransaction work on Base. Some Ethereum-specific methods may not apply.
Do I need a dedicated node for Base?
Only if you need archive data, trace calls, custom configuration, or a specific deployment environment. Most applications do fine with a managed endpoint.
How do I test Base without spending real ETH?
Use Base Sepolia and a faucet. Confirm you are on chain ID 84532 and that the faucet sent funds to your wallet address.
Where can I find OnFinality's Base endpoints?
See the Base network page and the Base Sepolia network page. For pricing and plan details, visit RPC pricing.
Related resources
Originally published at OnFinality.
Top comments (0)