冻结代币余额：核对账面持有与转账可用性
代币余额回答的是合约账本记着多少单位，不能独自回答某一条转账路径现在能否执行。黑名单可能不减少余额，却同时限制持有者转出、他人向其转入，以及已经获得授权的代花者操作。把所有可见余额都写成可用资产，会把账面持有和路径可用性混为一谈。
研究交付应有三栏：指定状态下的余额、限制状态、经过核对的具体转移路径。读者需要能复现失败原因，而不是仅看到一个“被冻结”的标签。由此也不能直接推出储备不足、法律所有权转移或未来必然解冻；这些判断各有不同证据。
先固定实现，再解释黑名单
本文读取的是二〇二六年十月二十五日访问的Circle公开FiatTokenV1参考实现，固定完整提交为fc85788bc7c23cefe3df1a757133048bfddadeaa。两份文件都与已保存的阅读快照逐字节一致，固定链接使同一源码核验可以复现。下面函数结论仍仅针对该版本源文件，不能冒充每个现网稳定币地址的部署证明。复核时应保存源文件字节和访问日期；核查真实代币，还需记录网络、代币地址、区块哈希、代理对应实现，以及实现源码与运行字节码的对应关系。
在Blacklistable源码中先定位notBlacklisted、isBlacklisted、blacklist及unBlacklist，再进入FiatTokenV1实现，查看内部函数的实际修改及transfer、transferFrom、approve的检查。管理员角色名称说明谁可能改状态，不能替代对转账路径的分析。
在所读实现中，直接转账检查调用者及接收方；代花转账额外把调用者spender、来源from、目的to分别列入黑名单检查；approve也检查授权者和代花者。暂停状态、余额、allowance以及零地址限制仍然是独立前提。因此，黑名单检查通过，只能排除一种阻断原因，不能保证整笔调用必然成功。
固定余额和供应，观察冻结前后
假设一个封闭示例只有两个正余额地址：A持有100单位，B持有50单位，总供应150。合约未暂停，地址非零，期间没有其他转账、铸造或销毁。下文单位是已独立核对decimals后展示的整枚代币，并非把链上原始整数直接当作枚数。
状态S0中两者都未入黑名单。状态S1中有权限的blacklister把A列入名单。所读实现的这一动作修改黑名单状态，不执行burn函数中另行存在的余额及供应扣减。
| 核对项目 | S0 | S1 |
|---|---|---|
| A余额 | 100 | 100 |
| B余额 | 50 | 50 |
| 总供应 | 150 | 150 |
| A被列黑名单 | 否 | 是 |
| B被列黑名单 | 否 | 否 |
因此，“A的100已销毁”与账本不符；“150全部可自由转移”也超过了证据。100除以150等于三分之二，只表示这个特意封闭的地址集合内，被列黑名单地址的账面余额占比。它不是实际全球流通供应调整，也不是赎回损失率，更不能用来推算市场价格影响。
真实核验要保存两个状态的区块标识。若冻结期间另有铸币，总供应可能确实变化，但不能把变化归到冻结动作。若只能取得Blacklisted事件，无法取得对应历史余额，应把事件已观察和余额未验证分开写，不能用当前余额补造历史快照。
分别检查发送、接收和代花者
保持S1的余额不变，另设未被冻结的代花者S已经获得A的20单位allowance。依次分析三条拟转10单位的路径，不实际提交交易。
| 拟议操作 | 黑名单阻断角色 | 被拒后的代币账本 |
|---|---|---|
| A直接向B转出 | 调用者A | A100、B50 |
| B直接向A转入 | 接收方A | A100、B50 |
| S代A转给B | 来源A | A100、B50，allowance20 |
转入路径说明限制并非仅仅“持有者不能签署转出”。代花路径说明，旧批准不覆盖后来的黑名单条件。调用回滚后，不会沿成功转账路径消耗allowance，也不会先送出十单位再只保留失败标记。若现实中提交了失败交易，原生资产执行费仍可能发生，但那是另一种资产的费用，不应塞入这里的代币数量桥。
再从最初干净状态另开一条互斥分支：A、B都未被冻结，只有S入黑名单，A余额100、旧allowance20仍在。此时S调用transferFrom(A,B,10)，会被调用者检查阻挡；来源和目的地都正常，授权金额也足够。只查持有地址及接收地址的工作表会漏掉这一分支。
这些分支用于隔离不同角色，不是一条真实发生的连续交易历史。核验实际失败时，应保存完整calldata、调用者、目标合约、拟转金额及相应历史状态，明确究竟是哪一个谓词阻断了执行，而不是把所有失败笼统写成“余额不足”。
解冻只改变条件，不自动交付
回到S1，假设A之后被解除黑名单，且其他条件仍全部满足。A直接转10给B可以产生A90、B60、总供应150；直接transfer不使用S的allowance。这是解除后某个转账的条件性结果，不能把unBlacklist事件本身当作十单位已到账。
不同机制的边界是暂停。即使A、B、S全都未列黑名单，只要所读函数的暂停条件不满足，转账仍可被拒。allowance不足、实现升级或接收地址不合法也会造成额外阻断。研究记录应写清本次改变了哪个条件，还有哪些条件已核、哪些未知。
链外合同也可能限制一个链上能正常转账的账户。反过来，链上黑名单不能单独证明法院没收、受益所有权转移、法律扣押范围或后续解冻概率。若要判断这些内容，需要独立取得法律文件及权利关系，不能从技术状态直接跳到法律结论。
建立可执行的路径核验表
每条拟转移路线各占一行，不给整个代币贴一个永久“流动”标签。核验顺序如下。
| 步骤 | 必须保留的输入 | 缺失或冲突处理 |
|---|---|---|
| 确定合约 | 网络、地址、区块、代理实现 | 只报告观察到的账面数据 |
| 读取账本 | 原始余额、decimals、供应 | 保留整数，暂不算占比 |
| 读取限制 | caller、from、to的标记及暂停 | 路径可用性列为未解决 |
| 固定操作 | 函数、calldata、spender、数量 | 不从事件名称反推调用 |
| 检查前提 | allowance、余额、地址合法性 | 明列未满足的条件 |
| 核对结果 | 提交状态、余额变化、回滚原因 | 区分失败与缺少证据 |
历史调用或模拟只有绑定正确区块及调用者上下文才有意义。今日模拟成功，不能改写过去的失败；RPC服务报错，也不等于代币合约拒绝。两个提供方结果不同时，先比较区块哈希、代理解析、原始返回数据与调用参数，再判断是否是同一次检验。不要挑选对既定结论有利的一边。
汇总持仓时，应保留完整账面总量，另报定义清楚的受限制子集。不能静默从totalSupply扣掉所有被标记地址：研究人口和转移路线本来就是指标的一部分。一个托管地址可能代表许多客户，一个实际持有者也可能分散在多个地址；地址技术标记没有解决受益归属分配问题。
收尾记录还要规定什么新证据会改变判断：后续区块的解冻、暂停状态变化、调用者纠正、授权更新、实现升级，或有匹配余额变化的已提交转账。新的状态不追溯改写旧快照。准确的表述是“S1记录100，指定路径受阻”，并附日期、路线及证据范围，不能含糊说成资产永久消失。
给不可用路径保留原因编码
路径核验要区分直接读到的状态、推导出的执行结果，以及尚无依据的恢复判断。比如实现及历史调用核实后，“S1中A被列黑名单”是状态观察；“A的指定转账会失败”还依赖函数与调用者；“A永远无法收回100”是另一种声明，前两项并未建立它。
即使余额为零，也要保留角色限制。零余额的S仍可能是代花者，零余额的接收方也可能使转入失败。相反，正余额但标记读取失败的地址应保留未知，不能默认未受限。多个路径汇总时，把已确认阻断、前提不足及服务证据缺失分别计数，否则归档服务中断会被错误解释成冻结规模上升。
还应记录是否真正取得执行证据。只读状态加源码推断、历史模拟、实际提交交易，三者证据强度及观察对象不同。模拟没有改变链上余额，不能填成已交付；交易receipt成功也要检查是否调用了所预期的函数，而不是另一个同地址操作。若代币提供返回false而不回滚的其他实现，则更不能把外层交易成功统一当作代币成功，这也是重新核对部署实现的原因。
复核表可以为每项保存“观察”“条件推导”“待证”三种状态，并附输入。之后归档访问恢复，只解决证据缺口；链上解除黑名单才改变被测状态。这种更新方式使研究能持续追踪，而不会把技术服务恢复错误写成资产解冻，也不会因表格最后一栏变绿就删除原始限制历史。
常见问题
冻结余额是否证明发行人储备不足？
不能。转移限制与发行人支持资产是两项研究任务，本表只核对指定合约状态及操作路径。
已有授权能否绕过黑名单？
所读transferFrom路径仍检查调用者、来源与目的地址。其他实现必须重新检查，不能推广此例。