ERC-7444 时间锁的到期日查询：一把链上锁怎么回答”什么时候能开”

链上的”锁”长得千奇百怪：锁仓合约、定期存款式金库、 vesting 分配、定期质押，每家给自己起不同的函数名，有的干脆只把到期时间写进内部结构体，外面只能靠猜。聚合器想统一展示”你的资产分别什么时候解冻”，就得为每个项目写一个适配器。ERC-7444 的解法小得近乎朴素：定义一个函数，任何时间锁系统只要回答 getMaturity(id) 返回一个时间戳，锁的世界就统一了。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2023 年 6 月 5 日。

接口的全部内容

标准文本里的接口只有一个函数：getMaturity(bytes32 id)，返回 uint256 maturity，即该锁到期解锁的 Unix 时间戳。示例实现展示了配套的最小生命周期：deposit(amount, lockingPeriod) 存入资产并同时返回一个 bytes32 的 lockId——示例里由 keccak256 对存入者、金额与到期时间做哈希生成，用作这把锁的标识；到期后 withdraw 才放行。注意 id 参数的设计意图：一个合约可以同时持有成千上万把锁，每把锁到期时间各不相同，必须有一个句柄把它们分开引用。对只有一种全局锁的简单合约，id 可以约定用固定值或零值，标准不强制。

一把”句柄”带来的可组合性

这个函数的直接受益者是估值与流动性工具。一份还有九个月到期的锁仓资产，和一份明天就解冻的同类资产，风险折价完全不同——标准摘要点名的正是这个用途：给多类资产类别（asset classes）标明到期日，让它们更容易被定价。有了统一的 getMaturity，借贷协议可以按剩余锁期做质押率梯度，行情页可以把”解锁倒计时”做成标准字段，钱包能在到期当天提醒用户去提现。反过来，对不支持该标准的合约，同样的信息要靠读内部变量或翻部署脚本获得，工具成本逐项目累加。

查到期日的三个实操要点

第一，时间戳的单位与含义要核实：标准规定 maturity 是解锁生效的 Unix 时间戳，与区块时间戳同为秒级，但个别实现若用毫秒或区块高度填入，读到天文数字或异常小的数字即是对不上口径的信号。第二，lockId 的生成口径要问清：示例用哈希生成意味着同额同长的两次存款可能得到同一个 ID（哈希输入相同），持仓对账时应当以合约实际的事件与映射为准，不能照抄示例想当然。第三，到期不等于到账：getMaturity 只回答锁何时打开，withdraw 是否自动执行、是否需要用户主动提取、错过的锁是否滚动续期，都在这个函数管辖之外——ERC-6229 那类需要结算轮次的金库就是”到期了但另一套流程”的现成例子。

锁与 NFT 的交集

时间锁和 NFT 生态的交集比表面看起来密。项目方常见的团队代币锁、创作者版税的分期释放、预售凭证附带的交付期，本质上都是”某个权益在某个时间戳之后才解锁”。ERC-7444 的价值在这些场景里体现为统一的问题句式：不管锁的是代币、NFT 领取权还是分成流，解锁时刻都问 getMaturity 一个函数。对买家，这也给出一个可执行的习惯——凡是”买了但暂时拿不到”的资产，先问三件事：句柄 ID 是什么、getMaturity 指向哪个合约、时间戳换算成日历时间是否与营销页面写的解锁日一致。三问有一个答不上来，所谓锁仓条款就只存在于宣传图里。

最小标准的价值与局限

按 ercs 仓库口径，ERC-7444 停留在 Draft，采用者有限。它的示范意义在于展示了”薄接口”的设计哲学：不定义锁的创建、不定义提款、不定义罚则，只统一一句”什么时候开”。局限也来自同一处：正因为管得少，锁的内部机制——可否提前解锁、到期后是否罚没、能否展期——仍需逐项读各自合约。对用户，把这一句和另外两句（“里面锁了什么、锁了多少”）凑齐，才算完成对一个锁仓仓位的完整清点。本文为机制说明，不构成任何投资建议。