Four chains at launch, and the truth about where they run.

What "vetted upstream" means

Your request hits our gateway, which holds your key, your quota and your usage record. Behind it, the call goes to a commercial node provider we pay for and monitor — with failover to a second one, and a block-height check so a backend that has fallen behind is taken out of rotation rather than served to you.

Once our own node for a chain is in sync and proven, it becomes the primary path and the upstream becomes the fallback. Your endpoint, key and code stay exactly the same. That has now happened for Ethereum.

Why we publish this: an "own infrastructure" badge on day one would be the easiest lie on this site, and the first thing a serious buyer would check.

Ethereum: what our own node actually is

Since 8 September 2026 every Ethereum call goes first to a node we run ourselves — a Helios light client. It is not a full node, and the difference matters, so here it is in full.

The light client follows the beacon chain sync committee and verifies the chain headers itself. When it answers a call such as eth_getBalance or eth_call, it fetches the underlying data from a public execution endpoint and then checks that data against the header it verified. A wrong or tampered answer from that endpoint does not reach you: it fails the check. In other words, we no longer ask you to trust the upstream, and we no longer ask you to trust us either — the proof is in the response path.

What it does not do. It stores no chain state and keeps no archive, so it cannot serve historical state, traces or debugging calls. Methods it does not implement — eth_feeHistory, debug_*, trace_* among them — are passed to a vetted upstream instead, exactly as before. Those answers are not verified, and we do not pretend otherwise.

What it still trusts. On each start it takes a recent finalised checkpoint from a public beacon endpoint. That is a single trusted moment; everything after it is verified cryptographically. If that endpoint is unavailable, the node keeps its previous checkpoint rather than starting blind.

You can check this yourself. Every gateway response carries an X-Chain-Verified header: yes when our own node produced and verified it, no when it came from an upstream, partial for a batch where only some calls qualified. If our node is down or lagging, it is taken out of rotation, the upstream answers, and the header says no. It will never say yes for an answer we could not prove.

Polygon, Base and Arbitrum have no Phantrium node yet. Base would need its own consensus feed, and all three need storage this machine does not have. Until that changes, their column above stays honest.