Distinguish native and bridged stablecoin contracts

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

A ticker is not an asset identity

Two tokens can both display USDC, use six decimals and trade near one dollar while representing different claims. The minimum identity tuple is chain ID plus contract address. Add issuer, mint-and-burn controller, backing location, bridge contracts and redemption route. Wallet icons and exchange deposit labels are presentation. They do not replace that tuple.

Trace the claim in order

1. Get the destination chain and accepted contract address from the receiving service's current first-party page. Do not start from a search result or token list alone.
2. Compare that address with the issuer's contract list. If it is absent, determine whether the token is bridged, independently issued or unsupported.
3. For a bridged token, identify its origin contract and canonical bridge. Verify that deposits escrow origin tokens and mint a representation, and that withdrawals burn the representation before releasing escrow.
4. Trace admin and upgrade powers for the token and bridge with the proxy workflow.
5. Read the recipient's deposit warning. Some services credit only one contract even when both variants are liquid on-chain.

Circle's Arbitrum announcement gives a concrete identity check: native USDC is contract 0xaf88…e5831; bridged USDC.e is 0xFF97…5CC8, and Circle says USDC.e is not issued by Circle. Circle Mint's current documentation separately warns not to send bridged USDC to supported deposit addresses. The names are similar; the liabilities and accepted routes are not.

Hypothetical example

Hypothetical: a wallet shows 1,000 'USD Coin' on Chain Q. An exchange says it accepts native USDC on Chain Q at contract 0xN…. The wallet asset is 0xB…, whose verified code points to a bridge gateway and an Ethereum origin token. A price quote near $1 does not close the identity gap. The safe research conclusion is that the wallet holds a bridged representation not listed for that deposit. The user would need a supported conversion or bridge path documented by the relevant operators; a small test transfer can reduce operational uncertainty but cannot make an unsupported contract supported.

Keep risk layers separate

Native issuance concentrates issuer and reserve risk. A bridged representation adds bridge custody, messaging, contract and upgrade risk to the underlying stablecoin risk described in the bridge note. Neither label guarantees liquidity or redemption access. The issuer may redeem only for eligible customers, while retail users trade through intermediaries, as the redemption guide explains.

Limits

Contract lists, supported chains and exchange deposit policies change. Recheck immediately before use and preserve the retrieval time. Token-list metadata can be stale or malicious, and a verified contract name can be copied. This workflow establishes technical identity and documented acceptance; it does not guarantee par value, bridge solvency, issuer solvency or successful recovery from a mistaken transfer. It is not investment advice.