Summary
A public Optimism RPC endpoint lets you read OP Mainnet data and broadcast transactions without running a node. This page gives you the chain settings, a working curl and JavaScript example, and the failure modes you should expect from shared public infrastructure. It also explains when a shared public endpoint stops being the right choice and how to move to a managed or dedicated setup without rewriting your app.
A public Optimism RPC endpoint is the fastest way to start reading OP Mainnet state and sending transactions. You point your wallet or script at an HTTP or WebSocket URL, set the chain ID, and you are on the network. The tradeoff is that public endpoints are shared, so you do not control throughput, rate limits, or how quickly the node is upgraded. This page covers the exact chain settings, a working request example, the errors you will hit, and the point at which a managed or dedicated endpoint becomes the better choice.
Chain settings at a glance
Before you send a single request, get these values right. A wrong chain ID or a mismatched RPC URL is the most common reason a wallet shows the wrong balance or a transaction fails to broadcast.
| Setting | Value |
|---|---|
| Network name | OP Mainnet (Optimism) |
| Chain ID | 10 |
| Currency symbol | ETH |
| Currency decimals | 18 |
| Block explorer | https://optimistic.etherscan.io |
| RPC transports | HTTP and WebSocket |
| Public endpoint | https://optimism.api.onfinality.io/public |
Optimism is an EVM-equivalent Layer 2, so the JSON-RPC surface matches Ethereum closely. That means the same libraries, the same method names, and the same ABI tooling work without changes. What differs is the chain ID, the sequencer behavior, and the fact that you are reading L2 state rather than L1 state.
If you are testing before you touch mainnet, Optimism Sepolia uses chain ID 11155420 and the endpoint https://optimism-sepolia.api.onfinality.io/public. Keep the two configs separate in your codebase so you never broadcast a testnet transaction to mainnet by accident.
Decide how you will connect
There is no single correct answer here. The right choice depends on what your app does and how much control you need over the node behind the endpoint.
Use a public endpoint when you are prototyping, running a script, checking balances, or building something with low, bursty traffic. Public endpoints are free to try and require no account. They are a good fit for local development, hackathon projects, and read-only dashboards.
Move to a managed RPC API when you are shipping to real users. A managed endpoint gives you a stable URL, predictable request handling, and a support path when something breaks. This is the usual next step once your app has production traffic.
Choose a dedicated node when you need consistent throughput, archive data, trace methods, or heavy eth_getLogs queries. Dedicated infrastructure removes the noisy-neighbor problem because the node serves your workload only.
A quick way to decide: if a failed request would page you at 2am, you have outgrown the public endpoint. If a failed request just means you retry in your terminal, the public endpoint is fine.
Connect with curl
You can verify an endpoint is live and returning the expected chain before you wire it into an app. This request asks for the chain ID, which should return 0xa (10 in hex).
curl -X POST https://optimism.api.onfinality.io/public \
-H "Content-Type: application/json" \
--data '{
"jsonrpc": "2.0",
"method": "eth_chainId",
"params": [],
"id": 1
}'
A healthy response looks like this:
{
"jsonrpc": "2.0",
"id": 1,
"result": "0xa"
}
If you get 0xa back, the endpoint is on OP Mainnet. If you get a different value, you are pointed at the wrong network. If you get an error object instead, read the message field before you change anything else.
Connect from JavaScript
Most apps use a library rather than raw HTTP. With ethers, the provider setup is one line once you have the URL.
import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider(
"https://optimism.api.onfinality.io/public",
{ chainId: 10, name: "optimism" }
);
const block = await provider.getBlockNumber();
console.log("Latest OP Mainnet block:", block);
Passing the chain ID explicitly is worth the extra characters. It lets ethers detect a mismatch instead of silently reading from the wrong chain, which is a hard bug to spot later.
For real-time use cases like watching pending transactions or tracking a specific address, use the WebSocket transport instead of polling over HTTP. Optimism supports ws, so you can subscribe to new block headers and react as they arrive rather than asking every few seconds.
Add Optimism to a wallet
If you are configuring a wallet manually, use the values from the chain settings table. In MetaMask, open the network selector, choose Add network, and enter the network name, RPC URL, chain ID, symbol, and explorer. The chain ID is what prevents the wallet from confusing OP Mainnet with Ethereum mainnet or a testnet.
A common mistake is pasting an RPC URL from a blog post that has since gone offline. Always confirm the endpoint responds before you save it, and keep a second URL on hand so you can switch quickly if the first one degrades.
Common failure modes
Public endpoints fail in predictable ways. Knowing the symptom saves you from debugging the wrong layer.
| Symptom | Likely cause | What to do |
|---|---|---|
429 or rate-limit message | Shared endpoint is throttling your request rate | Add backoff, batch requests, or move to a managed endpoint |
| Timeouts under load | Congestion on shared infrastructure | Retry with jitter, then evaluate a dedicated node |
eth_getLogs returns an error | Query range or result size too large | Narrow the block range and paginate |
| Transaction stuck pending | Gas price too low for current conditions | Re-estimate gas and consider a replacement transaction |
| Wrong balances or chain | Chain ID or URL mismatch | Re-check chain ID 10 and the endpoint host |
Rate limiting is the one developers underestimate. A public endpoint is shared by many callers, so your effective throughput depends on what everyone else is doing at that moment. Code that works in testing can slow down during a busy period. Build retry logic with exponential backoff from the start, and batch independent reads where the library supports it.
What to check before you rely on an endpoint
If you are comparing endpoints or providers, test against your actual workload rather than a generic benchmark. A few checks separate a usable endpoint from one that will cause incidents.
- Method coverage. Confirm the endpoint supports the methods you call, including archive queries and trace methods if you need historical state.
- Transport support. If you need subscriptions, verify WebSocket is available, not just HTTP.
- Behavior under load. Send a realistic burst and watch for throttling or rising latency.
- Failover. Have a second endpoint configured so a single outage does not take your app down.
- Observability. Track error rates and latency per endpoint so you notice degradation before users do.
OnFinality provides Optimism RPC through a managed API and dedicated node options. You can review the network details on the Optimism RPC API page, compare costs on RPC pricing, and see the full set of chains on supported RPC networks. If you need consistent throughput or archive access, dedicated nodes let you run infrastructure sized to your workload. For a broader framework, see how to choose an RPC provider.
Migrating from a public endpoint
Moving off a public endpoint should not require rewriting your app. If you have kept the URL in one place, the change is a config update.
- Put the RPC URL in an environment variable rather than hard-coding it.
- Add a second endpoint as a fallback and route requests to it when the first fails.
- Run both endpoints in staging and compare latency and error rates on your real traffic.
- Switch production traffic once the new endpoint matches or beats the old one on your key methods.
- Keep the public endpoint as a last-resort fallback, not your primary path.
This approach also protects you during provider incidents. A single endpoint, public or private, is a single point of failure. Two endpoints with a clear priority order is the minimum for anything user-facing.
Key Takeaways
- OP Mainnet uses chain ID 10, ETH as the native currency, and supports both HTTP and WebSocket RPC.
- A public endpoint is fine for prototyping and low-traffic reads, but it is shared, so throughput is not guaranteed.
- Always set the chain ID explicitly in your provider config to catch network mismatches early.
- Rate limiting and large
eth_getLogsqueries are the two most common sources of errors on public endpoints. - Move to a managed RPC API or a dedicated node when you need predictable throughput, archive data, or a support path.
- Keep your RPC URL in configuration and add a fallback endpoint before you go to production.
Frequently Asked Questions
What is the Optimism public RPC endpoint?
OnFinality exposes a public OP Mainnet endpoint at https://optimism.api.onfinality.io/public. It supports HTTP and WebSocket and is suitable for development and light production use. For heavier workloads, a managed or dedicated endpoint is a better fit.
What is the Optimism chain ID?
OP Mainnet uses chain ID 10. Optimism Sepolia, the testnet, uses chain ID 11155420. Always confirm the chain ID matches the network you intend to use.
Is a public RPC endpoint safe for production?
It can work for low-traffic apps, but public endpoints are shared and may throttle requests during busy periods. For user-facing apps, a managed endpoint with a fallback is the safer default.
Why does my Optimism request return a rate-limit error?
You are likely sending requests faster than the shared endpoint allows. Add exponential backoff, batch independent reads, or move to a managed endpoint with higher limits.
Does Optimism support WebSocket RPC?
Yes. OP Mainnet supports both HTTP and WebSocket transports, so you can subscribe to new blocks and events instead of polling.
When should I use a dedicated Optimism node?
When you need consistent throughput, archive data, trace methods, or heavy log queries, a dedicated node removes the noisy-neighbor effect and gives you infrastructure sized to your workload.