Ethereum RPC Acceptance Test: Check a Sepolia Endpoint

Check the endpoint before routing application traffic

A successful HTTP request does not tell you which chain the node serves, whether its head is fresh or whether you can repeat a block read. Use these checks as a first acceptance gate for a candidate endpoint, before comparing costs, methods or support. This is an endpoint test, not transaction simulation, wallet setup or a provider ranking.

Start with the offline fixture. It models the shape of five calls but does not contact a node. FluidRWA tested the fixture and mocked HTTP path; the optional live Sepolia path is not a reported provider test. You need Node.js 22 or later, but no wallet, signing key, token or test ETH.

Step 1: Run the offline fixture

Inspect the downloaded module before running it. With no argument the program defaults to offline. Expect AUTHORED OFFLINE FIXTURE, head 0x100, ageSeconds 12 and finalized 0xf0. The hashes are synthetic. Capture the result separately from any real endpoint observation.

If the report does not match, confirm that you downloaded the current file and that the command used --offline. A fixture pass confirms the expected branch of the program, not the freshness, latency or availability of any RPC service.

node --check rpc-acceptance-lab.mjs
node rpc-acceptance-lab.mjs --offline

• Download the RPC acceptance lab (.mjs)

Step 2: Read the acceptance checks

The lab asks for eth_chainId, reads latest and finalized using eth_getBlockByNumber, re-reads the observed head by its exact number, then asks for the chain ID again. The false argument requests transaction hashes rather than full transaction objects. No transaction is submitted.

The freshness window is a lab policy, not an Ethereum guarantee. A timestamp up to 30 seconds ahead accommodates limited clock skew; a head more than 300 seconds old fails this exercise. Check your machine clock before diagnosing stale data. The script validates a finalized block number and hash, but does not prove finality or block ancestry.

Step 3: Optionally run against your own Sepolia endpoint

Use only an HTTPS Sepolia endpoint you are authorized to test. The URL may contain a credential, so do not paste it into your shell command, report or support ticket. The zsh example reads it without echo. The script refuses redirects, uses per-request timeouts and only allows the two read methods above.

Check whether your provider meters requests before running the optional step. Save the provider label, time, mode and block observations, but omit the endpoint URL and account details. Do not use a production endpoint or replace Sepolia with mainnet to work around a chain failure.

read -s 'SEPOLIA_RPC_URL?Authorized Sepolia HTTPS RPC URL: '
printf '\n'
export SEPOLIA_RPC_URL
node rpc-acceptance-lab.mjs --live
unset SEPOLIA_RPC_URL

Step 4: Record the outcome before retrying

Give the run one of three dispositions: matched, failed or not run. Record failed runs separately from fresh attempts so a successful retry does not erase evidence of intermittent failures. A pass supports moving on to workload-specific checks; a fail means the endpoint did not meet this gate at the observed time.

If several consumers share the endpoint, record who owns follow-up and which checks block rollout. Keep a link to sanitized evidence rather than pasting a credential-bearing request URL.

Troubleshooting: separate incompatibility from inconsistency

Wrong chain: check the endpoint configuration rather than removing the chain guard. A rejected finalized tag is a compatibility gap for this workload; do not silently substitute latest. If finalization advances past the previously sampled head between calls, the lab stops and you can rerun from a fresh sample.

A repeated block mismatch may be a reorganization or inconsistent backends. A timeout, malformed response or HTTP rejection does not establish which component failed. The script omits the endpoint and remote error details. Use your provider's own request logs for diagnosis and redact any credentials before sharing evidence.

Step 5: Decide what still needs testing

Keep offline, mock and live observations in separate rows. For a real shortlist, compare hashes at a common height with a separately operated endpoint and investigate disagreement. One endpoint's internally consistent answers are not independent evidence of chain truth.

Before production, define the additional method, archive depth, quota, failover and observation-window checks your application requires. A single five-request run cannot measure tail latency, incident recovery or service uptime.

• Compare Alchemy, QuickNode and Chainstack
• Inspect a token transfer before signing