代币转账前先问一圈校验方：ERC-902 的 check 接口与状态码事件

受监管资产上链绕不开一个问题：谁能持有、谁能转。常见做法是每张代币自己维护一张白名单，改名单要动合约、名单数据也各锁各的。ERC-902 给出另一种思路：把“这笔交易行不行”外包给独立的校验方合约，代币在转账前后去问一句。它的文件头记录创建于 2018 年 2 月 14 日，仓库记录状态为 Stagnant，声明依赖 ERC-1066 状态码标准。

两个 check 函数

校验方接口 TokenValidator 只有两个方法。check(address _token, address _subject) 面向一般性检查——传入代币合约和某个用户或合约，返回一个字节的状态码，适合“这个人能不能持币”这类问题。check(address _token, address _from, address _to, uint256 _amount) 面向转账场景——多给了转出方、转入方和数量，适合判断“这次转移允不允许”，比如按额度、按时间窗口的规则。状态码的解释走 ERC-1066 那套十六进制口径，具体哪些码算通过，由实现约定。

值得注意的是，两个函数接收 _token 参数而不是依赖调用上下文。取舍部分解释了原因：校验方可能被别的校验方聚合或委托调用，msg.sender 未必是需要讨论的那张代币，所以代币身份必须显式传入。

事件由谁来发：一个反直觉的规定

代币侧的接口 ValidatedToken 只定义事件，不定义函数。两个事件与两个 check 对应：两参数版 Validation(address indexed subject, byte indexed result) 在校验方从 check 两参数版返回时必须发出；四参数版带上 from、to、amount 和状态码，在四参数版返回时必须发出。

关键在发出者：规范要求事件由调用方代币发出，而不是校验方。理由写在取舍里——校验方链条可能层层委托，如果每层都发事件，链上会被大量无意义事件淹没；由发起转账的代币统一记录一次“我查过、结果如何”，账本干净得多。这也意味着链上审计这条转账时，看的是代币合约的 Validation 日志，而不是校验方合约的。

不设中心化注册表

设计者明确留下了几项“不做”：校验方地址公开、私有还是硬编码，由实现者自己定；标准不包含中心化的校验方注册表；也不定义一套通用的“被校验代币”完整接口——一张币可以要求一个或多个校验方、分别做不同用途的校验，场景差别太大，统一接口反而绑手脚。正文给了示例：把 approve 也接上 check 的四参数版，授权动作同样先过校验。

这套“只管问、不管谁来答”的取舍，让 ERC-902 与 ERC-20、ERC-721 等标准在文字层面互不冲突——正文说它只定义校验检查这一小块，因此可以叠加在多种代币标准上。

读资产“准入规则”时的实用推论

对普通用户，这类机制的体感是：向某个受监管代币地址转账可能被拒，而拒绝原因不在代币转账说明里，需要理解“代币只是去问了校验方”。对尽调的人，可执行的核对清单是：确认代币合约里 check 调用的是哪个地址；那个校验方地址是否公开可查、归谁管理；它背后是链上名单还是链下合规服务；换校验方需不需要持有人同意。同一份 ERC-902 接口下，这些答案可以完全不同——接口标准保证的是“问法统一”，保证不了“答案宽松”。

与相邻机制的区分

校验检查和黑名单、许可制转账经常被混为一谈，边界值得写清楚。第一种混淆是把校验方当黑名单：校验函数的输入里根本没有名单字段，规则完全在实现方手里，可能查的是链上名单，也可能是链下签名凭证，甚至是一个时间点判断。第二种混淆是把状态码当错误原因：ERC-1066 的十六进制口径只保证“码可枚举”，不保证跨项目同码同义。第三种是把事件当放行证明：Validation 事件记录的是校验发生过、结果码是什么，如果代币实现先转账后发事件，事件里的码与用户实际损失可能对不上——顺序约定因此是读这类合约时的必查项。三种混淆的共同解法都一样：顺着一笔真实交易的日志，把代币、校验方、事件顺序完整走一遍，比读任何项目方说明都可靠。

也要提醒状态口径：状态码的含义标准本身留白，正文说具体码表后续再定。看到“返回码 0x12 表示拒绝”这类说法时，应当回到该代币或校验方的文档核对码表，而不是跨项目套用。本文为机制说明，不构成任何投资建议。