feat(rpc): serve the endpoint capability matrix, and make get_best_rpc_endpoint workload-aware

[JSONbored]

Parent: #11066. Producer: the rpc-bench container class in metagraphed-infra.

What "best" means today, and why it is not enough

get_best_rpc_endpoint ranks on a five-call HTTP probe — liveness, genesis-hash chain identity, and
block-height plausibility. That correctly excludes an endpoint answering for the wrong chain. It
says nothing about whether the endpoint can do the work the caller has.

We already know the difference matters, from a measurement recorded in a config comment rather than
a table: get_delegates() (~15 MB) measured 11.1 s direct against 92.9 s through our own
balancer, and that single figure is why the poller does not route through wss.metagraph.sh. The
same comment notes the balancer denies the state_call prefix, which subxt issues for every
at_block() — so routing bulk reads through it would not degrade those lanes, it would break them.

None of that is expressible in the current model, and a caller integrating against us has to
rediscover it.

Scope

• A capability row per endpoint: method surface, denied prefixes, archive depth measured rather than
  declared, runtime-API support, bulk-read throughput, max response size, unsafe RPCs exposed
• get_best_rpc_endpoint gains a workload argument — "bulk archive read" and "head subscription"
  are different answers and today we return one
• The matrix served as its own surface, because it is independently useful

Contract note

Archive depth is a measurement, not a claim, and it changes. Serve it with its observation
timestamp and never let a stale depth read as current.

Acceptance

• Capability row per endpoint, dated, method surface captured verbatim
• get_best_rpc_endpoint returns different endpoints for different workloads, with the reason
• The 11.1 s / 92.9 s comparison is reproducible from served data
• Route + MCP registration checklists complete

[linear-code]

JSO-8211

[JSONbored]

Probed 2026-08-13 — the default endpoint is not an archive node, and nothing surfaces that

Four subtensor-rpc surfaces in the registry. All four pass the current five-call liveness probe
identically. They are not interchangeable.

Archive depth — a 53x spread, invisible today

Measured by binary search for the oldest height whose state answers, not whose header does:
chain_getBlockHash(n) then state_getRuntimeVersion(hash). ~23 sequential probes per endpoint.

surface	provider	archive floor	depth
opentensor-archive-rpc	opentensor	block 1	8,835,491 — full archive
onfinality-finney-rpc	onfinality	block 1	8,835,480 — full archive
opentensor-finney-rpc	opentensor	block 8,670,519	164,972
opentensor-lite-rpc	opentensor	block 8,670,519	164,974

entrypoint-finney.opentensor.ai serves ~165,000 blocks of state — roughly two weeks. It is
the default endpoint in most Bittensor tooling, and a historical query against it does not fail
loudly; it fails at whatever depth the caller happens to reach. Today the registry reports all four
as equally live.

This is exactly the fact get_best_rpc_endpoint should be selecting on and cannot.

Method surface

surface	methods	unsafe exposed
onfinality-finney-rpc	209	14 — incl. author_hasKey, author_hasSessionKeys, author_insertKey
the three opentensor endpoints	186	4 — author_pendingExtrinsics, author_submitExtrinsic, author_submitAndWatchExtrinsic

Prefix breakdown for onfinality: eth:45, state:23, subnetInfo:20, system:20, chain:19, archive:10.
Keystore methods (author_insertKey, author_hasKey) answering on a public endpoint is worth
flagging as a signal — they may well be gated at the auth layer, and this probe does not establish
that they are not. Reported as observed, not as a vulnerability claim.

state_call("Core_version") succeeded on all four — no denials. Good news, since subxt issues
it for every at_block().

What did not work, stated rather than glossed

• Bulk throughput is inconclusive. My state_getPairs probe used a storage prefix that
  returned nothing (0.00 MB), so the 11.1s/92.9s comparison is not reproduced here. Needs a
  real prefix — the get_delegates runtime call is the right target.
• lite.chain.opentensor.ai returned HTTP 429 partway through, after roughly 25 sequential
  archive-depth probes. That is itself a finding: the depth search must be rate-aware and spread
  across a window, not run as a tight loop. These are other people's endpoints.

Scope confirmed and adjusted

• Archive depth measured rather than declared — the headline capability, proven
• Method surface and unsafe exposure captured
• state_call support verified
• Bulk throughput — redo against get_delegates, and make the pass rate-aware after the 429
• Feed depth into get_best_rpc_endpoint so "best for a historical read" stops returning a
  two-week node
• Raw results: rpc_matrix_results.json