Sepolia RPC Endpoint: Public URLs, Chain Settings, and When to Move Off Them

Sepolia is Ethereum's long-running proof-of-stake testnet, and "public RPC endpoint" is the phrase most developers search for when they want to connect to it without signing up for anything. That is a reasonable starting point: a public endpoint is a shared HTTPS URL that speaks JSON-RPC, and it is enough to add the network to a wallet, run a quick script, or unblock a CI job.

The catch is that public endpoints are shared by everyone who finds them. They are fine for exploration and light testing, and they become a bottleneck the moment you need consistent throughput, archive data, or trace calls. This page gives you the exact Sepolia chain settings, a working public endpoint, and a short framework for deciding when to move to managed or dedicated infrastructure.

Chain settings at a glance

Before you paste anything into a wallet or a config file, get these values right. Most "Sepolia RPC not working" reports come down to a mismatched chain ID or a URL that points at a different testnet.

If you are working on an L2 testnet instead, the values differ. Base Sepolia uses chain ID 84532, and Arbitrum Sepolia uses chain ID 421614. Mixing those up is a common source of failed transactions that look like RPC problems but are really wrong-network problems.

Is a public endpoint enough for your workload?

Use this as a quick triage before you invest time in configuration. The question is not whether a public endpoint works, but whether it works for what you are about to do with it.

A useful rule: if more than one process depends on the same endpoint at the same time, or if a failed request breaks a user-visible flow, you have outgrown the public tier. OnFinality runs shared and dedicated Sepolia infrastructure, and you can compare options on the Sepolia network page and RPC pricing.

Connecting with curl and JSON-RPC

The fastest sanity check is a raw JSON-RPC call. This confirms the endpoint is reachable and returning the chain you expect.

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

A correct response returns the chain ID in hex:

{"jsonrpc":"2.0","id":1,"result":"0xaa36a7"}

0xaa36a7 is 11155111 in decimal, which is Ethereum Sepolia. If you get a different value, you are pointed at the wrong network. If you get a timeout or a 429, the endpoint is reachable but rate limited, which is the signal to look at a managed plan.

Two more calls are worth keeping in your toolkit. eth_blockNumber tells you whether the node is synced and following the chain head. eth_getBalance with a known address confirms that state reads are working end to end.

Wallet and library configuration

In a browser wallet such as MetaMask, add a network manually and enter the chain settings from the table above. The RPC URL field takes the public endpoint, and the chain ID must be the decimal value 11155111. Wallets that ask for a hex chain ID want 0xaa36a7.

In JavaScript, the same settings apply. With viem:

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

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

const blockNumber = await client.getBlockNumber()
console.log('Sepolia head:', blockNumber)

With ethers v6:

import { JsonRpcProvider } from 'ethers'

const provider = new JsonRpcProvider(
  'https://eth-sepolia.api.onfinality.io/public',
  { chainId: 11155111, name: 'sepolia' }
)

console.log(await provider.getBlockNumber())

Passing the chain ID explicitly is worth the extra line. It makes wrong-network errors fail loudly instead of silently sending a transaction to the wrong chain.

Getting test ETH from a faucet

Sepolia ETH has no market value, but you still need it to pay gas. Faucets are separate from RPC endpoints, and most of them gate access behind a login, a mainnet balance check, or a proof-of-work challenge to limit abuse.

A few practical notes:

• Faucet drips are small and rate limited per address. Do not expect to fund a large test suite from one request.
• If a faucet rejects your address, it is usually because the address already holds a balance above the faucet threshold.
• Faucet availability changes over time. If one is down, try another rather than assuming your RPC endpoint is broken.
• Keep a small reserve address for gas so you do not have to re-request funds mid-test.

Common failure modes and how to read them

Most Sepolia RPC problems fall into a small number of categories. The error text usually tells you which one you are in.

If you are debugging a specific transaction, eth_getTransactionReceipt returning null usually means the transaction is still pending or was never broadcast, not that the endpoint is broken. Check the mempool status before assuming an infrastructure problem.

Where public endpoints stop being enough

Public endpoints are a shared resource, and shared resources have shared failure modes. Three patterns show up repeatedly in testnet work:

Parallel CI. Contract deployment jobs that run on every pull request can fire dozens of transactions in the same second. On a shared endpoint, some of those requests will be throttled, and the job fails intermittently in a way that is hard to reproduce locally.

Log-heavy indexing. eth_getLogs over a wide block range is expensive. Public endpoints typically cap the range or reject the query outright. If your test setup mirrors a production indexer, you need archive access and a higher range limit.

Trace and debug calls. debug_traceTransaction and trace_* methods are not enabled on most public endpoints because they are computationally heavy. If your tests depend on them, you need a node configured for it.

When you hit any of these, the fix is not a better public URL. It is a managed endpoint with a defined capacity, or a dedicated node you control. OnFinality offers both, and the how to choose an RPC provider article walks through the evaluation criteria in more detail.

Moving from a public endpoint to managed or dedicated

The migration itself is usually a config change, not a rewrite. The work is in choosing the right tier and setting up fallbacks.

1. Inventory your methods. List every JSON-RPC method your app calls. Flag eth_getLogs, debug_*, and trace_* calls, since these drive the node type you need.
2. Measure your peak, not your average. Testnet traffic is bursty. Size for the busiest minute you expect, not the daily mean.
3. Decide shared versus dedicated. Shared managed endpoints suit most dApps. Dedicated nodes make sense when you need isolated capacity, custom configuration, or predictable performance under load. See dedicated nodes for what that involves.
4. Add a fallback. Even with a managed endpoint, configure a second URL so a single provider issue does not take down your test environment.
5. Keep the public endpoint for smoke tests. There is no reason to remove it. Use it for quick checks and keep the managed endpoint for anything that matters.

If you also test on L2s, the same pattern applies to Base Sepolia, which uses chain ID 84532 and a different public URL. Keeping testnet configs in one place, with chain IDs and endpoints side by side, prevents most cross-network mistakes.

Key Takeaways

• Ethereum Sepolia uses chain ID 11155111, symbol ETH, and explorer sepolia.etherscan.io.
• A public Sepolia RPC endpoint is fine for wallets, one-off scripts, and manual testing.
• Public endpoints are shared and rate limited, so parallel CI, log indexing, and trace calls will hit limits.
• Always pass the chain ID explicitly in your client so wrong-network errors fail loudly.
• Faucets are separate from RPC endpoints and are rate limited per address.
• When you outgrow the public tier, move to a managed or dedicated endpoint and keep a fallback configured.
• Browse supported RPC networks and compare RPC pricing before committing to a plan.

Frequently Asked Questions

What is the public RPC endpoint for Sepolia?

OnFinality publishes a public endpoint at https://eth-sepolia.api.onfinality.io/public. It speaks standard JSON-RPC over HTTPS and requires no API key. It is shared, so treat it as suitable for development and light testing rather than production-scale traffic.

What is the Sepolia chain ID?

Ethereum Sepolia uses chain ID 11155111, which is 0xaa36a7 in hex. Base Sepolia uses 84532 and Arbitrum Sepolia uses 421614. Always confirm the chain ID matches the network you intend to use.

Does the public endpoint support WebSocket subscriptions?

Transport support varies by network and endpoint. If your app relies on eth_subscribe for new heads or logs, check the network page for the transports available, or use a managed or dedicated endpoint where WebSocket support is part of the plan.

Why do I get 429 errors on a public Sepolia endpoint?

A 429 means you have exceeded the shared rate limit. Reduce your request rate, batch calls where possible, and consider a managed plan if the limit is consistently in your way. It is a capacity signal, not a bug in your code.

Can I use a public Sepolia endpoint for CI pipelines?

For low-volume, sequential jobs it can work. For parallel jobs that deploy contracts on every push, shared rate limits will cause intermittent failures. A managed endpoint with defined capacity is the more reliable choice.

Do I need an archive node for Sepolia testing?

Only if you query historical state or wide log ranges. Most test workflows do not need archive access, but indexer-style tests and backfill scripts do. Check the method requirements before assuming a standard node is enough.