One name per chain for the blackbeard wallet (blackbeard/wallet #53), on
the same edge proxy as the site: a CNAME to the site indirection, a Let's
Encrypt certificate, and a vhost that proxies JSON-RPC over HTTP and
WebSocket to the chain's upstream. quantus_node is our node on bob across
the mesh (bob's firewalld now admits oolon by name, lair/quantus deploy);
planck_node is Quantus's two official testnet hosts over TLS with SNI and
verification, since we run no testnet node. Upstreams and the per-client
throttle zones (20 requests a second with a burst of 40, 16 concurrent
connections, 429 on excess) live in conf.d/blackbeard-nodes.conf so each
vhost stands alone.
script/infra-setup.sh gains a nodes role that does the three steps per
name, enables the vhosts only after nginx -t passes and disables them
again if it does not, and ends by asking each name for system_chain.
Run today: both names carry certificates to 2026-12-15 and Planck
answers; the quantus record was still propagating when the script asked.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ftBXYuba8ARhQeF74oUgW
Mainnet was the only chain left on a single endpoint, and that endpoint is our
own node — so a restart on bob took the flagship chain off the site while both
testnets, on two endpoints each, stayed up.
Our node stays first, and has to: loopback pays no network hop, and `127.0.0.1/32`
is the only address whitelisted against its `--rpc-rate-limit 300`. Behind it are
`rpc1-` and `rpc2-mainnet.quantus.com`, both of which answer `archive_v1_*`,
report the same genesis and the same runtime, and accept a `wss://` upgrade.
They took some finding, which is recorded in the template's comment so the next
person does not repeat the search: mainnet uses a different domain *and* a
different prefix from the testnets, its bootnodes serve only p2p on 30333, and
the official explorer talks to a GraphQL indexer rather than to any node at all.
This buys availability, not depth. Failover moves on a transport failure, and a
pruned node answers `{"result": null}` — a success, so a deep state read would
stop at it rather than fall through to a peer that has the answer. Filed as #9.
Closes#8
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5
A chain entry held exactly one `rpc_url` and one `ws_url`, and when that host
went down everything for that chain stopped — headers, difficulty, backfill,
state reads, runtime discovery. The endpoints already existed in pairs:
`a2-planck` and `a2-heisenberg` both answer and neither was configured. We were
choosing single points of failure the network went to some trouble to avoid.
`rpc_urls` and `ws_urls` are lists now, and `rpc_url`/`ws_url` still work as a
one-element list — a config naming one endpoint is still a valid config, and
making every deployment rewrite its entry would be this feature breaking the
thing it exists to make reliable.
Endpoints are stuck to rather than balanced across, which is the design and not
laziness: a storage read at an old block hash needs a node that still holds that
block's state, and nodes prune on their own schedules, so alternating would
return a mixture of answers and absences that reads as sparse data rather than a
configuration problem. The cursor is shared across clones so a failover one task
finds is not rediscovered by every other task on the chain.
Failing over on the wrong thing was the trap worth avoiding. A JSON-RPC error is
the node answering — moving on `count exceeds maximum value` would hide a
caller's mistake behind a second node making the same complaint — so a new
`Malformed` variant separates "did not answer" from "answered, with an error".
A pruned block returns `{"result": null}`, a success, and never looks unhealthy.
The WebSocket rotates at reconnect, where the loop already was; racing
subscriptions across endpoints and deduplicating heads buys nothing, since heads
are a liveness signal and ingest fills gaps against `chain_getBlockHash` anyway.
Verified live with a dead endpoint configured first: Planck stayed `full` at its
real height, the RPC logged one `failed over` with from and to, and the head
subscription logged the loss with the endpoint count beside it — because "the
chain is unreachable" and "one of three endpoints is unreachable" are different
operational facts and used to look identical.
Closes#7
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5
`a1-planck.quantus.cat` answers, and has all along. The config comment claimed
Planck "publishes no RPC endpoint we can find" — true when written, and never
rechecked after the node we ran for it was switched to mainnet. A million blocks
of history and 2.38M zk-tree leaves were sitting there unasked for.
Measured before committing to it. Three chains backfilling at once cost 4.8% of
one core, five of eight Postgres connections with one active, and no movement in
API latency — summary 7 ms p95, block 13 ms, account 49 ms. The walk is bound by
RPC round trips rather than by anything local, so it needs no deployable of its
own; and `backfill` only reads in-memory state while writing solely to Postgres,
so it contends with nothing the API serves.
Unthrottled deliberately: ~46 hours at roughly 20 requests a second against a
public node. Leaning on public decentralised testnet infrastructure exercises
what it is there for.
Restart resilience confirmed by killing the process mid-walk — `event_scan.low`
stayed put rather than jumping back to the tip. That is load-bearing here rather
than tidy, because the cert-rotation path restarts this service several times a
day and a cursor in memory would mean Planck never finishing.
`a2-planck` answers too, and is noted for when a chain can hold more than one
endpoint.
Closes#6
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5
Mainnet launched today and the node was switched to it. The observer reads
whatever the node is on, so the `[[chains]]` entry pointing at 127.0.0.1:9944
had to follow it — until now the daemon was filing mainnet's blocks under the id
`planck`, with Planck's genesis and PLK still attached to them.
Read from the node, not assumed: `system_chain` "Quantus", genesis
`0xfb5487c0…626fba`, token QTC. `mainnet = true` is asserted here rather than
inferred, which is the field's whole purpose — telemetry also carries a chain
calling itself "Quantus Staging Mainnet", and it is not this one.
The target block time is **12 s, not the 6 s Planck used**.
`TARGET_BLOCK_TIME_MS` is 12_000 in the runtime the node actually runs —
checked at commit b017e642, the `0.11.1-b017e6420aa` its `system_version`
reports, rather than at the tip of the chain repo. It is the denominator for
every hashrate published before twenty tip samples exist, which on a chain
hours old is all of them, so carrying 6.0 across would have put out a mainnet
hashrate at exactly twice its true value — labelled "nominal", not broken.
Planck keeps its 268 telemetry nodes and stays in the site's navigation as
`no_endpoint`: still listed, no longer navigable, because authorship comes from
block headers and we no longer run a node that serves Planck's. That is an
ordinary state here, not an outage.
Nothing about the node itself is touched by this; every command run against it
was a read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5
The chain list is no longer config. substrate-telemetry announces every chain it
knows — with live node counts — before and independent of any subscription, so
one feed connection that never subscribes is a complete, self-maintaining index.
A chain that launches tomorrow appears in the nav on its own.
Config now contributes only RPC endpoints. Authorship lives in the `pow_` digest
of a block *header*, and telemetry publishes hashes and heights but never
headers — so a chain with no endpoint is listed with its node count and is not
navigable, and the nav says why rather than offering an empty board. The two
sets join on genesis hash, never on name.
Two chains are tracked in full: Planck (our own node on bob) and Heisenberg
(a1-heisenberg.quantus.cat, found via Quantus-Network/quantus-apps). Both decode
identically — same digest shape, same QPoW runtime API — which is the proof that
adding a chain is one [[chains]] entry and no new code. Quantus Staging Mainnet
and Quantus Dirac Testnet are listed and disabled: no endpoint exists under the
a1-/a2- pattern and none resolves under any plausible name.
Nav is ordered by node count descending, ties broken on id so it cannot reshuffle
between refreshes.
Telemetry now also yields chain-wide best height, best finalized height, average
block time and the client-version histogram (feed codes 1, 2, 12 and 22).
Infra moves to a single site: oolon fronts blackbeard.observer, reverse-proxying
cross-site over the mesh to the API beside the node on bob. That hop is the one
the loopback health probe cannot see, so the deploy now checks it explicitly —
a firewalld service scoped to bob's own /16 would leave a live site with a dead
/v1 and nothing would fail. infra-setup gains `dns` and `cert` roles that run on
oolon with the credential already there: the Cloudflare token is never copied off
the proxy, and it refuses to repoint an apex record that already exists.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MSDYiibCtELsrjQq6KXnoi
Cargo workspace plus a Vite frontend, following ~/git/architecture/generic.md.
Every block header carries its author's wormhole reward preimage in a `pow_`
PreRuntime digest, so authorship for the whole network is derivable from headers
alone — no indexer, no registration, no way for a miner to be left out. That
decoding, the hashrate maths and the telemetry name attribution live in
blackbeard-core with no I/O at all, so the parts that are easy to get subtly
wrong are exercised by unit tests rather than only against a live chain.
The browser holds one WebSocket: snapshot on subscribe, deltas thereafter. The
head stream is itself a push (chain_subscribeNewHeads), so a block reaches the
page the moment the node imports it. Messages are serialised once per broadcast,
and leaderboards are recomputed only for windows a socket is actually watching.
No RxJS — useSyncExternalStore is React's own contract for this.
Verified against the live Planck testnet: 12/12 headers decoded, telemetry names
attributed (quanpool-planck, baba-gorchitsa, …), warm start restoring 84 blocks
and 5 held names across a restart.
Three findings worth recording, all in CLAUDE.md:
- substrate-telemetry sends its JSON in *binary* frames. A text-only client
connects, subscribes, reports healthy and receives nothing at all — and a
Python probe hides it, because json.loads accepts bytes.
- Difficulty is a little-endian U512; decoding it big-endian gives a number
wrong by ~10^150 that still renders fine.
- Planck's real block interval is ~13-15s against a 6s target with enormous
variance, so a measured interval needs 20 tip samples before it is publishable.
Deploy assets, the Gitea Actions workflow and script/infra-setup.sh are included;
port 25864 is registered in architecture/port-allocations.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MSDYiibCtELsrjQq6KXnoi
