Network Selector

Overview

A network selector presents supported chains as controlled options rather than free text. It can determine address validation, token list, fee asset, RPC route, deposit instructions, confirmation policy, and bridge availability.

Poor selectors use ambiguous labels or retain a previous network after the asset changes. They may also show technically available networks that the recipient or recovery process does not support. Visual similarity should not replace explicit confirmation. Designers should display canonical network name, asset representation, fees, and warnings for uncommon routes. The selection must be included in quotes, signatures, API records, and audit logs. Defaults should be conservative, and any automatic change should require visible user acknowledgement before funds move. Human-readable labels are not sufficient when different chains, environments, or providers reuse similar names. Network Selector should be maintained through one versioned source of truth that defines identifiers, schemas, allowed values, ownership, and deployment scope.

Inputs to Network Selector need explicit validation and deterministic failure behavior. Unknown versions, ambiguous aliases, unsupported fields, duplicate records, and stale configurations should fail into review rather than being silently mapped to a convenient default. Rollout needs environment separation, change approval, rollback, and historical traceability so past transactions can be interpreted using the configuration active at that time. Changes to Network Selector should pass automated tests against known network identifiers, contracts, encodings, and expected outputs. Operational logs for Network Selector should record the version, caller, resolved value, and downstream action without exposing secrets. This evidence helps distinguish incorrect configuration from an upstream node, protocol, or business-logic failure.