PublicNode Sepolia: What It Is and When to Use a Different Endpoint

PublicNode Sepolia is a free, shared JSON-RPC endpoint for the Ethereum Sepolia testnet. Developers usually find it while setting up a wallet, wiring a Hardhat or Foundry script, or looking for a Sepolia RPC URL they can paste into a config file without signing up for anything. It works for that. The question worth answering before you commit is whether a shared public endpoint is the right long-term choice for your test workflow.

This page covers what the endpoint is, how to connect to it, the chain settings you need, and the point at which a shared public endpoint starts costing you more time than it saves. If you already know you want a managed or dedicated Sepolia endpoint, you can skip ahead to Sepolia RPC on OnFinality or compare plans on RPC pricing.

Is PublicNode Sepolia the right endpoint for your workload?

Use this as a quick triage before you build anything on top of a public endpoint.

The pattern is simple: shared public endpoints are fine when a human is waiting for a single response. They get uncomfortable when a machine is sending many requests on a schedule you do not control.

What PublicNode Sepolia actually is

PublicNode is a set of free, community-facing RPC endpoints for a range of EVM chains, including Ethereum mainnet and Sepolia. The Sepolia endpoint speaks standard Ethereum JSON-RPC over HTTP, so any client that supports an HTTP RPC URL can talk to it: ethers, viem, web3.js, Hardhat, Foundry, MetaMask, and so on.

A few properties matter for planning:

• It is shared. You are one of many callers hitting the same infrastructure.
• It is unauthenticated. There is no API key, which is convenient for a quick test and awkward for anything you need to attribute or rate-manage.
• It is best-effort. There is no support contract, no SLA, and no channel to escalate a problem.
• It is HTTP-oriented. If your workflow depends on WebSocket subscriptions or heavy eth_getLogs queries, verify support before you rely on it.

None of that makes it bad. It makes it a specific tool for a specific job.

Sepolia chain settings at a glance

If you are configuring a wallet or a framework, these are the values you need for Ethereum Sepolia. They are the same regardless of which Sepolia RPC provider you point at.

The chain ID is the field people get wrong most often. Sepolia is 11155111, not 1 (Ethereum mainnet) and not 5 (the deprecated Goerli testnet). If a wallet or script behaves oddly, check the chain ID first.

Connecting with curl, ethers, and a wallet

Start with the simplest possible check. A raw JSON-RPC call tells you whether the endpoint is reachable and what chain it is serving.

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

The response should be a hex chain ID. For Sepolia that is 0xaa36a7, which is 11155111 in decimal. If you get a different value, you are pointed at the wrong network.

In JavaScript with viem, the same check looks like this:

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);

For a wallet, add a custom network with the chain settings above and paste your Sepolia RPC URL into the RPC field. MetaMask and most EVM wallets accept the same five fields.

If you want a Sepolia endpoint you can point at without managing your own node, OnFinality exposes a public Sepolia RPC at https://eth-sepolia.api.onfinality.io/public. It is a reasonable default for development and testing. For anything heavier, see Sepolia RPC on OnFinality.

Where shared public endpoints start to hurt

Public endpoints rarely fail loudly. They degrade in ways that look like bugs in your own code. The symptoms below are the ones developers most often misattribute.

The CI case is the one that surprises teams most. A test suite that runs fine on one developer's laptop can generate hundreds of calls per minute once it runs on every pull request. That is exactly the workload a shared public endpoint is not sized for.

What to look for in a Sepolia endpoint you depend on

If Sepolia is part of your release process rather than a one-off experiment, evaluate endpoints on the same criteria you would use for mainnet.

• Transport support. HTTP is the baseline. WebSocket matters if you subscribe to events. Check whether the provider supports both.
• Archive and historical data. If you replay past state or backfill logs, you need archive access, not just the latest block.
• Rate and concurrency limits. Know the request-per-second and burst limits before you design around them.
• Key management. A keyed endpoint lets you separate environments, rotate credentials, and see usage per project.
• Observability. Request metrics and error breakdowns turn "it feels slow" into a specific number.
• Failover. A single endpoint is a single point of failure. Know what happens when it is unavailable.
• Support path. On a testnet this matters less, but it still matters when a release is blocked.

OnFinality provides managed RPC API access and dedicated node infrastructure across a range of networks, including Sepolia. You can review the full list on supported RPC networks and compare tiers on RPC pricing. If you need isolated capacity rather than shared access, dedicated nodes are the relevant option.

Migrating from a public endpoint without breaking your setup

Moving off a public endpoint is usually a config change, not a rewrite. Treat it as a small, reversible migration.

1. Centralize the RPC URL. Replace hardcoded URLs with a single environment variable such as SEPOLIA_RPC_URL. This is the step that makes everything else easy.
2. Add a fallback. Configure a primary and a secondary endpoint so a single provider outage does not stop your pipeline.
3. Verify the chain ID. After switching, confirm eth_chainId still returns 0xaa36a7.
4. Re-run your test suite. Compare pass rates and timings before and after the switch.
5. Watch error rates for a few days. Rate-limit and timeout errors should drop; if they do not, the problem may be in your client code.

// config.js
const RPC_URLS = [
  process.env.SEPOLIA_RPC_URL,
  process.env.SEPOLIA_RPC_URL_FALLBACK,
].filter(Boolean);

export function getSepoliaTransport() {
  return http(RPC_URLS[0], {
    retryCount: 2,
    onFetchResponse: async (response) => {
      if (!response.ok && RPC_URLS[1]) {
        console.warn("Primary Sepolia RPC failed, consider fallback");
      }
    },
  });
}

Keeping the endpoint in configuration rather than in code is the single highest-value change. It lets you swap providers, add a fallback, and run different endpoints per environment without touching application logic.

Debugging checklist for Sepolia RPC problems

When something breaks, work through these in order. Most Sepolia issues are one of these six.

• Wrong chain ID. Confirm 0xaa36a7. A mainnet endpoint will happily answer your calls and return mainnet data.
• No test ETH. A transaction that fails on gas usually means an empty balance. Use a Sepolia faucet to top up.
• Stale nonce. If you sent a transaction that never confirmed, the nonce is still consumed. Check pending transactions before resending.
• Log query too wide. eth_getLogs over a large block range is the most common source of errors on shared endpoints. Narrow the range.
• Rate limiting. 429 responses mean you are sending more than the endpoint allows. Add backoff and reduce concurrency.
• Endpoint lag. Compare eth_blockNumber with a block explorer. If the endpoint is behind, switch or wait.

A quick probe script is worth keeping around:

#!/usr/bin/env bash
RPC="${SEPOLIA_RPC_URL:-https://eth-sepolia.api.onfinality.io/public}"
echo "chainId: $(curl -s $RPC -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}')"
echo "blockNumber: $(curl -s $RPC -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')"

Run it against each endpoint you are considering. It takes seconds and tells you whether the endpoint is alive and on the right chain.

Key Takeaways

• PublicNode Sepolia is a free, shared JSON-RPC endpoint for the Ethereum Sepolia testnet, suited to manual testing and light scripts.
• Sepolia chain ID is 11155111 (0xaa36a7); getting this wrong is the most common configuration mistake.
• Shared public endpoints degrade under CI, load testing, and wide log queries rather than failing cleanly.
• Keep your RPC URL in configuration, not in code, so you can add fallbacks and swap providers.
• For workloads that need consistent throughput, archive data, WebSocket support, or observability, use a managed or dedicated Sepolia endpoint such as Sepolia RPC on OnFinality.

FAQ

Is PublicNode Sepolia free? Yes, it is a free public endpoint. Free access usually comes with shared capacity and best-effort availability rather than a support commitment.

What is the Sepolia chain ID? 11155111, which is 0xaa36a7 in hex. Use it in wallets and framework configs.

Can I use PublicNode Sepolia in CI? You can, but CI generates far more requests than interactive use. If your pipeline runs on every commit, a keyed managed endpoint is usually more reliable.

Does PublicNode Sepolia support WebSocket? Support varies and can change. If your application depends on subscriptions, verify WebSocket availability before you build on it, or use a provider that documents WS support.

How do I get Sepolia ETH? Use a Sepolia faucet. Faucets have their own eligibility rules and rate limits, so check the current requirements before requesting.

When should I switch to a managed Sepolia RPC? When Sepolia is part of a repeatable workflow: CI, automated testing, indexing, or anything with more than one developer depending on it. At that point, rate limits, observability, and failover start to matter more than free access.

Next steps

If you are still experimenting, a public Sepolia endpoint is a fine place to start. If Sepolia is now part of how your team ships, review Sepolia RPC on OnFinality, check RPC pricing, and browse supported RPC networks if you also need mainnet or other testnets. For a broader framework on evaluating providers, read how to choose an RPC provider.