USDT 黑名单剖析：Tether 如何冻结代币

Tether 拥有冻结存放在任何区块链地址上的 USDT 的技术能力。在此类冻结之后，地址所有者将无法再转移 USDT，尽管它仍会显示在余额中。

自 2017 年以来，Tether 已对大约 8,000 个区块链地址 发起黑名单操作，涉及金额合计超过 40 亿美元。

相对于 USDT 流通的整体规模，这些数字看起来或许很小。但对于单个市场参与者而言，黑名单会成为一个关键事件——尤其是当他们确信自己没有做任何违法之事时。此类情形并不像看起来那样罕见。部分地址后来被解封的事实证明，个别决定有时是基于发起方的错误结论作出的。

黑名单不会随意发生——必须存在依据，且该程序既有法律层面也有操作层面。我们在一篇专门讨论究竟由谁作出决定的文章中涵盖了这些方面。本文的目的是解释 USDT 黑名单的技术机制。

一笔普通的 USDT 转账如何运作

要理解冻结过程，我们首先需要理解一笔普通的 USDT 转账在技术上是如何发生的。

以 TRON 网络上的一笔 USDT 交易为例。用户从自己的地址向接收方地址发起一笔 USDT 转账。在那一刻，该交易与 TRON 上的 USDT 智能合约进行交互：

TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

智能合约负责处理余额记账和代币转账处理。当执行一笔转账时，合约内部的代币转账逻辑被调用。在合约的事件层面，这被记录为一个 Transfer 事件——即资产从发送方到接收方的移动。

简化来看，这个过程如下：

1. 用户发起一笔 USDT 转账；
2. 交易调用 USDT 智能合约；
3. 合约验证转账条件；
4. 如果没有限制，发送方余额减少，接收方余额增加；
5. 一个 Transfer 事件被记录在链上。

Ethereum 上的 USDT 运作方式类似：转账通过代币的智能合约处理，成功的转账被记录为一个 Transfer 事件。TRON 与 Ethereum 之间的主要差异来自技术环境：代币标准、地址格式、手续费、交易处理速度。

USDT 智能合约中的控制机制

除了普通转账外，USDT 智能合约还具有管理功能，使发行方能够管理特定地址的代币流通方式。发行方可以将地址加入黑名单、将其从黑名单中移除，以及销毁存放在被列入黑名单地址上的 USDT。

这些操作通过合约事件反映出来。对于分析黑名单，三个事件是关键：

• AddedBlackList — 将地址加入黑名单；
• RemovedBlackList — 将地址从黑名单中移除；
• DestroyedBlackFunds — 销毁被列入黑名单地址上的资金。

简化来看，其逻辑如下：

1. Tether 将地址加入 BlackList；
2. 智能合约开始将此地址识别为已被列入黑名单；
3. 当尝试转出时，合约检查地址状态；
4. 如果地址在 BlackList 中，转账被拒绝；
5. 如果地址不在 BlackList 中，转账可以进行。

从 preban 到 ban：黑名单如何在链上出现

TRON 上的 USDT 黑名单不是作为一个事件，而是作为两个相关的链上阶段被记录的：首先，在 Tether 的 MultisigWallet 中创建一项操作；然后该操作被执行，导致地址被加入 BlackList。

这个序列可以有条件地分为两个事件：

1. Preban — 在 Tether 的 MultisigWallet 中创建操作。
2. Ban — 实际执行操作，之后地址进入 BlackList。

Preban：在 Tether 的 MultisigWallet 中创建操作

在 preban 阶段，multisig 合约上的一个方法被调用。在这笔交易中，地址实际上尚未被列入黑名单——它只是创建了一项操作，multisig 必须在获得所需确认后执行该操作。

preban 交易的关键参数：

在 preban 交易的事件日志中，记录了 multisig 合约的事件。TransactionId 是 Tether 的 MultisigWallet 中稍后将被执行的操作的内部标识符。

待列入黑名单的地址隐藏在何处

将被列入黑名单的地址不会直接显示在 preban 交易的事件日志中。它隐藏在 Data 参数内部，必须根据 Solidity ABI 规则进行解码。

如果该操作正在准备对一个 blacklist 函数的调用，数据结构如下所示：

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

前 4 个字节是函数选择器。其余是 ABI 编码的参数。要提取地址，取参数的最后 20 个字节并对其解码。

在 TRON 中，地址可以以两种形式显示：

• Hex 格式 — 以 41 前缀开头；
• Base58Check 格式 — 人类可读，以 T 开头。

Ban：实际将地址加入 BlackList

实际的黑名单发生在稍后，当已创建的 multisig 操作被执行时。在 ban 交易中，USDT 合约日志显示：

AddedBlackList(address target)

这个事件是地址已被加入 BlackList 的链上确认。

机会窗口：从 preban 到 ban 的时间

在 preban 与 ban 之间存在一段时间间隔。在 AddedBlackList 事件出现之前，地址尚未进入 BlackList，且在技术上保留使用 USDT 的能力。这段间隔正是我们所称的机会窗口。

这个窗口曾经是数天。如今它已明显缩短——有时是数小时，有时是数分钟。这降低了地址所有者的可预测性，并使得快速反应至关重要。

在 AddedBlackList 事件之前，地址仍可执行 USDT 转出。因此，从一个看到即将到来的黑名单风险的善意用户的角度来看，合理的行动顺序是：先转出资金，将其移出可能被冻结的地址，然后处理被冻结的原因。

实际 ban 之后会发生什么

被列入黑名单后，地址将无法再发送 USDT。转出的转账被智能合约逻辑拒绝。资金将继续显示在余额中，且转入的转账在技术上仍可到达该地址。

接下来会发生什么取决于列入黑名单的依据：

• 地址可能无限期留在 BlackList 中；
• 地址可能通过 RemovedBlackList 被解封；
• 资金可能通过 DestroyedBlackFunds 被销毁，并可能重新发行到一个新地址。

在实际 ban 之后，工作转向法律与分析轨道：识别风险来源、准备链上分析、确认资金来源，以及与 Tether 和发起黑名单的国家机构沟通——需有相关法律顾问参与。

如何判断你的地址已被 Tether 列入黑名单

用户往往不会立即注意到黑名单。乍一看一切正常：USDT 显示在余额中，网络正常，地址正确，转入的转账成功入账。但在尝试发送 USDT 时，交易失败。

地址上的其他操作可能继续正常运作。例如，用户可能成功发送 TRX 或其他代币，而问题只出现在 USDT 转出上。这是一个重要迹象：Tether 的黑名单在 USDT 智能合约层面生效，而非针对 TRON 网络上的整个地址。

USDT 转出失败，而其他操作（发送原生代币、接收转入资金） 正常运作。

— 黑名单的主要迹象

如果地址在 Tether 的 BlackList 中，USDT 智能合约会拒绝转出尝试。在钱包中，这可能表现为发送错误，而在区块浏览器中，交易可能以 Failed 状态显示。

区分黑名单与普通技术问题很重要：

• 原生代币（TRX、ETH）不足以支付手续费；
• 钱包未发送交易（UI、RPC 或钱包的 bug）；
• 网络拥堵或临时的基础设施中断。

如何通过 USDT 智能合约查询黑名单状态

步骤 1。 在 Tronscan 中打开 TRON 上的 USDT 智能合约：TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

步骤 2。 前往 Contract 标签页。

步骤 3。 打开 Read Contract 部分。

步骤 4。 找到 getBlackListStatus 方法。在 Tronscan 中它可能显示为 「8. getBlackListStatus (59bf1abe)」。

步骤 5。 输入你想查询的地址并执行查询。

通过 Tronscan 手动查询适用于一次性验证。为了快速反应，最好使用自动化监控：它可以通过 AddedBlackList 事件追踪 BlackList 的添加，并且——在功能可用时——在实际的 AddedBlackList 事件之前呈现即将到来的黑名单迹象。

如何实时监控 USDT 黑名单活动

每一个事件——preban、ban、unban、destroy——都被公开记录在链上。这意味着任何人都可以构建监控：

• 直接方式 — 运行一个 TRON 和 Ethereum archive node，通过 WebSocket 订阅 USDT 合约的事件日志。成本最低，但需要基础设施。
• 通过第三方服务 — QuickNode Streams、Alchemy webhooks、Infura。付费，但无需自有基础设施。
• 通过现成产品 — 我们自 2017 年以来实时做这件事：Telegram 警报数据源、REST API、面向 AI 工具的 MCP 服务器，以及面向研究人员的 HuggingFace 数据集。

延伸阅读

• 究竟由谁决定 USDT 黑名单 — 关于黑名单的来源：执法机构、制裁、Tether 的内部风险评估。
• 2026 年 5 月 14 日的大规模 unban——72 分钟内 497 个地址 — 一个罕见事件的实用案例，依据链上数据进行拆解。