钱还没动就先冻结：ERC-1080 的可找回代币与退单窗口

“转账不可撤销”常被当成区块链的天条，但有一批早期标准试图在代币合约层面给这笔交易装上后悔药。ERC-1080 是其中最直白的一份：摘要写着给 ERC-20（以及 ERC-791 类合约）扩展出找回丢失或被盗账户、以及对代币转账发起退单的基础功能。文件头记录创建于 2018 年 5 月 2 日，仓库状态为 Stagnant，属于长期无人推进的归档方案。它的动机部分有一句话值得整段记住：协议层不应该因为盗窃、丢失或纠纷去修改区块链本身，但这些问题可以在智能合约层面解决。

报失：先占坑，再裁决

claimLost(address lostAccount) 把某个账户申报为丢失，规范强制要求触发 AccountClaimedLost 事件。申报不等于拿回钱：实现方必须提供一个机制，在 getLostAccountRecoveryTimeInMinutes 配置的时长之后，去“确定代币的正确所有者并把代币移到新账户”，整个恢复过程必须触发 AccountRecovered 事件。也就是说这份标准只标准化了“报案”这个接口，断案规则留给项目方自己写——这句限制后面还会反复出现。

申报不是不能撤回。cancelLostClaim 让申报人改口“没丢”，规范要求触发取消事件，并且规定一个硬条件：如果恢复流程已经启动，这个撤销必须失败。时间窗口内你可以反悔，裁决机器一旦开动就不能反悔，这是防止用报失-撤销反复试探机制的实现。

被盗：先冻结，后追认

和报失不同，reportStolen 申报的是自己当前这个地址被盗，语义是“钥匙在坏人手里”。调用成功的直接后果写在规范里：msg.sender 的代币被冻结，并触发 AccountFrozen 事件。被盗路径没有等待期设计，因为等的每一秒都是对方继续转走的窗口；冻结优先、归属后判，和报失路径的“先观察再动”正好相反。两条路径殊途同归，最终都要靠实现方的机制把代币挪到正确账户并发出恢复事件。

规范同样给了 getLostAccountRecoveryTimeInMinutes(address account) 与 setLostAccountRecoveryTimeInMinutes(uint256 minutes) 这对读写函数，裁决等待期按账户可查、按合约统一设置——任何人转进这种代币之前都可以先查这个项目给自己留了多长的争议窗口。整份设计对“每一步都要在日志里留下可追凭证”的执念非常重：除了前述事件，还规定了 PendingTransfer(from, to, value, pendingTransferNumber) 给每笔待定转账发号，ChargebackRequested 与 Chargeback 分开记录退单请求与退单成立两个时刻——审计工具顺着这四类事件就能重建“转账待定、被申请退单、退单落地”的完整链条。

退单：每笔转账自带一个时间胶囊

chargeback(uint256 pendingTransferNumber) 是这份标准最有争议的部分：由转出方对某笔标了号的转出请求撤销。它有一个必守的前提——必须遵守 setPendingTransferTimeInMinutes 配置的发件人退单窗口，窗口外退单请求不成立。配套的 getPendingTransferTime(address) 是公开查询口，接收方可以事先看到对方地址享受的退单时长。商品已经交付、窗外才收到退单尝试的纠纷，在接口层面就被这份设计的时序规则掐死了；窗口内收到的每一笔“已到”余额，严格说都处于待定状态。

把两个窗口放在一起读，可以拼出这类代币完整的生命周期：转入后先进入待定窗口，窗口期内可被退单；报失路径再给归属争议加一层等待期；被盗路径随时能按下冻结按钮。对一个需要和这种代币交互的交易所或商户来说，这三层状态机没有一层是链上密码学保证的，全部依赖“实现方提供的机制”——项目方的审核团队就是这套系统的信任核心。

为什么这条路没有铺开

接口逐条读完，问题就浮出来了。第一，冻结和改余额需要裁决者，裁决者意味着中心化的争议处理，这和 ERC-20 时代“代币合约没人能动”的默认认知正面冲突。第二，chargeback 让“到账”变成概率事件，对交易所、清结算类集成是灾难级的不确定性，收款方要么等满窗口要么承担可逆风险。第三，各家的“恢复机制”互不兼容，钱包和交易所无法标准化接入。所以它停在了 Stagnant，后来资产找回的主流路线转向了账户层的白名单、时序锁和恢复密钥，而不是在通证合约里内置法院。今天如果某个代币真的实现了这一族函数，正确的读法是：余额含义是“无争议窗口内的余额”，大额收付前把两个时间参数查清楚，比看项目白皮书的承诺可靠得多。本文为机制说明，不构成任何投资建议。