币会过期：ERC-7818 可过期 ERC-20 的纪元余额算法

奖励积分、活动补贴、限定用途的代币，发行方常有一句备注：“请在有效期内使用”。ERC-7818 可过期 ERC-20（Expirable ERC-20）把这句备注变成合约原生状态：余额不再是一行总数，而是一串按“纪元”（epoch）分箱的批次，每个纪元到点作废。标准状态为 Final，创建于 2024 年 11 月 13 日，兼容实现必须继承 ERC-20 接口并实现它列出的全部函数。

纪元如何划分、余额如何分箱

纪元有两种定义：按区块数（例如每 1000 个区块一个纪元）或按秒数（例如每 1000 秒），由 epochType 查询属于哪种、epochLength 给出长度、currentEpoch 给出当前是第几代、validityDuration 告诉你在多少个纪元之内有效，isEpochExpired 直接回答某一代是否过期。代币与铸造或转入时所在的纪元绑定；纪元区间一结束，该批即视为过期。规范对核心查询有硬性规定：balanceOfAtEpoch(account, epoch) 返回账户在指定纪元的余额，若该纪元已过期，必须返回零——过期不是靠后台脚本删余额，而是查询语义天然排除。转账侧还有 transferAtEpoch 与 transferFromAtEpoch，允许显式操作指定代际的余额。

文档给了一个直观算例：某地址纪元 1 得 100、纪元 2 得 150、纪元 3 得 200，当前纪元 3、有效期覆盖两代，则可用合计是纪元 2 加纪元 3 的 350，纪元 1 的部分已过期不计。这套账本与传统“过期即销毁”的关键差异在于记账方式：旧批次永久留在分箱账本里，只是查询时被排除；你能随时回答“他去年那批券还剩多少没用过”，也能在项目方声称“发放了 X”时逐纪元核对。一次性批量销毁的账本，事后只能靠发行方公告对账。

你会在哪里遇到它

最贴近的是积分与激励设计：任务挖矿、签到返利、流动性补贴这类“会过期的钱”，用 7818 表达后，规则（纪元粒度、有效代数）直接写在合约里，参与人自行查询即可验证“我的哪批什么时候到期”，不必相信前端倒计时。其次是带使用期限的凭证与配额：内容平台的播放额度、活动的优先铸造额度，都可以是绑定纪元的批次。NFT 侧的组合玩法也存在：主币是普通 721，配套权益代币按 7818 发行，权益按季滚动作废，持仓者随时能查每季权益的到期线。

持有“会过期的钱”要盯什么

第一是纪元粒度换算。按秒的纪元对钱包展示友好；按区块的纪元受出块速度影响，同一份“1000”在不同链上的真实时长可能差出数倍——把参数换算成人类时间再决策，是基本核验动作。第二是参数变更的可能。纪元长度、有效期属于项目参数而非标准常量，修改通常要走治理或升级动作，查事件与提案历史里有没有被临时调整过，值得放进尽调清单。第三是转账语义：带纪元的代币在普通转账时动的是哪一代余额、是否先进先出，取决于实现分支；在市场里挂单卖出前，确认前端展示的是“可用余额”而非名义总余额——挂着快蒸发的旧批次成交，等于用即将过期的资产换回即时资产，账目含义完全不同。

一句总结：7818 让“过期”从条款变成算式，但算式参数永远是项目方的选择——读标准只帮你问对问题，答案仍在具体合约的函数返回值与事件记录里。

接口全表值得一读：currentEpoch、epochLength、epochType、validityDuration、isEpochExpired 五个查询描述规则本身，balanceOfAtEpoch 按代际读余额，transferAtEpoch 与 transferFromAtEpoch 允许指定代际划转。合规实现的 ERC-20 标准函数照常工作，扩展函数只是把“哪一代币”显式化——这也是集成成本低的含义：旧钱包与旧浏览器看不见新函数，转账依旧可用，只是分代语义要靠支持这套扩展的工具才显示得出来。 最后提醒：本文讲协议机制，不构成投资建议；持有带期限属性的资产前请核验合约中的纪元参数，并自行计算实际到期区块或时间点。