The USDT blacklist, explained
USDT is issued by a company, and the company keeps a switch in its token contract: any address can be frozen. For a business paying out USDT in volume the blacklist is not trivia — it is a per-recipient risk that costs real money when ignored. Here is how it works and how to screen for it.
What the blacklist is
The USDT contract on TRON gives its issuer, Tether, the power to blacklist addresses. A blacklisted address is frozen in the token: the USDT it holds cannot be moved, and transfers involving it do not go through. The freeze applies at the token level only — the address can still hold and move TRX; it is USDT that stops.
Every freeze is an on-chain transaction, so the list is public by construction: anyone can check any address at any moment. What is not public in advance is timing — an address is fine until the moment it is not.
How addresses end up on it
Tether freezes addresses in response to law-enforcement requests and court orders, for sanctions exposure, and around the movement of funds from hacks and scams. A freeze is not a court verdict — mistakes and collateral freezes happen — but for the person about to send money to such an address, the practical conclusion is the same: the transfer cannot arrive.
What a payment to a frozen address costs
The transfer fails on-chain. What you spend on it does not come back: the energy — or the burned TRX — pays for the attempt, not for the outcome.
In a batch the damage multiplies quietly: one frozen recipient among five hundred is invisible to the eye, fails on its own, and — if your pipeline retries failures — keeps failing at full price. Screening before sending is not compliance theatre; it is cheaper, every single time.
How to screen before a single TRX is spent
This service checks recipients as part of its normal flow, and you can also ask directly:
curl "https://api.nrg.market/v1/address-check?address=TN3W4H6rK2ce4vX9YnFQHwKENnHjoxb3m9" \
-H "Authorization: Bearer $KEY"
{"activated": true, "holds_usdt": true, "blacklisted": false, "is_contract": false}
blacklisted is the freeze itself, read from the chain. The other three fields answer neighbouring questions that decide what a transfer will cost: activated — whether the address exists on-chain at all; holds_usdt — whether the recipient already has a token account (if not, the transfer needs about twice the energy); is_contract — the recipient is a smart contract, whose energy appetite is its own.
A cost estimate (POST /v1/estimate, up to 500 recipients at a time) marks every problem recipient in one pass — blacklisted, inactive_recipient, contract_recipient — without reserving or spending anything. An order that names a blacklisted recipient is refused outright, with the error blacklisted_recipient, before any money moves: a transfer that cannot arrive is not a service worth selling.
Sanctions lists are a separate and wider matter than the token blacklist; how prohibited destinations are handled here is set out in the Acceptable Use Policy.
Questions we actually get
Can a frozen address be unfrozen?
Yes — the same switch works in both directions, and Tether has used it that way. It is entirely the issuer's decision, and reversals are the exception rather than something to plan for.
Does the blacklist affect TRX or other tokens?
No. The freeze lives inside the USDT contract and reaches only USDT. The address keeps sending and receiving TRX and other tokens normally.
Is there an official list to download?
The state lives on-chain, and every freeze is a public transaction. In practice you query it per address at the moment of sending — that is what GET /v1/address-check does — rather than downloading a snapshot that starts ageing immediately.
We sent to an address that was frozen later. Is our transfer at risk?
A completed transfer is history and does not unhappen. The freeze stops the address from moving funds from that moment on — which is exactly why recipients are screened at the moment of sending, not once a year.