Summary
Base RPC is the JSON-RPC interface to the Base L2 network, used to read state, send transactions, and subscribe to events. This page covers the public endpoint, chain settings, and how to evaluate marketplace-style RPC listings for production workloads. You will also find a practical checklist for choosing between shared public endpoints and dedicated node infrastructure, plus debugging steps for common Base RPC failures.
If you are looking for a Base RPC endpoint, the fastest path is to connect to a public URL, confirm the chain ID, and send a test request. This page gives you the exact settings, a working example, and a practical way to decide whether a shared public endpoint is enough or whether you need dedicated node infrastructure for your workload.
Quick start: connect to Base in under a minute
Base is an Ethereum L2 built on the OP Stack. It uses the standard Ethereum JSON-RPC interface, so any Ethereum-compatible tooling works once you point it at a Base endpoint.
| Setting | Value |
|---|---|
| Network name | Base |
| Chain ID | 8453 |
| Native currency | ETH (18 decimals) |
| Block explorer | https://basescan.org |
| Public RPC (OnFinality) | https://base.api.onfinality.io/public |
| Transport | HTTP |
Add Base to a wallet or client with these values:
{
"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 decimal 8453. Wallets expect the hex value; most JavaScript libraries accept the decimal chain ID.
When a public endpoint is enough — and when it is not
A public Base RPC endpoint is fine for development, scripts, dashboards, and low-volume reads. It is not designed for high request rates, large log queries, or workloads that need consistent throughput under load.
Use this table to decide what fits your situation.
| Your workload | Public endpoint | Dedicated node |
|---|---|---|
| Local development and testing | Good fit | Overkill |
| Low-traffic dApp reads | Usually fine | Optional |
High-frequency eth_getLogs or indexing | Likely to hit limits | Recommended |
| Trading bots or latency-sensitive calls | Not suitable | Recommended |
| Archive or historical state queries | Not guaranteed | Recommended |
| Production apps with SLAs | Not suitable | Recommended |
If you are unsure, start on the public endpoint, measure your request volume and error rate, and move to a dedicated node when you see throttling, timeouts, or inconsistent responses. OnFinality offers both shared RPC API and dedicated nodes for Base and other networks.
Base RPC methods you will actually use
Base supports the standard Ethereum JSON-RPC method set. The methods below cover most application needs.
| Method | What it does | Typical use |
|---|---|---|
eth_chainId | Returns the chain ID | Verify you are on Base |
eth_blockNumber | Latest block number | Health checks, sync status |
eth_getBalance | Account balance | Wallets, dashboards |
eth_call | Read-only contract call | Token metadata, contract state |
eth_getLogs | Query event logs | Indexers, analytics |
eth_sendRawTransaction | Broadcast a signed transaction | Sending transactions |
eth_getTransactionReceipt | Transaction status | Confirmation tracking |
eth_estimateGas | Gas estimation | Transaction building |
If you need trace or debug methods (debug_traceTransaction, trace_block), check provider support first. These are not always available on shared endpoints and may require a dedicated node with the right client configuration.
Sending your first request
A simple curl call confirms connectivity and chain identity:
curl -X POST https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "eth_chainId",
"params": [],
"id": 1
}'
A correct response returns "result":"0x2105". If you get a different chain ID, you are pointed at the wrong network. If you get an error, check the URL and your request body.
In JavaScript with viem:
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('Latest Base block:', blockNumber);
For WebSocket subscriptions (new heads, logs), confirm that your provider exposes a wss:// endpoint. The OnFinality public Base endpoint is HTTP; WebSocket access is available on dedicated and managed plans. See RPC pricing for details.
How to evaluate a Base RPC marketplace listing
Marketplace-style RPC listings aggregate many providers under one interface. That can be convenient, but it hides important details. Before you commit, check the following.
| What to verify | Why it matters |
|---|---|
| Chain ID and network | Prevents sending transactions to the wrong chain |
| Transport support (HTTP, WebSocket) | Determines whether subscriptions work |
| Archive data availability | Needed for historical state queries |
| Trace/debug method support | Required for some debugging and analytics tools |
| Rate limits and burst behavior | Affects reliability under load |
| Failover and redundancy | Reduces downtime risk |
| Pricing model | Shared vs dedicated changes cost structure |
| Support and SLA terms | Matters for production incidents |
A marketplace listing is a starting point, not a guarantee. If your application depends on Base RPC availability, test the endpoint under realistic load before you rely on it.
Base Sepolia for testing
Use Base Sepolia to test contracts and transactions before mainnet. The settings are similar but the chain ID and endpoint differ.
| Setting | Value |
|---|---|
| Network name | Base Sepolia |
| Chain ID | 84532 |
| Native currency | Sepolia Ether (ETH, 18 decimals) |
| Block explorer | https://sepolia.basescan.org |
| Public RPC (OnFinality) | https://base-sepolia.api.onfinality.io/public |
You can get testnet ETH from a Base Sepolia faucet to pay for test transactions. See the Base Sepolia network page for details.
Common Base RPC errors and how to fix them
Most Base RPC issues fall into a few categories. This table maps symptoms to likely causes.
| Symptom | Likely cause | Fix |
|---|---|---|
429 Too Many Requests | Rate limit hit | Reduce request rate, batch calls, or move to a dedicated plan |
-32000 or timeout errors | Endpoint overloaded or request too heavy | Retry with backoff, narrow eth_getLogs block range |
| Wrong chain ID in response | Endpoint points to a different network | Verify the URL and chain ID |
eth_getLogs returns empty | Block range too wide or filter mismatch | Reduce range, check topic filters |
| Transaction not found | Node not synced or wrong network | Check eth_blockNumber and chain ID |
| WebSocket disconnects | Connection limits or idle timeout | Add reconnect logic, use heartbeat |
For eth_getLogs, a common mistake is querying a very large block range in one call. Break the range into smaller chunks and paginate. This reduces load on the node and avoids timeouts.
Production readiness checklist
Before you move a Base application to production, confirm the following.
- Chain ID and endpoint verified with
eth_chainId - Failover endpoint configured in your client
- Retry logic with exponential backoff implemented
- Request batching or caching for high-volume reads
-
eth_getLogsqueries paginated by block range - WebSocket reconnect logic if using subscriptions
- Monitoring for error rates and latency
- Archive or trace requirements confirmed with your provider
If any of these are missing, address them before launch. Most production incidents on Base RPC come from rate limits, missing failover, or unpaginated log queries.
Shared RPC vs dedicated nodes for Base
Shared RPC is the right default for most teams. It is fast to set up, requires no infrastructure management, and scales with your request volume up to the plan limits.
Dedicated nodes make sense when you need:
- Consistent throughput under heavy load
- Archive data or trace methods
- WebSocket subscriptions at scale
- Isolation from other tenants
- Custom client configuration
OnFinality provides both options for Base. You can start on the shared RPC API and move to a dedicated node when your workload demands it. Review RPC pricing to compare plans, and see the full list of supported RPC networks if you operate across multiple chains.
Key Takeaways
- Base uses chain ID 8453 and the standard Ethereum JSON-RPC interface.
- The OnFinality public Base endpoint is
https://base.api.onfinality.io/public(HTTP). - Base Sepolia uses chain ID 84532 for testing.
- Public endpoints suit development and low-volume reads; dedicated nodes suit high-throughput, archive, trace, and WebSocket workloads.
- Always verify chain ID, configure failover, and paginate
eth_getLogsbefore going to production. - Marketplace listings are a starting point — verify transport, archive, trace, limits, and support terms yourself.
Frequently Asked Questions
What is the Base RPC endpoint?
The OnFinality public Base RPC endpoint is https://base.api.onfinality.io/public. It supports HTTP JSON-RPC. For WebSocket or archive access, use a dedicated or managed plan.
What is Base's chain ID?
Base mainnet uses chain ID 8453 (hex 0x2105). Base Sepolia uses 84532.
Is the Base public RPC free to use? Public endpoints are suitable for development and low-volume use. For production workloads with higher request rates, review RPC pricing and consider a dedicated plan.
Does Base RPC support WebSocket? WebSocket support depends on the provider and plan. The OnFinality public Base endpoint is HTTP; WebSocket access is available on dedicated and managed plans.
Can I use Base RPC for eth_getLogs at scale?
Yes, but paginate your block ranges and confirm your provider's limits. Large unpaginated queries are a common cause of timeouts.
How do I test on Base without spending real ETH? Use Base Sepolia (chain ID 84532) and get testnet ETH from a faucet. See the Base Sepolia network page.