Mainnet has only our own endpoint; two public archive nodes exist #8

New Issue

grenade · 2026-09-10T08:33:04Z

grenade commented

2026-09-10 08:33:04 +00:00

What

Heisenberg and Planck each got two endpoints in #7. Mainnet — the chain that
actually matters — still has one: our own node on bob. If it goes down, so does
every mainnet number on the site.

Two public archive nodes exist:

https://rpc1-mainnet.quantus.com   Quantus  h=19,644  v=1.0.0-gm-f5828f0bd82
https://rpc2-mainnet.quantus.com   Quantus  h=19,644  v=1.0.0-gm-f5828f0bd82

Same genesis as ours (0xfb5487c0…), and both read System::Account at genesis,
block 1 and block 5000. They advertise the archive_v1_* family, plus
state_getPairs and system_peers.

Why they were not found earlier

Probing looked for the testnet naming — a1-<chain>.quantus.cat, matching
a1-p2p-<chain>.quantus.cat — and for rpc./node./mainnet.. Mainnet uses a
different domain and a different prefix: rpc1-mainnet.quantus.com, while
its bootnodes are a1..a7-p2p-mainnet.quantus.com. The bootnodes expose only
port 30333, so they are gossip peers rather than RPC providers.

Worth recording: the official explorer does not use a node at all. Its bundle
talks to https://sqm.quantus.com/v1/graphql and
https://sub2.quantus.com/v1/graphql. There was never a public archive node
behind it to find.

Change

Add both as fallbacks after our own node, which stays first: it is loopback, so
it pays no network hop and is whitelisted against the node's own
--rpc-rate-limit 300.

Known limitation, filed separately

This buys availability, not depth. Failover moves on transport failure, and a
node that has pruned a block answers {"result": null} — a success. So when bob
eventually prunes, deep state reads will return empty rather than falling
through to an archive node that has the answer.

## What Heisenberg and Planck each got two endpoints in #7. Mainnet — the chain that actually matters — still has one: our own node on bob. If it goes down, so does every mainnet number on the site. Two public archive nodes exist: ``` https://rpc1-mainnet.quantus.com Quantus h=19,644 v=1.0.0-gm-f5828f0bd82 https://rpc2-mainnet.quantus.com Quantus h=19,644 v=1.0.0-gm-f5828f0bd82 ``` Same genesis as ours (`0xfb5487c0…`), and both read `System::Account` at genesis, block 1 and block 5000. They advertise the `archive_v1_*` family, plus `state_getPairs` and `system_peers`. ## Why they were not found earlier Probing looked for the testnet naming — `a1-<chain>.quantus.cat`, matching `a1-p2p-<chain>.quantus.cat` — and for `rpc.`/`node.`/`mainnet.`. Mainnet uses a different domain **and** a different prefix: `rpc1-mainnet.quantus.com`, while its bootnodes are `a1..a7-p2p-mainnet.quantus.com`. The bootnodes expose only port 30333, so they are gossip peers rather than RPC providers. Worth recording: **the official explorer does not use a node at all.** Its bundle talks to `https://sqm.quantus.com/v1/graphql` and `https://sub2.quantus.com/v1/graphql`. There was never a public archive node behind it to find. ## Change Add both as fallbacks after our own node, which stays first: it is loopback, so it pays no network hop and is whitelisted against the node's own `--rpc-rate-limit 300`. ## Known limitation, filed separately This buys availability, not depth. Failover moves on transport failure, and a node that has pruned a block answers `{"result": null}` — a success. So when bob eventually prunes, deep state reads will return empty rather than falling through to an archive node that has the answer.

grenade referenced this issue

2026-09-10 08:37:51 +00:00

Failover buys availability, not depth: a pruned node answers null, and null is a success #9

grenade referenced this issue from a commit

2026-09-10 08:38:16 +00:00

config: give mainnet the two public archive nodes as fallbacks

grenade closed this issue

2026-09-10 08:38:16 +00:00

Sign in to join this conversation.