feat: named asset locations (dot asset add/inspect/remove)

Summary

XCM asset locations are verbose JSON and relative — the same asset has different parents values depending on which chain you're on. This makes CLI usage painful for cross-chain transfers.

Proposal: Let users save assets by name and reference them in tx commands, with automatic perspective-based location conversion.

Motivation

Currently, transferring a foreign asset requires verbose JSON:

dot paseo-people.tx.Assets.transfer \
  '{"parents":1,"interior":{"type":"X3","value":[{"type":"Parachain","value":1000},{"type":"PalletInstance","value":50},{"type":"GeneralIndex","value":50000413}]}}' \
  5GsXsx1L6d52DviYjnZdwyENor644q95dxbftcn2gxAWSYr3 \
  100000000000000000000 \
  --from alice

With named assets, this becomes:

dot asset add my-token Parachain(1000) PalletInstance(50) GeneralIndex(50000413)
dot paseo-people.tx.Assets.transfer my-token 5GsXsx... 100000000000000000000 --from alice

The CLI auto-converts my-token to {parents:1, interior: X3(Parachain(1000), PalletInstance(50), GeneralIndex(50000413))} because paseo-people is parachain 1004 (not 1000), so parents: 1.

Design

Storage

Assets stored as canonical junctions (from relay chain perspective) in ~/.polkadot/assets.json:

{ "name": "my-token", "junctions": [
  {"type": "Parachain", "value": 1000},
  {"type": "PalletInstance", "value": 50},
  {"type": "GeneralIndex", "value": 50000413}
]}

Relative Location Conversion

Given canonical junctions [J1, J2, ..., Jn] and current chain's parachainId:

• Relay chain (no parachainId): { parents: 0, interior: X_n(J1..Jn) }
• Parachain C where J1 is Parachain(C) (asset is local): strip J1 → { parents: 0, interior: X_(n-1)(J2..Jn) }
• Parachain C otherwise: { parents: 1, interior: X_n(J1..Jn) }

CLI Commands

dot asset add <name> [junction1] [junction2] ...    # Save a named asset
dot asset list                                       # List all named assets
dot asset remove <name>                              # Remove a named asset
dot asset inspect <name> [--chain <chain>]           # Show relative location for a chain

TX Integration

In parseTypedArg, when a struct matches a Location shape (parents + interior fields) and the arg is a plain string, try resolving it as a named asset. Thread a ParseContext { chainName, parachainId } through the parsing functions.

Parachain ID Knowledge

Add parachainId to ChainConfig and DEFAULT_CONFIG entries:

• *-asset-hub: 1000, *-collectives: 1001, *-bridge-hub: 1002, *-people: 1004, *-coretime: 1005

Add --parachain-id <N> flag to dot chain add for custom chains.

Built-in Assets

Ship with common assets: dot (native relay token), usdt (GeneralIndex 1984), usdc (GeneralIndex 1337).

Files to Create/Modify

New:

• src/config/assets-types.ts — types, defaults
• src/config/assets-store.ts — persistence (load/save/find)
• src/core/location.ts — conversion algorithm, junction parsing
• src/commands/asset.ts — CLI commands
• src/core/location.test.ts + src/commands/asset.test.ts — tests

Modify:

• src/config/types.ts — add parachainId to ChainConfig + DEFAULT_CONFIG
• src/core/client.ts — add parachainId to KNOWN_CHAIN_SPECS, export helper
• src/commands/chain.ts — --parachain-id flag
• src/commands/tx.ts — thread ParseContext, resolve asset names in Location structs
• src/cli.ts — register asset commands
• src/completions/complete.ts — asset completions

Start by reading the proposed entry points in src/core/location.ts, src/config/assets-store.ts, src/commands/asset.ts, and src/commands/tx.ts, then review the existing chain and CLI registration paths. Use the named location and chain examples as acceptance cases, and run the new location and asset tests once implemented. Done means asset persistence, relative conversion, commands, chain configuration, transaction resolution, completions, built-ins, and coverage are integrated.