ERC-1337 链上订阅：先签授权后扣款的旧实验

网页3 世界对”订阅”有过一个天真而迷人的设想：内容网站按月收费，不必每笔都弹窗让用户确认，而是用户最初签一份数据，服务方此后到期自行执行——像信用卡代扣，但执行凭据是密码学签名而不是卡号。ERC-1337 于 2018 年 8 月 1 日提出，状态 Stagnant，是这条路线上最有代表性的早期尝试。它借用了 Gnosis Safe 的多签枚举思路，把”可重放交易”做成订阅底座。今天主流链上没有原生订阅协议，但这份提案留下的问题——预签名到底给了对方什么权力——在每一代批量授权争论里都会重演。

机制：签名存在商家那里，链上只是执行

提案的原始流程分三步：用户把执行订阅所需的输入数据拼成一段字节串，对它的哈希签名；这段数据由收款方（而非用户）离线保存；到期时服务方把数据连同签名提交到用户的订阅合约执行。接口提供 getSubscriptionHash 生成订阅标识、isValidSubscription 验证某订阅当前是否有效、executeSubscription 执行一笔，另有状态修改相关的 modifyStatus 与 getModifyStatusHash。订阅状态被枚举成四种：ACTIVE、PAUSED、CANCELLED、EXPIRED，周期枚举支持日、周、月。合约还应实现 ERC-165 声明接口支持。

与”无限授权”的本质区别

很多人第一反应是：这不就是一枚永不过期的 approve 吗？结构上相似，机制上差三层。第一，作用域：签名绑定的是这份订阅的具体参数（金额、周期、对手方），不是代币合约的任意划转权；第二，可查询性：订阅有 isValidSubscription 这样的公开状态查询，暂停和取消理论上应反映在链上状态里，而无限授权只有一个额度数字；第三，可撤销性：改状态走 modifyStatus 签名流程，撤销动作留有链上痕迹。但第三层正是要害所在——若实现合约把状态更新做得不严，或者签名参数设计宽泛，用户”取消订阅”就可能只是网站后台的标记，链上扣款照跑。

为什么没跑起来

订阅模式对链上服务（域名续费、存储、会员）是真需求，ERC-1337 却没有普及，可见的原因有三：一次性预签任意时长扣款在自我custody文化里极不受欢迎，签名管理本身成了新风险面；智能账户与订阅费率的通用方案迟迟缺位，每条链要各自适配；支付侧稳定币生态成熟太晚，链上订阅的钱从哪儿来先成了问题。后来的替代路线分成两支：账户抽象体系给”条件化的自动执行”提供了更细的权限颗粒，稳定币侧则用”按期人确认”的土办法守住控制权。

把它与今天的签名体系对照，能看清十年间答案的演进。ERC-1337 让用户签一段自定义拼接的字节，验证靠合约里的还原逻辑；EIP-712 之后，签名内容有了类型化结构，字段名、类型、验证合约地址与链 ID 都被哈希进域分隔符，签名从”我对一串字节签过”精确化为”我在指定链上对指定合约的指定结构签过”。跨链重放、合约混淆这些当年的事故高发区，正是靠这套结构化编码堵上的。今天再评估预签名产品，也应按此精度提问：签的是类型化结构还是裸字节？域里有没有绑定合约地址与链 ID？执行函数有没有校验订阅状态而非仅验签名——两者叠加才构成”取消后扣不动”的技术保证，任何一环缺失，取消都只是商业承诺。顺带一提，提案里那份日周月周期枚举也提醒我们检查计价周期：订阅价按区块时间还是自然月计，合约里没有日历，时区与闰月都会变成实现者的自由裁量。

给用户的现成教训

即便不碰任何 ERC-1337 产品，这份老提案仍然提供一份安全检查心智：凡是让你”签一次、以后自动执行”的授权，都要当场问三件事——签名绑定了哪些字段，有没有公开的过期与撤销查询函数，撤销需要对方配合还是自己单方就能在链上作废。三问有一个答不上来，这份便利就是在透支控制权。本文为机制说明，不构成任何投资建议。