Every TrUAPI chain call takes a genesis hash, and products currently get those from constants baked into their own bundles (PASEO_NEXT_V2_ASSET_HUB in @parity/truapi, the WellKnownChain table in product-sdk). This breaks in two ways. When a testnet is wiped and restarted, its genesis hash changes and every product's hard-coded constant goes stale until a new bundle ships. And each product has to know ahead of time which network its host is connected to. If the host and the product disagree, calls fail at runtime, and moving a product between environments means shipping new constants.
The host already knows exactly which chains it can talk to, so products should be able to just ask.
Proposal
Add one method to the chain service.
chain.getChainInfo({ chain }) takes one chain identifier, drawn from a closed role enum (Relay, AssetHub, People, Bulletin), and returns the environment the host is configured for plus the chain's genesis hash:
const result = await truapi.chain.getChainInfo({ chain: "AssetHub" });
// { network: "paseo", chain: "AssetHub", genesisHash: "0x..." }If the host doesn't serve the requested chain the call fails with NotSupported. A product needing several chains issues concurrent calls; the transport multiplexes them, so there's no extra round trip and no batching semantics in the protocol.
A product never says which network it wants. The host is configured for one environment (polkadot in production), and every identifier resolves against that. The network field on the response is informational: it tells the product or SDK which environment the host is on. The identifiers are chain roles, not chain instances, so they are typo-proof and mean the same thing on every host; adding a new role is an additive enum variant.
Display names and token properties stay out of the response. Once you have the genesis hash you can already get those through getSpecChainName and getSpecProperties.
Host-side this follows the same pattern as featureSupported: one new platform syscall returning the configured chain set, which each host backs with config it already has (dotli's network config already enumerates relay, asset hub, bulletin and people per environment). The wire method is answered in the core from that syscall, so hosts implement one callback.
The full wire spec is in RFC 0026 (#354).
Every TrUAPI chain call takes a genesis hash, and products currently get those from constants baked into their own bundles (
PASEO_NEXT_V2_ASSET_HUBin@parity/truapi, theWellKnownChaintable in product-sdk). This breaks in two ways. When a testnet is wiped and restarted, its genesis hash changes and every product's hard-coded constant goes stale until a new bundle ships. And each product has to know ahead of time which network its host is connected to. If the host and the product disagree, calls fail at runtime, and moving a product between environments means shipping new constants.The host already knows exactly which chains it can talk to, so products should be able to just ask.
Proposal
Add one method to the chain service.
chain.getChainInfo({ chain })takes one chain identifier, drawn from a closed role enum (Relay,AssetHub,People,Bulletin), and returns the environment the host is configured for plus the chain's genesis hash:If the host doesn't serve the requested chain the call fails with
NotSupported. A product needing several chains issues concurrent calls; the transport multiplexes them, so there's no extra round trip and no batching semantics in the protocol.A product never says which network it wants. The host is configured for one environment (polkadot in production), and every identifier resolves against that. The
networkfield on the response is informational: it tells the product or SDK which environment the host is on. The identifiers are chain roles, not chain instances, so they are typo-proof and mean the same thing on every host; adding a new role is an additive enum variant.Display names and token properties stay out of the response. Once you have the genesis hash you can already get those through
getSpecChainNameandgetSpecProperties.Host-side this follows the same pattern as
featureSupported: one new platform syscall returning the configured chain set, which each host backs with config it already has (dotli's network config already enumerates relay, asset hub, bulletin and people per environment). The wire method is answered in the core from that syscall, so hosts implement one callback.The full wire spec is in RFC 0026 (#354).