2026-10-26

Can USDC Be Frozen? What Issuer Blacklists Mean for Crypto Payouts

Yes. USDC can be frozen, and so can USDT. Both issuers can restrict an address on-chain, usually because of a court order, a sanctions listing or a request from law enforcement. Once that happens, the token contract itself refuses the transfer. No wallet, app or payment provider can get around it.

Most people learn this as trivia. If you move money for other people, it's an operational problem. A payment can land correctly and still get stuck on the way out, because one of the addresses it's supposed to reach can't receive it.

What each token actually blocks

The two big stablecoins don't freeze the same way, and the difference matters.

Token Issuer function Restricted address can receive? Restricted address can send?
USDC isBlacklisted No No
USDT on Ethereum isBlackListed Yes No
USDT0 on Polygon, Arbitrum, Avalanche isBlocked Yes No

USDC checks both sides of every transfer. If either the sender or the recipient is blacklisted, the transfer reverts.

USDT only checks the sender. A transfer to a blacklisted USDT address goes through, and the money then sits there until Tether lifts the restriction. We verified that by simulation on Ethereum mainnet rather than taking it on faith.

Some pairs have no public function to ask at all: USDT on Base and Optimism, and both tokens on BNB Chain. The issuer can still freeze addresses there. You just can't see it ahead of time.

Why one frozen address can stall a whole payment

Every Klap charge pays out through its own split contract (here's why), escrow charges included once their funds are released, and that contract pays everyone in the split at once: the merchant, any extra recipients, and the platform fee.

That "at once" is the catch. A 0xSplits push split sends each recipient their share with a plain token transfer inside one transaction. If the token refuses any single one of those transfers, the whole distribution reverts. One frozen USDC recipient means nobody in that split gets paid, not just them.

So the useful question isn't "is this address frozen?" in the abstract. It's "will every address this payment has to reach be able to receive it, on this token, on this network?"

What Klap checks, and when

We read the token contract's own status, and nothing else. Klap keeps no blocklist of its own and uses no third-party sanctions oracle. If the chain would refuse a transfer, we refuse it early. If the chain wouldn't, we don't.

When a charge is created, Klap checks that every address the charge pays (your payout address, each split recipient and Klap's fee treasury) can receive on every accepted token and network. If one can't, the API answers with a 422 and names only the pairs that are affected:

{
  "error": {
    "code": "recipient_transfer_restricted",
    "message": "The token issuer restricts transfers to your payout address for USDC on base. Remove the affected pairs from acceptedPayments and try again.",
    "param": "acceptedPayments"
  }
}

Drop those pairs from acceptedPayments and retry. A payout address restricted on USDC can usually still be paid in USDT, because USDT never checks who receives.

When a payment is made, nothing is checked. Klap never screens the payer. If the payer's own address is frozen, their wallet's transfer fails on-chain and the charge simply stays unpaid.

When the payout runs, Klap checks again: the split must be able to send and every recipient must be able to receive. If an address got frozen after the charge was created, the payout is held instead of failed. The funds stay in the charge's split contract, the charge keeps its status with settlementStatus: pending, no webhook goes out, and Klap checks again every hour. If the issuer lifts the restriction, the payout goes through normally. Nothing burns through a retry budget and ends up marked as failed.

Any time you want, GET /v1/recipients/{id}/transferability reports receive and send for each token and network, so you can warn the address's owner before a charge ever fails.

When we can't tell

Each check reads the token contract live, with a one-second limit. If the read fails, times out or there's no function to ask, the result is unknown, and unknown never blocks a charge or a payout. A slow RPC shouldn't stop your business because of a risk we can't confirm.

Results are only held in memory: a definite answer for up to five minutes, an unknown for thirty seconds. So when an issuer changes an address's status, it can take that long for Klap to see it.

What to do as an integrator

  • Check a recipient's transferability when you register it, not only when a charge fails.
  • On recipient_transfer_restricted, offer the payer the pairs that are still open.
  • If a restricted address belongs to someone you work with, ask them for another one. Only the issuer can lift a freeze. Klap can't, and neither can anyone else.
  • A paid charge that gets no charge.settled for hours may be a held payout. Contact support with the charge id.

Freezes are rare. But "rare" plus "every payout is a single all-or-nothing transaction" is exactly the combination you want handled before money moves, not after.

The full reference, including every token and network we check, is on the token restrictions docs page.