Official USDT and USDC contract addresses — and how to verify a deposit is the real token

The canonical contracts

Nine contracts across seven chains: USDT (Tether) on Ethereum, Tron and Avalanche; USDC (Circle) on Ethereum, Base, Arbitrum, Polygon, Avalanche and OP Mainnet.

These addresses come from the issuers' official publications and are configured in the product, never taken from user input. A change to this list is a code change, reviewed like any other. If an address here ever disagrees with the issuer's own page, the issuer's page wins — tell us.

How to verify a deposit is the real token

Read the transaction receipt and require a Transfer log emitted by the canonical contract, to your address, for the expected amount.

A stablecoin transfer is not a native coin movement; it is a contract call that emits a Transfer(from, to, value) event log. The log's emitting address is the token contract. A deposit is the real token only if that emitting address equals the canonical contract for that chain — not if the symbol matches, not if the name matches, and not if the explorer paints a logo on it.

KYTGate's transaction integrity check does exactly this for kind: "transfer" subjects: it fetches the receipt, confirms the transaction exists and succeeded, waits for the confirmation depth, finds the Transfer log emitted by the canonical contract, checks the recipient is yours and the amount is what the webhook claimed, and takes the log's from — not the transaction signer — as the address to screen. Any of these failing makes the transactionIntegrity coverage dimension fail and the decision REVIEW; it is never a credit.

Receipt log that passes integrity (Ethereum USDT)
  address: 0xdAC17F958D2ee523a2206206994597C13D831ec7   ← must equal the canonical contract
  topics[0]: Transfer(address,address,uint256)
  topics[1]: from  → the address that gets screened
  topics[2]: to    → must be your deposit address
  data:      value → must match the claimed amount (6 decimals)

If you verify by hand: open the transaction on the explorer, go to the logs tab, and compare the log's address field character by character with the table above. Do not trust the token name column.

Common fake-token tricks

Same symbol, near-identical address, a real transfer of a worthless token, or a zero-value transfer from a look-alike sender.

• Same symbol, different contract. The simplest one: a token named "USDT" or "Tether USD" with 6 decimals, transferred to your deposit address. Every field except the contract address looks right.
• Address poisoning. The attacker sends dust from an address whose first and last characters match a legitimate counterparty, hoping a reviewer or an ops script copies it from history. Screening the log's from in full, not its abbreviation, defeats it.
• Real contract, wrong chain. Ethereum USDT's address is meaningless on another chain; a token deployed at the "same" address elsewhere is unrelated. Verification is per chain.
• Edited webhook. The transfer is real and canonical, but the amount or recipient in the notification was changed in transit, or the same hash is submitted twice. Integrity compares the chain to the claim, and the idempotency key stops the second credit.
• Transaction signer as sender. The transaction was sent by a contract or a relayer; the token actually came from another address inside it. Screening the signer screens the wrong party. The token log's from is what KYTGate screens.

Chains deliberately not covered

BNB Chain's Binance-Peg USDT/USDC have no issuer blacklist function; Solana has no comparable read in the current connector.

BNB Chain (BSC) is absent on purpose. The "USDT" and "USDC" there are Binance-Peg tokens issued by Binance, not by Tether or Circle, and their contracts expose no blacklist function. Pretending to read a freeze that does not exist would be a false sense of coverage, so on BSC the issuerFreeze dimension reports UNSUPPORTED and no read is made. The same reasoning applies to bridged variants on any chain.

Solana is screened for sanctions but has no issuer-freeze read in the current connector; the coverage matrix says so per screening rather than implying otherwise. Bitcoin has no stablecoins to read. The rule throughout is the same: the product reports what it actually checked, per dimension, and a NO_ADVERSE_SIGNAL on a dimension that did not run is not a result.

Questions

Read more

• GateCoverage — the coverage matrix explained
• Decision Receipt verifier
• Methodology — how sources are read and matched
• All guides