到点才能领的转账：ERC-7720 延迟代币转账的 txnId、解锁时间与无主设计

“NFT 的尾款三个月后付清""活动奖励分四期发放”这类约定，靠什么承载才不尴尬？口头承诺没有约束，每次手动打款又累又容易漏。ERC-7720 给出的答案是建一个专门的中转合约：付款方把 ERC-20 存进去并写死领取时间，收款方只能到点后自己来取。标准文档记录的状态为 Draft，创建于 2024 年 6 月 9 日，现状以标准仓库为准。本文只拆机制，不涉及任何项目背书。

三行流程与两个事件

流程只有一存一取。存款走 transferFrom：传入代币地址、付款方、收款方、金额、unlockTime（用 40 位无符号整数表示的解锁时间戳）和一个 32 字节的参考号，合约把币收进来，登记一条转账记录并返回唯一的 txnId，同时发出 Transfer 事件——这个事件里带全了七项信息，包括解锁时间，索引器据此建台账。取款走 withdraw(txnId)：先校验记录存在、当前时间不早于解锁时间、还没有被提取过，然后把币打到存款时登记的收款地址，发出 Withdraw 事件并打上已取标记。想查某笔延迟转账的细节，用 getTransaction(txnId)，代币、双方地址、金额、解锁时间、参考号、是否已取，一次返回。

时间字段为什么用 uint40？设计说明的解释是：40 位足以覆盖所有现实的锁仓跨度，同时给每笔记录省下空间；txnId 用独立递增整数而不是复用 ERC-20 转账日志，是为了让每一笔延迟安排可单独寻址、单独跟踪，多笔并行也不会互相覆盖。它与 ERC-20 的关系是”外挂”而非”改造”：标准刻意做成独立接口，任何现成的 ERC-20 都不需要升级就能被存进这类合约，这是它兼容性的来源。

为什么安全章节要求”无主”

文档的安全考量写了两条，分量很重。第一，这类合约不应设置管理员——一旦有 owner，理论上就存在把合约余额挪去非受益人地址的代码路径，时间锁承诺就退化成”信任管理员不滥用”；无主设计让余额只可能流向登记在册的受益人。第二，取款时必须严格把钱打给存款时登记的收款地址，不允许事后改道。这两条合起来就是它的信任模型：付款方信任的是”代码加时间戳”，而不是任何一方的善意。需要说明的是，这是标准文本给出的实现指引，具体部署是否遵循，要逐个合约读源码验证——把”标准建议无主”当成”所有实现都无主”，是常见的偷懒推断。

使用场景里的对与错

适合它的：定金尾款、分批付的服务费、按时间表释放的贡献者奖励。不适合它的：需要中途修改条款的复杂分期（本接口没有改期函数，写错时间只能重新登记）、跨链结算（记录与资产都在单链合约里）、以及任何需要收款方私钥以外手段兜底的安排。给使用者的自查清单很短：存之前，在浏览器确认中转合约已验证源码且你能读懂无主条款；存之后，把返回的 txnId 与链上 Transfer 事件对一次，收款方地址拼写确认无误——登记错了，到点也领不出正确地址；临近解锁时，收款方自查 getTransaction 的 withdrawn 字段即可，无需询问任何人。

顺带澄清一个常见误会：延迟转账与”退款”不是一回事，本接口没有给付款方预留取回通道，unlockTime 之后收款方是唯一的资金去向；把这两件事混为一谈的教程，往往在描述某个具体项目的自定义变体而非标准本身。本文只做机制科普，不构成投资建议；凡要求你先存币进陌生地址再”到期自动返利”的话术，与本机制无关，按诈骗处理。