Skip to content

feat(server): implement chain.getChainInfo in the core - #358

Draft
valentinfernandez1 wants to merge 6 commits into
mainfrom
rfc-0026-core-impl
Draft

feat(server): implement chain.getChainInfo in the core#358
valentinfernandez1 wants to merge 6 commits into
mainfrom
rfc-0026-core-impl

Conversation

@valentinfernandez1

@valentinfernandez1 valentinfernandez1 commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Part of #352, implements the wire surface from #354.

Draft until #354 merges: this branch is stacked on rfc-0026-supported-chains, so it will be rebased and updated once the RFC PR lands.

What

chain.getChainInfo now works end to end in the core. Hosts implement one callback, Features::supported_chains, returning a HostChainSet (the network string plus one genesis hash per ChainIdentifier role), and the core resolves each request against it in host_logic/features.rs, echoing the identifier and mapping a miss to NotSupported.

Verified end to end against the headless host CLI: a battery run with the CLI answering supported_chains from its paseo-next-v2 preset resolved getChainInfo over the real wire (Chain/get_chain_info reported ✅), and the generated examples that resolve their genesis hashes through it kept their baseline results. That CLI chain set ships in a follow-up PR.

Add the RFC document plus its protocol surface: chain.getSupportedChains (wire id 166) enumerates the chains a host serves as (name, network, genesisHash) descriptors, and chain.resolveChain (168) maps a (name, network) pair to its genesis hash or NotFound. Both trait methods are stubs returning unavailable, so products stop hard-coding genesis hashes once hosts implement the backing syscall in a follow-up.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant