Audit shared token catalog coverage and canonical address provenance #38

Problem

The shared Tokens catalog is used to recognize assets and construct Skill choices, but its coverage is uneven. PR #37 adds EURC on four chains; it does not establish comprehensive coverage or certify every listed token as freely transferable.

At #37's current head there are 143 chain-specific entries: Ethereum 105, Base 24, BNB Chain 2, Sepolia 7 and Base Sepolia 5. Counts are entries per chain, not unique assets. Concrete gaps include WBNB on BNB Chain and RLUSD on Ethereum/Base. Some assets are already known in protocol-specific registries without appearing in the shared token catalog.

Scope

Audit the supported chains and define what coverage the catalog promises. Treat “known good” as verified asset identity and provenance, rather than an investment-safety endorsement or proof that every destination can receive it.

• Inventory the shared catalog and protocol-specific token/address registries. Reconcile missing entries and duplicates without using cross-chain lookup fallback as evidence of identity on a particular chain.
• Define a practical baseline per supported mainnet: widely used stablecoins, canonical native wrappers, common BTC representations, liquid-staking assets, and established DeFi assets. Document the selection criteria and compare against issuer/protocol address books and maintained ecosystem token lists.
• Verify each proposed chain/contract pair against canonical sources. Distinguish native versus bridged variants and legacy deployments. Check code and decimals with read-only calls where useful; symbol/name alone are insufficient evidence.
• Keep native currency handling separate from ERC-20 contracts. Treat testnets separately: include verified test deployments, rather than assuming every mainnet asset has an equivalent test token.
• Record transfer constraints relevant to consumers, including permissioned recipients, rebasing and transfer-fee behavior. Listing an asset should not silently imply that it can join a standard atomic sweep to any address. Do not automatically hide legitimate holdings merely because they have additional transfer rules.
• Review the existing provenance/documentation process and propose lightweight checks to prevent future gaps or address drift.

Deliverables

1. A per-chain coverage matrix: present, missing, legacy/bridged variant, unverified, or requires special transfer handling; include canonical source links and verification dates.
2. A prioritized gap list, beginning with WBNB and RLUSD, and small catalog PRs with changesets and integrity tests.
3. A documented catalog inclusion/maintenance policy and an explicit list of remaining gaps. Avoid claiming “all common tokens” without a defined, testable coverage target.
4. Consumer guidance distinguishing asset recognition from transfer eligibility. Studio can show recognized holdings while preparation validates whether the selected transfers actually work.

Sources / related work

• EURC addition: feat: add Circle EURC to the shared token catalog #37
• Studio discovery/sweep integration: https://github.com/AvaProtocol/studio/pull/2028
• Ripple canonical addresses: https://docs.ripple.com/products/stablecoin/overview/token-addresses
• PancakeSwap maintained token list: https://github.com/pancakeswap/token-list/blob/main/src/tokens/pancakeswap-extended.json
• Ondo OUSG transfer/onboarding constraints: https://docs.ondo.finance/qualified-access-products/ousg/overview

This is a coverage/metadata audit. It requires no live token transfers or wallet signatures.