Skip to main content
Merkle Street

Protocols, markets, policy, people

A Token’s Ticker Is Not Its Identity

A token’s ticker is not enough to identify it: check its network, contract address, and destination before sending or swapping funds, so you can distinguish assets that share a familiar name.

Merkle Street Newsroom#22ec233 min read

Abstract cover artwork

A token variant check confirms the network and contract address of the asset you are about to send or swap. A ticker such as USDC or ETH is a label, not a unique identifier. First, identify the network selected in your wallet or exchange. Next, compare the token’s contract address on that network with the address given by the recipient or other trusted source. Then check that the destination can receive that asset on the same network.

This matters because one token can have native and bridged versions, or separate contract deployments on different networks. A bridge locks or burns an asset on one chain and issues or releases a corresponding version on another; the result may share a ticker with other tokens without being interchangeable everywhere. For a fuller explanation of how a native cross-chain swap handles these moving parts, see this guide to Chainflip and native cross-chain swaps. The same principle applies to an ordinary transfer: verify the asset and network as a pair.

How do I tell two token variants apart?

Compare the network name and contract address; together, they identify most tokens more reliably than a name or ticker. A contract address points to the token’s smart contract on a particular chain. The same address string can exist on different chains, so the network is part of the check. Native coins, which are built into a network rather than issued by a token contract, need a network check but have no token contract address.

Use a source that is tied to the project or the service you are using to confirm the address. Then compare the full address, not just its first and last few characters. A wallet may display a familiar name or logo for convenience, but those labels do not prove that the selected contract is the intended asset.

What should I check before sending tokens?

Before you confirm a transfer, check the asset, network, recipient address, and any destination requirements shown by the receiving service. A matching address format does not establish that two networks are compatible. If the recipient expects a token on one network and you send it on another, recovery may depend on the recipient’s support and the receiving chain’s rules.

  • Asset: Confirm the token name and contract address, or the native coin, against a trusted source.
  • Network: Match the sender’s network to the network the recipient can receive.
  • Destination: Check the full address and any required memo or tag shown by the service.
  • Amount: Review the displayed asset and amount on the confirmation screen before signing.

For a new address or an unfamiliar token, a small test transfer can help confirm that the route works, though it may incur a fee. It does not replace checking the network and contract: a test sent to the wrong destination can still be lost.

How do token checks work when swapping?

A swap quote connects the token you offer to the token you want through a route such as a pool or order book. Check both assets in the quote, including their networks and contract addresses where available. A similar ticker in the output field may refer to a different variant, and a route across chains may involve a bridge or other intermediary.

Wallet confirmations show the transaction details that will be signed, but the exact fields vary by wallet and route. Read the asset and network shown by the interface before approving. The practical rule is simple: treat a token as its network and contract, not its ticker. When those details match the intended transfer or swap, the label becomes useful context rather than the basis for the decision.