Token identity: chain and address before symbol

A ticker is not a token identifier. Store an ERC-20 selection using its chain ID and contract address, then attach the name, symbol, decimals and logo as metadata with a known origin.

Build the key before the label

The same symbol can describe unrelated contracts. The same address string can exist on different EVM chains. A proposed key such as erc20:56:address keeps those cases separate. Native currency should use a separate key kind so that an API placeholder cannot accidentally become a token contract.

Read contract metadata or a reviewed token registry after resolving identity. Under ERC-20, name, symbol and decimals are optional. A failed symbol call therefore does not prove that an address is not a token. A missing decimals value, however, means the application cannot safely interpret a human amount without another trustworthy source.

Make ambiguity visible

When a user pastes an address, display the chain and enough of the address to verify the selection before showing a familiar-looking logo. If metadata sources disagree on decimals, block amount entry until the discrepancy is resolved. Choosing the most common number would change transaction size rather than merely change presentation.

Cache metadata by identity and record its source. Do not let a later symbol-only search overwrite a selected contract. In a saved trade, preserve the identity and base-unit amount even if the token changes its label.

A useful fixture has two tokens with the same symbol and different decimals. Selecting one, switching to the other and returning must not reuse the wrong balance or amount conversion. Another fixture should omit every optional label while retaining an explicit supported decimals value. The form should remain understandable through its address and network display.