ERC-6932 订阅型代币：把按期自动扣款写进合约的六个函数

会员服务、域名、链上存储、社区通行凭证，这类产品的收费方式通常是”先授权、之后每期扣一笔”。网页世界里这叫代扣，链上世界里 ERC-20 本身没有”周期”这个概念——approve 只管额度，不管什么时候扣、扣几次。ERC-6932 试图补的就是这一层：给代币合约加一组订阅接口，让”按固定价格、固定频率、给每个订阅者单独记下一期扣款日”成为合约的内建行为。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2023 年 4 月 25 日。

标准文本里的六个函数和一张映射

ERC-6932 的接口 ISubscriptionERC20 在标准文本中列出的成员包括：subscribe 用于加入订阅，文本标注它可以是 payable 的，也就是允许在调用时附带原生币支付；unsubscribe 用于退出；subscriptionFee 返回每期价格；subscriptionFrequency 返回扣款周期；subscriptionInfo 一次性返回订阅编号、名称、描述和条款文本四个字段；subscribers(idx) 按下标遍历订阅者名单。标准摘要还特别提到一个 nextPaymentDate 映射，按地址记录每个人下一次扣款的时间点。把这几块拼起来，一个订阅关系的最小账本就成立了：价格、周期、条款、名单、下一期时间，全部由合约自己说话，而不是靠商户的客服页面。

和”留额度等扣款”的土办法差在哪

在 ERC-6932 之前，链上订阅的常见做法是用户给商户合约批一个长期 allowance，商户自己写脚本按期 transferFrom。这个土办法有两个结构性缺陷：一是额度不设周期，商户理论上任何时点都能扣，扣几次合约账本上看不出来；二是用户想退订只能去撤额度，撤没撤干净、商户端有没有同步停止服务，全靠双方自觉。ERC-6932 的差别在于把周期语义放进合约：subscriptionFrequency 定义多久扣一次，nextPaymentDate 定义下一次轮到谁，unsubscribe 是一个链上动作而不是客服工单。审查一个订阅合约时，用户理论上可以通过只读调用直接回答”我下次什么时候被扣、扣多少、合约认不认识我还在订阅名单里”这三个问题。

自动扣款仍然需要一个动手的人

值得澄清的一点是：以太坊合约没有闹钟。subscriptionFrequency 只是把周期写成了数字，真正到点执行扣款的仍然要有人或合约来调用——可能是商户自己的自动化守夜程序，也可能是聚合扣款的第三方合约，这一层标准文本并没有替实现方规定。因此评估一个基于该标准的订阅服务时，除了看接口是否齐备，还要看两点：扣款触发逻辑写成什么样，余额不足时合约怎么处理。subscribe 本身是 payable 也提示了一种混合收费模式——首期可能直接用原生币结清，周期扣款才走代币余额。

把接口翻译成三个可自查的问题

对审查工具来说，这组接口等于把一份订阅协议变成三道免 Gas 的只读题。一是名单题：从下标零开始逐个调用 subscribers(idx)，返回零地址即遍历到底，链上订阅总规模可以直接数出来。二是条款题：把 subscriptionInfo 返回的名称、描述与条款文本和项目官网逐项对照，两份说辞不一致本身就是红旗。三是状态题：确认自己的地址是否真在名单里、nextPaymentDate 是否停在预期的未来时间。三个答案全部来自合约本体，不经商户之手，这正是把订阅写进标准接口的意义。

退订路径和条款文本为什么重要

标准把 unsubscribe 列为必选函数，等于承认”用户单方面离网”是订阅代币的基本权利。实际操作里这一步应当永远优先于任何弹窗挽留流程：先在链上调用退订，再处理账单争议。subscriptionInfo 返回的条款文本字段则是给钱包和审计工具看的——如果条款描述与实际扣款频率对不上，比如文本写着按月扣而 subscriptionFrequency 是八十六万四千秒（一天），这类矛盾就是最直接的红旗信号。按 ercs 仓库口径，ERC-6932 停留在 Draft，未进入最终标准，市面上自称”订阅型代币”的合约大多实现了自己的私有接口，逐项对函数名再下结论比看宣传语可靠得多。本文为机制说明，不构成任何投资建议。