Official USDT and USDC contract addresses by chain

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 differs from the issuer's own page, the issuer's page takes precedence. Please 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 a contract call, not a native coin movement. It emits a Transfer(from, to, value) event log, and 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. A matching symbol, name or explorer logo does not count.

KYTGate's transaction integrity check does this for kind: "transfer" subjects. It fetches the receipt and confirms the transaction exists and succeeded. Until the confirmation depth is reached it answers "too early" (HTTP 425) and stores nothing. It then looks for a Transfer log emitted by the canonical contract and screens that log's from address rather than the transaction signer. If you pass your deposit address as toAddress, that is the sender who paid it. Otherwise it is the only sender, when there is exactly one. The check does not compare the amount with what a webhook claimed. That is the job of reconciliation (POST /api/v1/reconcile). A missing or reverted transaction is a finding that sends the decision to review. If the check could not run, or the sender cannot be singled out, the decision is TECHNICAL_HOLD. Neither outcome is ever 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 → compare with the claimed amount in reconciliation (6 decimals)

To 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. Ignore 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 version is a token named "USDT" or "Tether USD" with 6 decimals, sent 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 full from address, rather than a shortened form, defeats it.
• Real contract, wrong chain. Ethereum USDT's address means nothing 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. Reconciliation 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, and the token came from another address inside it. Screening the signer screens the wrong party. The token log's from is what KYTGate screens.

Chains 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 left out 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. Reporting a freeze read that cannot exist would give a false sense of coverage. On BSC the issuerFreeze dimension therefore reports UNSUPPORTED and no read is made. The same applies to bridged variants on any chain.

Solana is screened for sanctions but has no issuer-freeze read in the current connector, and the coverage matrix states this on each screening. Bitcoin has no stablecoins to read. On every chain the product reports what it checked, dimension by dimension. 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
• Why is my USDT frozen? What a broker must do
• Wallet ownership verification for withdrawals
• Crypto deposit compliance checklist for MLROs
• How to use the OFAC crypto address list
• The crypto Travel Rule for brokers
• All guides