Anatomy of a USDT blacklist: how Tether freezes tokens

Tether has the technical ability to block USDT held at any blockchain address. After such a block, the address owner can no longer transfer USDT, even though it continues to appear in the balance.

Since 2017 Tether has initiated blacklisting of approximately 8,000 blockchain addresses with a combined value of more than $4 billion.

Against the overall scale of USDT circulation, these numbers may seem small. But for an individual market participant, a blacklist becomes a critical event — especially when they're confident they did nothing illegal. Such cases are not as rare as they might seem. The fact that some addresses are later unblocked confirms that individual decisions were sometimes made based on incorrect conclusions by the initiator.

Blacklisting doesn't happen arbitrarily — there must be grounds, and the procedure has both a legal and an operational side. We cover those aspects in a separate article about who actually makes the call. The goal of this article is to explain the technical mechanics of USDT blacklisting.

How a regular USDT transfer works

To understand the blocking process, we first need to understand how a regular USDT transfer technically happens.

Consider an example of a USDT transaction on the TRON network. The user initiates a transfer of USDT from their address to a recipient's address. At that moment, the transaction interacts with the USDT smart contract on TRON:

TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

The smart contract is what handles balance accounting and token transfer processing. When a transfer is executed, the contract's internal token-transfer logic is invoked. At the contract's event level, this is recorded as a Transfer event — that is, the movement of an asset from sender to recipient.

Simplified, the process looks like this:

1. The user initiates a USDT transfer;
2. The transaction calls the USDT smart contract;
3. The contract verifies transfer conditions;
4. If there are no restrictions, the sender's balance decreases and the recipient's balance increases;
5. A Transfer event is recorded on-chain.

USDT on Ethereum works similarly: a transfer is processed through the token's smart contract, and a successful transfer is recorded as a Transfer event. The main differences between TRON and Ethereum come from the technical environment: token standard, address format, fees, transaction processing speed.

Control mechanisms in the USDT smart contract

In addition to regular transfers, the USDT smart contract has administrative functions that let the issuer manage how the token circulates for specific addresses. The issuer can add an address to the blacklist, remove it from the blacklist, and burn USDT held at a blacklisted address.

These actions are reflected through contract events. For analyzing blacklisting, three events are key:

• AddedBlackList — adding an address to the blacklist;
• RemovedBlackList — removing an address from the blacklist;
• DestroyedBlackFunds — burning funds at a blacklisted address.

Simplified, the logic looks like this:

1. Tether adds an address to BlackList;
2. The smart contract starts recognizing this address as blacklisted;
3. When an outgoing transfer is attempted, the contract checks the address status;
4. If the address is in BlackList, the transfer is rejected;
5. If the address is not in BlackList, the transfer can proceed.

From preban to ban: how blacklisting appears on-chain

USDT blacklisting on TRON is recorded not as one but as two related on-chain stages: first, an operation is created in Tether's MultisigWallet; then that operation is executed and results in the address being added to BlackList.

This sequence can be conditionally split into two events:

1. Preban — creation of the operation in Tether's MultisigWallet.
2. Ban — actual execution of the operation, after which the address enters BlackList.

Preban: creating the operation in Tether's MultisigWallet

In the preban stage, a method on the multisig contract is called. In this transaction, the address is not yet actually blacklisted — it just creates an operation that the multisig must execute after the required confirmation.

Key parameters of a preban transaction:

In event logs of the preban transaction, the multisig contract's events are recorded. TransactionId is the internal identifier of the operation in Tether's MultisigWallet that will be executed later.

Where the address-to-be-blacklisted is hidden

The address that will be blacklisted is not displayed directly in the event logs of the preban transaction. It is hidden inside the Data parameter, which must be decoded according to Solidity ABI rules.

If the operation is preparing a call to a blacklist function, the data structure looks like this:

0xecb93c0 + 32-byte address argument
(<function selector> + <ABI-encoded arguments>)

The first 4 bytes are the function selector. The rest is the ABI-encoded argument. To extract the address, take the last 20 bytes of the argument and decode them.

In TRON, addresses can be displayed in two forms:

• Hex format — starts with the 41 prefix;
• Base58Check format — human-readable, starts with T.

Ban: actually adding the address to BlackList

The actual blacklist happens later, when the created multisig operation is executed. In the ban transaction, the USDT contract logs show:

AddedBlackList(address target)

This event is the on-chain confirmation that the address has been added to BlackList.

The window of opportunity: time from preban to ban

Between preban and ban there is a time gap. Before the AddedBlackList event appears, the address is not yet in BlackList and technically retains the ability to use USDT. This gap is what we call the window of opportunity.

The window used to be days. Now it has shortened noticeably — sometimes hours, sometimes minutes. This reduces predictability for the address owner and makes rapid response critical.

Before the AddedBlackList event, the address can still perform outgoing USDT transfers. So, from the perspective of a bona-fide user who sees a risk of impending blacklist, the rational sequence of actions is: first move funds out of the potentially blocked address, then deal with the reasons for the block.

What happens after the actual ban

After blacklisting, the address can no longer send USDT. Outgoing transfers are rejected by smart-contract logic. The funds will continue to appear in the balance, and incoming transfers can technically arrive at the address.

What happens next depends on the grounds for blacklisting:

• The address may remain in BlackList indefinitely;
• The address may be unblocked via RemovedBlackList;
• Funds may be burned via DestroyedBlackFunds, with possible re-issuance to a new address.

After the actual ban, work shifts to the legal and analytical track: identifying the source of risk, preparing on-chain analytics, confirming the origin of funds, and communicating with Tether and the state structures that initiated the blacklist — with relevant legal counsel involved.

How to tell that your address has been blacklisted by Tether

Users often don't notice the blacklist immediately. At first glance everything looks normal: USDT is shown in the balance, the network is working, the address is correct, incoming transfers credit successfully. But when trying to send USDT, the transaction fails.

Other operations on the address may continue to work normally. For example, the user may successfully send TRX or other tokens, while the problem appears only with outgoing USDT transfers. This is an important sign: Tether's blacklist applies at the USDT smart-contract level, not to the entire address on the TRON network.

Outgoing USDT transfers fail, while other operations (sending native tokens, receiving incoming funds) work normally.

— The main sign of blacklisting

If the address is in Tether's BlackList, the USDT smart contract rejects the outgoing transfer attempt. In the wallet, this may appear as a send error, and in the block explorer the transaction may show with Failed status.

It's important to distinguish blacklisting from ordinary technical issues:

• Insufficient native token (TRX, ETH) to pay fees;
• The wallet not sending the transaction (UI, RPC, or wallet bug);
• Network congestion or temporary infrastructure outages.

How to check for blacklisting via the USDT smart contract

Step 1. Open the USDT smart contract on TRON in Tronscan: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

Step 2. Go to the Contract tab.

Step 3. Open the Read Contract section.

Step 4. Find the getBlackListStatus method. In Tronscan it may appear as «8. getBlackListStatus (59bf1abe)».

Step 5. Enter the address you want to check and execute the query.

Manual checking via Tronscan is fine for a one-off verification. For rapid response, it's better to use automated monitoring: it can track BlackList additions via the AddedBlackList event and — when the functionality is available — surface signs of impending blacklisting before the actual AddedBlackList event.

How to monitor USDT blacklist activity in real time

Every event — preban, ban, unban, destroy — is recorded publicly on-chain. This means anyone can build monitoring:

• Direct approach — run a TRON and Ethereum archive node, subscribe to USDT contract event logs via WebSocket. Cheapest in cost, requires infrastructure.
• Through third-party services — QuickNode Streams, Alchemy webhooks, Infura. Paid, but no own infra.
• Through a ready product — we do this in real time since 2017: Telegram alert feed, REST API, MCP server for AI tools, HuggingFace dataset for researchers.

Further reading

• Who actually decides on a USDT blacklist — about the sources of blacklists: law-enforcement, sanctions, Tether's internal risk assessment.
• Mass unban on 14 May 2026 — 497 addresses in 72 minutes — a practical case of a rare event, broken down from on-chain data.