钱先冻结、清算人放行才算转出：ERC-2018 可清算代币的六个状态

你在交易所提币被驳回、在支付网络做争议退款，背后都是清算概念：付款承诺和资金实际移动之间隔着一道裁定环节。ERC-2018 创建于 2019 年 4 月 30 日，仓库记录状态为 Stagnant，它把这道环节写成代币合约的状态机，让链上转账获得“先挂起、后裁定”的银行式生命周期。

一笔转账的一生

付款方调用的不是 transfer 而是 orderTransfer，配一个自己生成的 operationId 字符串作为订单编号，orderTransferFrom 是授权代付版本。下单瞬间发出 ClearableTransferOrdered 事件，订单进入 Ordered 状态。原文对资金状态的描述很关键：金额不从付款方余额中扣除，但也不能被另一笔转账使用——效果等价于冻结。之后路径分叉：清算人调用 processClearableTransfer 把它推入 InProcess，再 executeClearableTransfer 完成移动，或者 rejectClearableTransfer 带上驳回理由退回；付款方在裁定前可以 cancelTransfer 撤单。每个出口各发一条事件：ClearableTransferExecuted、ClearableTransferRejected、ClearableTransferCancelled。合约内的状态枚举依次是 Nonexistent、Ordered、InProcess、Executed、Rejected、Cancelled，用 retrieveClearableTransferData 可以一次读回订单的付款方、收款方、金额和当前状态。

清算人从哪来

能裁定的地址不是天然的，需要账户显式授权：authorizeClearableTransferOperator 指定某清算人处理自己的转账，revokeClearableTransferOperator 撤销，isClearableTransferOperatorFor 查询授权关系，授权和撤销同样各有一条事件。换句话说，这个标准里清算人是用户可选的服务商，而不是内置管理员，这是它和单纯“管理员可回滚代币”的本质区别。原文还标注接口继承 ERC-1996 的数据回执思路，即每笔操作可凭编号取回完整处理记录。

订单编号的讲究

operationId 由下单方自选字符串，这个自由是风险点也是审计点。同一编号重复下单、不同币种或不同合约间编号碰撞、下单方换钱包后编号失去归属，都需要消费方自行约定命名规范。原文把订单数据全部挂在编号下，retrieveClearableTransferData 一次读回四方信息，等于强迫所有参与者用同一个主键说话：任何对账系统只要收下编号加事件，就能把挂起、执行、驳回、撤单四类状态串成一张完整凭证。清算人的授权同样围绕账户而非订单：授权事件记录的是清算人处理某账户转账的资格起止，审计时按地址聚合即可复原每一笔裁定的权限来源。

与近似机制的区别

挂起态和可回滚不是一回事。某些代币给管理员直接冻结或反向转账的能力，事后补救，钱已经在对方账上过了一圈；ERC-2018 把裁定放在转账生效之前，被挂起的金额在法律语义上从未离开付款方，也就不存在追回问题。它也和 ERC-1996 的纯数据回执不同：1996 只让订单可查询，不改转账语义；2018 在此之上把裁定权做成独立角色和独立状态。评估一个声称支持争议退款的代币时，先问它是哪种形态：链上挂起订单、链下多签退款，还是管理员单方回滚，三者的资金安全模型完全不同，用户承担的时间成本与信任成本也完全不同。

兼容性与现实的夹角

标准的尴尬写在原文里：它不规定 ERC-20 的 transfer 该禁止还是允许。若保留直接转账通道，冻结与清算语义就有了绕行的后门；若全部禁止，这个代币和任何依赖 ERC-20 转账的钱包、兑换设施都接不上。这条路线停在 Stagnant，很大原因在此。但它的状态机语言今天仍在支付类合约里以私有形态使用：挂起金额、订单编号、带理由的驳回、可查询的状态枚举。拿它当模板读现代争议退款合约时，重点核对三件事：冻结是否真在合约层生效、清算人授权能否单方面撤销、驳回理由是否进了事件——三样缺一样，清算话术就只是宣传。

本文为机制说明，不构成任何投资建议。