RPC Gateway

One Ethereum JSON-RPC endpoint in front of several public providers. The gateway at rpc.pigfox.com is a small service written in Go. It runs no node of its own: it forwards each read-only request to one of several public Ethereum Sepolia RPC providers, watches how each of them is doing, and moves a request to the next provider when one fails. This page talks to it directly from your browser. Everything below about the gateway is read from the gateway itself.

Sepolia is a test network: its ether has no value. The gateway forwards reads only. Nothing on this page signs or sends a transaction, and nothing here costs money.

The providers, live

Connecting to the gateway…

From the gateway’s /status/stream, every two seconds
ProviderHealthLatest block Lagp50p95 SuccessAnswered
Waiting for the gateway’s status.
Best block
—
Cache hit rate
—
Cached answers
—
Rate limit
—

Send a request

Simulate an outage for this request

Tick a provider and the gateway treats it as down for your next request only. Nobody else’s requests are affected, and it does not count against the provider.

Providers appear here once the gateway answers.

Response

HTTP status
—
Answered by X-Upstream
—
Cache X-Cache
—
Gateway time X-Latency-Ms
—
Tried, in order X-Failover
—
Round trip from this tab
—
Send a request to see the gateway’s answer.

Try these

  • Takes down every provider but the last for one request. X-Failover lists each one the gateway tried before the one that answered.
  • With nothing left to try, the gateway answers 502 and says which providers it tried.
  • Asks for block 1,048,576 twice. That block is long final, so its answer can never change, and the second request is answered by the gateway’s cache without asking any provider.
  • Fires 30 requests at once, more than the gateway’s burst allowance for one visitor, so some are refused with 429 and a Retry-After header.
  • Calls eth_sendRawTransaction. It is not on the allowlist, so the gateway refuses it without forwarding it anywhere.
  • Asks for logs over a range wider than the gateway allows, and is refused before any provider is asked.

How it works

Routing. Each request goes to the next healthy provider in turn. If that provider errors, times out or is marked down, the gateway tries the next one, and the X-Failover header lists every provider it tried, in order, ending with the one that answered. A provider whose latest block falls too far behind the others is treated as unhealthy until it catches up, because an answer from a stale node is a wrong answer that looks right.

Caching. Only answers that cannot change are cached, such as a block asked for by its number. Anything that asks about “latest” always goes to a provider.

Limits. Each visitor has a token bucket: a burst allowance, refilled at a steady rate per second. The gateway accepts only the read methods on its allowlist, one request at a time (no batches), and caps how many blocks one log query may span. The current values are shown above and come from the gateway’s own /status.

The figures. Latency percentiles, success rates and the cache hit rate are the gateway’s own measurements of the traffic it has served since it last started. X-Latency-Ms is the time the gateway spent on your request; the round trip is measured by this tab and includes the network between you and the gateway.

What it does not do. It runs no node, holds no keys and forwards no writes. The providers are public services run by other companies, named in the table above as the gateway reports them; your requests’ contents (such as an address you look up) reach whichever provider answers, under that provider’s own terms. The gateway does not pass your IP address on to them.