Detecting USDT and USDC Freezes Before You Credit a Deposit

TL;DR — When Tether or Circle blacklist an address, funds sent to it are stuck and settlement fails. Custody and PSP developers can screen incoming addresses against AML and sanctions data with GET /aml/addresses/{address}, then monitor for frozen-address activity in real time via webhooks. This lets you reject or flag a deposit before it settles, not after.

The problem

Tether and Circle can freeze addresses holding USDT and USDC. The freeze is enforced at the contract level: a blacklisted address cannot send or receive the token. Recent litigation put a number on the exposure. Tether was sued over a $42 million USDT freeze that plaintiffs allege happened before a seizure warrant was issued. The legal question is unsettled. The operational one is not.

Here is the build problem a custody engineer actually hits. A user initiates a USDC withdrawal to an address your platform never checked. The address is blacklisted by Circle. Your outbound transaction reverts, or worse, the deposit path credits a balance you can never move. Support tickets follow. The defense is to screen the counterparty address and the deposit source before you settle, and to watch for freeze events on addresses you already hold.

What you need

• An account and API key. The free crypto api tier works for testing with no credit card.
• The address you want to screen, plus the chain it lives on. USDT and USDC exist on Ethereum, Tron, Solana, and other networks, so your screening must be chain-aware.
• A public HTTPS endpoint to receive webhook callbacks. This is the part teams underestimate. You need signature verification, idempotency, and retry handling before you go to production.
• A settlement pipeline that can hold a deposit in a pending state until screening returns. If you credit optimistically, screening buys you nothing.

Address screening across chains is not a single lookup. USDC on Ethereum and USDC on Solana are different contracts with different blacklists. Our guide to screening across 17 chains covers the per-chain nuance.

How it works

Screening runs in two layers. First, a synchronous AML check on the address before you accept or send funds. Second, an asynchronous webhook subscription so you learn when a held address starts moving or gets flagged.

The AML check is a single call. Screen the address before crediting a deposit or approving a withdrawal:

GET https://rest.cryptoapis.io/aml/addresses/0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B
Header: x-api-key: YOUR_API_KEY

The response carries a risk assessment for the address. Use it as a gate: a clean result lets the deposit proceed to settlement, a flagged result holds it for manual review. If you are screening a specific transaction rather than an address, use GET /aml/transactions/{blockchain}/{transactionHash} to assess the transfer itself.

The synchronous check tells you the state at request time. It does not tell you when an address you already hold gets blacklisted later. That is what blockchain events are for. Subscribe to token transaction activity on the addresses in your custody set:

POST https://rest.cryptoapis.io/blockchain-events/ethereum/mainnet/address-tokens-transactions-confirmed
Header: x-api-key: YOUR_API_KEY
Content-Type: application/json

{
  "data": {
    "item": {
      "address": "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B",
      "callbackUrl": "https://your-domain.com/webhooks/token-activity"
    }
  }
}

When a confirmed token transaction touches that address, you receive a callback. Webhook delivery targets sub-100ms response times, so your compliance state stays close to on-chain reality. Pair the event with a fresh AML lookup on the counterparty to decide whether to hold or release. For a fuller pattern, see our developer guide to monitoring addresses with webhooks.

To surface freeze status to users before settlement fails, run the AML check at withdrawal-request time and again at broadcast time. If the destination is flagged between those two points, block the broadcast and show the user a clear reason rather than letting the transaction revert on-chain.

What to watch for

A few failure modes matter in production.

• Chain mismatch. Screening an Ethereum address when the deposit arrives on Tron gives you a false sense of safety. Always pass the correct {blockchain} and {network} and screen the address on the chain the funds actually move on.
• Timing gaps. A blacklist can land between your screen and your broadcast. Re-screen at broadcast time for high-value transfers. The cost of an extra call is trivial next to a stuck balance.
• Webhook reliability. Callbacks can arrive more than once and can be delayed if your endpoint is slow. Make handlers idempotent, respond fast, and process asynchronously. Verify the payload before acting on it.
• Optimistic crediting. If your ledger credits a deposit before screening completes, screening is decorative. Hold deposits in pending until the AML gate returns.
• Sanctions overlap. A stablecoin freeze and an OFAC sanctions listing are different signals with different obligations. Treat AML risk scoring as input to your compliance policy, not as the policy itself.

Privacy features on newer chains also widen the gap. Shielded transfers can obscure the counterparty you would otherwise screen, as we covered in our note on the Starknet STRK20 privacy layer.

Screening frozen stablecoin addresses before settlement is a solved engineering problem, not a legal one you have to wait out. Combine Verify Address AML screening at the decision points with Blockchain Events for continuous monitoring, and you catch a USDT or USDC freeze before it becomes a support ticket. Start on the free tier and build the gate into your deposit and withdrawal paths.