Same token, different chain: native vs bridged stablecoins

You and a friend each hold 500 USDC on different networks. An exchange accepts your deposit but not theirs. Same ticker, same logo — so what's going on?

The short answer: "USDC" or "USDT" is not one token. It's a family of separate contracts on separate blockchains, and not every member of that family is issued the same way. Here's why that matters, and how to check which one you hold.

One name, many contracts

A token on Ethereum, Polygon, Base or Solana is a program (a smart contract, or on Solana a "mint") living on that one chain. A chain can't see another chain's contracts. So when a stablecoin is available "on ten chains", there are at least ten separate contracts, each with its own address, its own supply and its own rules.

Even details differ: on BNB Smart Chain, the USDT and USDC listed in SSP Wallet use 18 decimal places, while the Ethereum versions use 6.

If you're new to the idea that tokens live inside a chain and need its native coin for fees, coins vs tokens covers the basics.

Native vs bridged: who actually stands behind it?

There are two broad ways a stablecoin ends up on a chain.

Natively issued. The issuer itself deploys the contract and mints and redeems tokens on that chain directly. Your claim runs straight to the issuer's reserves, under the issuer's terms. What backs stablecoins explains what those reserves are.

Bridged. Someone locks the original tokens in a contract on one chain, and a bridge mints a matching "wrapped" token on another chain. That token isn't directly redeemable with the issuer. It's an IOU on whatever is locked in the bridge, so it carries the bridge's risk on top of the issuer's. If the bridge is drained or its keys are compromised, the bridged token can lose its backing while the native token is unaffected. Why bridges keep getting hacked and wrapped tokens go deeper on both.

The two often coexist. On Polygon, for example, USDC first arrived through a bridge. When Circle later began issuing USDC natively there, the older bridged token was relabelled USDC.e, and both kept circulating as separate tokens.

Why the contract address is the identity

Names, tickers and logos are just labels. Anyone can deploy a token contract and call it "USDC" with six decimals and a blue logo. Scammers do exactly this, and airdrop look-alikes to wallets hoping someone will try to use them.

The only thing that can't be copied is the contract address. On a given chain, exactly one address is the issuer's USDC (or, where several exist, one is native and the others are bridged versions with their own addresses). Two tokens with identical names but different addresses are different assets, full stop.

This is also why exchanges and payment services can credit one version and not another. A service decides which contracts it supports on which networks. Send a bridged version, or the right token on the wrong network, and the deposit may not be credited automatically. Before sending, check three things: the network, the token, and the exact contract the recipient accepts.

How to check a token contract

• Start from the issuer. Major issuers publish their official contract address for each supported chain. Compare against it character by character, not just the first and last few.
• Use a block explorer. Look up the address on the chain's explorer. Check that it's verified, the name and decimals match, and its history looks like a major stablecoin, not a contract created last week.
• Distrust addresses from replies, ads or DMs. They're a common route for fake contracts.
• Ask the recipient. If you're paying an exchange or a business, use the network and token they list on their deposit page, not the one you assume.

How SSP handles this

SSP Wallet ships a built-in token list for each supported EVM chain and for Solana. It includes widely used stablecoins: for example USDT and USDC on Ethereum, USDT and the natively issued USDC on Polygon, USDC on Base, USDT on Avalanche, USDT and USDC on BNB Smart Chain, and Circle's USDC mint on Solana. The lists are short, so not every version of every stablecoin is there.

For anything else, you can add a custom token by pasting its contract address (or mint address on Solana). SSP fetches the token's name, symbol and decimals, and adds it to that chain only. Keep in mind that the name and symbol come from the token itself, which means a look-alike will happily call itself "USDC". The address you paste is what matters, so take it from the issuer or the explorer.

Once a token is added, SSP Wallet shows its contract address, decimals and network in the token's details, with a copy button, and the contract also appears in transaction details. On the approval side, SSP Key shows the token contract (or Solana mint) for a token transfer before you approve. If the phone doesn't recognise the token — for instance one you imported only in the browser extension — SSP Key shows the amount in raw units and labels it an unknown token, rather than trusting a name it can't verify.

The honest summary

"USDC" and "USDT" are families of separate contracts. Some are issued natively by the issuer; others are bridged IOUs that also depend on a bridge holding up. The ticker tells you very little — the network plus the contract address tells you what you actually hold.

Before sending stablecoins, confirm the network and the exact contract the recipient accepts, and check unfamiliar contracts against the issuer's published list and an explorer. SSP helps by pre-listing common stablecoins, showing contract addresses, and flagging unrecognised tokens on SSP Key, but it can't decide for you which version an exchange will credit.