A coin picker looks simple until the same symbol appears several times. USDC on Ethereum and USDC on Solana share a ticker, but a quote request cannot treat those options as interchangeable. The network changes what the provider must accept and where the output must be delivered.

For a developer building a cross-chain crypto swap interface, this is a data-modelling problem before it is a design problem. If the application uses the ticker as its only key, the wrong option can survive selection, deduplication, caching or restoration from a saved search. Showing a network badge later does not repair an ambiguous request created earlier.

Original TornadoSwap development illustration using the official Bitcoin and USDC icons. Two USDC network options produce different quote requests. The diagram is explanatory and does not claim that either example has a current provider route.

Make the asset-network pair explicit

The Tornado Swap interface represents a listed coin with fields including ticker, network, name, amount limits and whether a memo is required. Its catalogue normalisation deduplicates by ticker and network together. A ticker repeated on another network is retained as a separate option.

This design reflects a broader distinction visible in issuer documentation. Circle publishes USDC contract identifiers separately for supported networks and distinguishes mainnet assets from testnet tokens. A familiar symbol does not supply the missing chain or token-contract identity. See Circle's current USDC contract directory: https://developers.circle.com/stablecoins/usdc-contract-addresses

Within a provider integration, preserve the provider's exact network identifiers as transport values. A friendly label such as Ethereum can appear in the UI, while a provider may expect a particular network string in its request. Maintain an explicit mapping rather than deriving the transport value from a translated display name.

A small conceptual key function can express the idea:

type ListedAsset = { ticker: string; network: string };
const assetKey = (asset: ListedAsset) =>
  JSON.stringify([asset.ticker, asset.network]);

const ethereumUsdc = { ticker: 'usdc', network: 'ERC20' };
const solanaUsdc = { ticker: 'usdc', network: 'SOL' };
// These keys are intentionally different.
assetKey(ethereumUsdc) !== assetKey(solanaUsdc);

This is an illustrative application key, not a universal token identifier. A larger catalogue may also need chain IDs, contract or mint identifiers, issuer information and native-versus-bridged distinctions. Define the uniqueness guarantee your own catalogue actually provides; a symbol and a loosely normalised network name cannot resolve every token collision.

Carry identity through the whole request

A quote needs both sides of the exchange: sending ticker, sending network, receiving ticker, receiving network and input amount. Tornado Swap's request contract reads those fields separately. It rejects an identical sending and receiving ticker-network combination as a no-op while allowing distinct network choices to be evaluated.

Do not reduce the receiving selection back to a ticker when serialising a form. For example, replacing a stored object with just usdc would discard the information the user selected. The same principle applies to page routes, saved searches, analytics labels and React list keys: retain enough context to identify the selected network.

A robust review screen should make the two directions visible. A user exchanging Bitcoin for USDC needs to distinguish the network used for the Bitcoin deposit from the network used for the USDC payout. A single generic network label near the bottom of a card leaves room for a costly misunderstanding.

A valid catalogue entry is not a live route

There are two different checks. The first asks whether each selected coin-network option exists in the supported catalogue. The second asks whether a provider currently offers a route for that exact pair and amount. Passing the first check does not prove the second will pass.

In the current implementation, local contract validation checks that both options are listed and that the sending amount falls within the catalogue's limits. The interface then requests provider quotes. An empty quote result is an availability outcome, not a reason to silently change the user's receiving network.

That distinction also matters when building token landing pages. A page can describe an asset-network option without promising that every destination is always available. Keep a clear live-quote step between discovery and order creation. A static pair page or a listed destination is not a standing commitment from an exchange provider.

Normalise data without inventing support

External responses can contain duplicate entries, invalid amounts or mixed representations of a boolean. Tornado Swap's normalisation code checks for required strings and finite positive amount limits before exposing coin options. It converts the memo flag into a consistent boolean and deduplicates the ticker-network key.

The useful engineering principle is to define an accepted shape at the boundary. Do not let a malformed entry become a selectable coin just because its ticker and image look convincing. Likewise, do not fill a missing network with a guessed default simply to make a response render.

Keep display formatting separate from transport data. A translation or a more readable label can improve the picker, but it should not silently rewrite the identifiers sent to the provider. When those identifiers need to change, update and verify the mapping deliberately.

Invalidate quotes when the inputs change

Once a quote appears, another class of ambiguity can emerge: the form shows the newly selected network, but the estimate belongs to the previous request. Treat the selection, amount and quote as related state rather than independent labels that happen to be nearby.

The Tornado Swap component aborts an earlier quote request and uses a request-version guard while inputs change. The intended result is to keep stale responses from replacing the estimate for a newer selection. The displayed receive amount is labelled approximate, and quote expiry is checked before order creation.

Those mechanisms address interface consistency. They do not guarantee provider availability, a final payout amount or execution time. A server still needs to validate the request it receives rather than trust a browser merely because it rendered the expected controls.

Address checks remain a separate responsibility

A listed receiving network does not prove that a supplied wallet address is valid for it or supported by the receiving service. Structural form checks, chain-specific address validation, required memos and a destination platform's deposit policy are different layers.

The current shared address helper trims input and applies basic type and length limits. That is input-shape validation, not cryptographic proof of ownership or a complete blockchain-address validator. Developers should name that boundary accurately instead of describing every non-empty input as verified.

Similarly, a deposit QR code can carry an address without carrying the amount, network or memo. The surrounding order screen must preserve those instructions. Ethereum's network documentation provides useful context for why a network is part of the environment a transaction belongs to: https://ethereum.org/developers/docs/networks/

Keep the provider boundary visible

Tornado Swap compares independent provider offers without requiring a wallet connection to the interface. That removes one browser-wallet interaction, but the chosen provider still handles the deposit, conversion and payout. Provider verification rules and eligibility restrictions continue to apply.

The development lesson is broader than one exchange: model what the user actually chose, preserve it across every boundary, and distinguish catalogue validity from executable availability. A precise asset-network identity makes that possible. A familiar ticker alone does not.

Service reference and implementation scope

Tornado Swap: https://tornadoswap.app/ Implementation reviewed for this guide: catalogue normalisation, pair validation and quote-request handling in the local Tornado Swap source, 19 October 2026. The code fragment above is a simplified example. This guide does not claim exhaustive testing, an independent security audit or guaranteed compatibility with any wallet or provider.