`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