Sepolia Ethereum RPC: Endpoint Settings, Faucets, and Debugging

Sepolia is the testnet most Ethereum developers reach for first. It behaves like mainnet at the JSON-RPC layer, so contracts, wallets, and indexers that work on Ethereum mainnet usually work on Sepolia with only a chain ID and endpoint change. The friction is rarely the protocol itself — it is picking a working endpoint, funding an account, and diagnosing why a request fails.

This page is a working reference: the exact chain settings, a decision guide for choosing an endpoint type, request examples you can paste into a terminal, and a debugging path for the errors you are most likely to hit.

Which Sepolia endpoint should you use?

There are three practical options, and the right one depends on what you are doing rather than on raw preference.

• Local or one-off testing. A public endpoint is usually fine. You are sending a handful of requests, you do not care about rate limits, and you can switch endpoints if one is slow.
• Team development and staging. A managed RPC API gives you an API key, consistent configuration across machines, and a support path when something breaks. This is the common choice for apps that will eventually ship to mainnet.
• CI pipelines, indexers, and load tests. These generate sustained request volume and often need archive data or wide log queries. A dedicated node removes noisy-neighbour effects and lets you size capacity to your workload.

OnFinality provides Sepolia through its RPC API service and through dedicated nodes when you need isolated capacity. You can see the network entry on the Sepolia RPC page.

If you are still deciding between public, managed, and dedicated infrastructure in general, the RPC provider selection guide covers the evaluation criteria in more depth.

Sepolia chain settings at a glance

Use these values when adding Sepolia to a wallet, a framework config, or a deployment script. They match the network definition used across Ethereum tooling.

A public OnFinality Sepolia endpoint is available for light testing:

https://eth-sepolia.api.onfinality.io/public

Public endpoints are shared and intended for development and evaluation. For production-like workloads, use an API key or a dedicated node so your traffic is not competing with other users.

Connecting from a wallet

Most wallet connection problems on Sepolia come from a mismatched chain ID or a stale endpoint. When adding the network manually, enter the chain ID exactly as 11155111 — not as a decimal string with separators, and not as the mainnet chain ID 1.

If you are using a browser wallet that supports programmatic network switching, you can request the chain directly:

// Request Sepolia from an injected wallet
await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0xaa36a7", // 11155111 in hex
    chainName: "Ethereum Sepolia",
    nativeCurrency: { name: "Sepolia Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://eth-sepolia.api.onfinality.io/public"],
    blockExplorerUrls: ["https://sepolia.etherscan.io"]
  }]
});

Note that chainId in the wallet request is hex-encoded. JSON-RPC calls, by contrast, return the chain ID as a hex string too, so eth_chainId on Sepolia returns 0xaa36a7. If your application compares that value to the decimal 11155111, the check will fail — parse it before comparing.

Getting test ETH from a faucet

Sepolia ETH has no market value, but you still need it to deploy contracts and send transactions. Faucets typically require one of the following:

• A verified account on a faucet provider.
• A small mainnet balance, used as an anti-abuse signal.
• A proof-of-work or social login step.

Practical notes that save time:

1. Fund the address you will actually deploy from. It is easy to request ETH to a fresh address and then deploy from a different one.
2. Expect cooldowns. Most faucets limit how often the same address or IP can request funds.
3. Do not bridge mainnet ETH to Sepolia. There is no supported bridge path for that; use a faucet.
4. Keep a small buffer. Contract deployment plus a few test transactions is usually enough, but complex deployments with large bytecode cost more gas.

If a faucet transaction is pending for a long time, check the explorer before requesting again — duplicate requests to the same address rarely help and can trigger rate limits.

Making your first JSON-RPC calls

Before wiring Sepolia into an application, confirm the endpoint responds and reports the expected chain. A single curl call answers both questions.

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 healthy response looks like this:

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

If you see 0x1 instead, you are talking to Ethereum mainnet, not Sepolia. If you see an error object, the endpoint is reachable but rejecting the request — check the error code before changing anything else.

Two more calls are worth running during setup:

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

# Balance of an address, in wei (hex)
curl -s https://eth-sepolia.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0xYourAddress","latest"]}'

eth_blockNumber confirms the node is synced and following the chain. eth_getBalance confirms your funded account is visible to the endpoint you plan to use.

Using Sepolia from JavaScript

With viem, Sepolia is a built-in chain, so you only need to supply a transport:

import { createPublicClient, http, formatEther } from "viem";
import { sepolia } from "viem/chains";

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

const block = await client.getBlockNumber();
const balance = await client.getBalance({ address: "0xYourAddress" });

console.log("Sepolia block:", block);
console.log("Balance:", formatEther(balance), "ETH");

With ethers, the pattern is similar — pass the Sepolia network and a provider URL:

import { JsonRpcProvider, formatEther } from "ethers";

const provider = new JsonRpcProvider(
  "https://eth-sepolia.api.onfinality.io/public",
  11155111
);

console.log(await provider.getBlockNumber());
console.log(formatEther(await provider.getBalance("0xYourAddress")));

Both examples use HTTP. If your application relies on eth_subscribe for new blocks or pending logs, you need a WebSocket transport instead, and your provider must expose it. Check transport support before designing around subscriptions.

Debugging common Sepolia failures

The table below maps the symptom you are most likely to see to the usual cause and the first thing to check.

A few of these deserve more detail.

Nonce confusion on testnets. Because you may be sending transactions from scripts, wallets, and the explorer at the same time, nonces can drift. When a transaction appears stuck, query the pending nonce rather than the latest one, and avoid firing a replacement with a guessed value.

Log queries that return nothing. eth_getLogs is sensitive to block range. On a busy testnet, a range that is too wide may be rejected, while a range that is too narrow returns nothing. Start with a modest range around the block where you deployed, then expand.

Rate limits during CI. If your pipeline runs many parallel jobs against a public endpoint, failures will look random. That is usually contention, not a bug in your code. An API key or dedicated node gives you a stable budget.

When to move off a public endpoint

Public endpoints are convenient and appropriate for early development. They become a liability when:

• Your CI pipeline runs on every commit and generates bursty traffic.
• An indexer or backend service polls continuously.
• You need archive state for historical queries.
• You depend on WebSocket subscriptions for real-time updates.
• You need a support channel when something breaks before a release.

At that point, compare providers on the criteria that actually affect your workload: method coverage, archive availability, transport support, how limits are enforced, and how failover works. RPC pricing and the list of supported RPC networks are good starting points, and the provider selection guide walks through the evaluation in detail.

Key Takeaways

• Sepolia uses chain ID 11155111, which is 0xaa36a7 in JSON-RPC responses.
• Always verify eth_chainId before debugging anything else — pointing at mainnet is a common mistake.
• Faucets fund test accounts; there is no supported path to bridge mainnet ETH to Sepolia.
• Public endpoints suit light development; CI, indexers, and subscription-based apps benefit from managed or dedicated capacity.
• Most Sepolia errors fall into a small set: wrong chain, no funds, nonce drift, rate limits, or unsupported methods.

Frequently Asked Questions

What is the Sepolia RPC URL?

There is no single canonical URL — Sepolia is a network, and multiple providers expose endpoints for it. For light testing you can use the public OnFinality endpoint https://eth-sepolia.api.onfinality.io/public. For production-like workloads, use an API-key endpoint or a dedicated node.

What is the Sepolia chain ID?

Sepolia's chain ID is 11155111. JSON-RPC returns it as the hex string 0xaa36a7.

Is Sepolia the same as Ethereum mainnet?

No. Sepolia is a separate testnet with its own state and its own ETH that has no monetary value. It runs the same EVM and JSON-RPC interface, which is why mainnet tooling usually works with only a configuration change.

Why does my Sepolia transaction say insufficient funds?

Your account does not have enough Sepolia ETH to cover the transaction value plus gas. Request test ETH from a faucet, then confirm the balance on the block explorer before retrying.

Can I use WebSocket subscriptions on Sepolia?

Only if your provider exposes a WebSocket transport. HTTP endpoints do not support eth_subscribe. Check transport support for your chosen endpoint before building around real-time subscriptions.

Do I need an archive node for Sepolia?

Only if you query historical state at old block heights. Recent-state queries work on a standard node. If your application needs historical balances or traces, confirm archive availability with your provider.