How to verify a real USDT or USDC token contract

A token is not genuine merely because a wallet or explorer displays the name “Tether USD,” the ticker USDT, a familiar logo or a large balance. Anyone can deploy a token with copied metadata. The decisive identifier is the full contract address on an EVM or TRON network, or the mint address on Solana, matched against an issuer or official network registry for that exact network.

Transaction count, holders, age, liquidity and an explorer badge are useful secondary checks. They are not proof: activity can be manufactured, and a popular bridged or platform-pegged asset is not necessarily an issuer-native token.

The short verification rule

Use this order every time:

1. Identify the exact mainnet: Ethereum, Optimism, BNB Chain, Base, Polygon, Arbitrum, TRON or Solana.
2. Determine which representation is expected: issuer-native, canonical bridged, platform-pegged or issuer-authorized omnichain.
3. Copy the contract or mint from the issuer or the official registry responsible for that representation.
4. Open a trusted explorer for the same network and paste the full address, not the ticker.
5. Compare every character, then check token type, symbol and decimals.
6. Treat transfers, holders and contract age as supporting evidence only.
7. For a payment, confirm that the transfer event used this same contract or mint.

Never begin by searching USDT or USDC in an explorer and trusting the first result. Search results, ads and copied token metadata are precisely what counterfeit tokens exploit.

Verified identifiers for GramPayBot routes

The addresses below are written directly in this content page. A contract or mint identifies the asset; it is not the merchant’s receiving wallet address.

Route	Contract / mint	Representation	Verify with
USDT · Ethereum	0xdAC17F958D2ee523a2206206994597C13D831ec7	Issuer-native	Tether
USDC · Ethereum	0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48	Issuer-native	Circle
USDT · Optimism	0x94b008aD8e5B9742116e2F419C7830d15B23F2aD	Canonical bridged	Optimism
USDC · Optimism	0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85	Issuer-native	Circle
USDT · BNB Chain	0x55d398326f99059ff775485246999027b3197955	Binance-Peg	BNB Chain
USDC · BNB Chain	0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d	Binance-Peg	BNB Chain
USDT · Base	0xfde4C96c8593536E31F229EA8f37b2ADa2699bb2	Canonical bridged	BaseScan
USDC · Base	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	Issuer-native	Circle
USDT · Polygon	0xc2132D05D31c914a87C6611C10748AEb04B58e8F	Canonical bridged	Polygon
USDC · Polygon	0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359	Issuer-native	Circle
USDT · Arbitrum	0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9	USDT0 omnichain	USDT0
USDC · Arbitrum	0xaf88d065e77c8cC2239327C5EDb3A432268e5831	Issuer-native	Circle
USDT · TRON	TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t	Issuer-native	Tether
USDT · Solana	Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB	Issuer-native	Tether
USDC · Solana	EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v	Issuer-native	Circle

USDC on BNB Chain deserves special attention: the route above is Binance-Peg USDC with 18 decimals, not Circle-issued native USDC. Likewise, USDT on BNB Chain is a Binance-Peg representation. On Arbitrum, the listed USDT contract was upgraded into the USDT0 omnichain system; the old canonical deposit path is deprecated. These distinctions should be visible in a payment integration instead of being hidden behind the ticker.

Where to paste the address

Open the explorer for the chosen network and paste the copied contract or mint into its search field:

Network	Explorer	Expected input
Ethereum	Etherscan	Full 0x... token contract
Optimism	OP Mainnet Etherscan	Full 0x... token contract
BNB Chain	BscScan	Full 0x... BEP-20 contract
Base	BaseScan	Full 0x... token contract
Polygon	PolygonScan	Full 0x... token contract
Arbitrum	Arbiscan	Full 0x... token contract
TRON	TRONSCAN	Full T... TRC-20 contract
Solana	Solana Explorer	Full token mint

The page should resolve to a token contract or token mint, not an ordinary wallet account. Check that the explorer is showing the intended mainnet and that the displayed identifier exactly matches the official source.

What should be visible in the explorer

After the full address matches, review the page as a sanity check:

• the correct network and mainnet;
• a token contract or mint page rather than a normal receiving account;
• the expected name and ticker;
• the expected decimals published for that route;
• established transfer history and a holder base appropriate for a widely used stablecoin;
• a verified-contract or recognized-token label, if the explorer provides one;
• links or metadata that do not contradict the issuer or official registry.

A mature USDT or USDC route will normally have substantial activity. A nearly empty, newly created token claiming to be the main USDT or USDC is a strong warning sign. But “many transactions” is not a minimum that proves authenticity: a scammer can generate thousands of transfers between controlled addresses. Exact address provenance comes first.

Native, bridged and platform-pegged are not interchangeable labels

The same ticker can describe assets with different issuance and bridge assumptions:

• Issuer-native: the issuer publishes the contract or mint for that network. Circle’s native USDC contracts and Tether’s supported native deployments belong here.
• Canonical bridged: the network’s official bridge maps a token from another chain to a representation on this chain.
• Platform-pegged: a platform issues a representation and maintains backing or conversion infrastructure. Binance-Peg USDT and USDC on BNB Chain are examples.
• Issuer-authorized omnichain: the asset uses a cross-chain system authorized with the issuer’s participation, such as USDT0 on Arbitrum.

Do not silently describe every item as “native USDT” or “native USDC.” For a customer, exchange or bridge, support for one representation does not automatically mean support for another.

Contract address is not a payment address

The token contract or mint tells software which asset moved. The receiving wallet address tells the network who receives it. Sending tokens to a contract address instead of your own receiving address can make funds unrecoverable.

In GramPayBot, configure a public wallet address that you control for the selected network. Never provide a private key or seed phrase. The expected token contract is checked separately so payment verification can require the correct asset.

Verify the actual payment too

Confirming token identity is only one part of payment verification. For each payment, also check:

1. successful transaction status;
2. exact recipient address;
3. transferred amount;
4. required confirmation or finality state;
5. one-to-one match with the intended invoice;
6. no reuse of the same transaction for another order.

Use the separate guide on verifying a crypto payment and avoiding fake screenshots for the complete transaction checklist. A valid token sent to the wrong recipient or on the wrong network still does not pay the invoice.

Red flags that should stop automatic crediting

• the address came only from a search result, ad, chat message or social post;
• one character differs from the official contract or mint;
• the explorer is for another network;
• a receiving wallet address is presented as the token contract;
• USDC.e, wrapped USDC or another bridged asset is presented as Circle-native USDC;
• a Binance-Peg token is presented as issuer-native;
• the token has copied branding but little credible history;
• the seller asks you to install an unknown wallet, connect to an unfamiliar site or reveal a seed phrase;
• the transaction transfer event references another contract even though the interface says USDT.

When any of these appears, do not credit the payment automatically. Re-establish the expected network, representation and exact address from the trusted source, then inspect the raw on-chain transfer again.