ERC-3135：只有发行方能替你扣款的代币，微支付通道怎么签

订阅服务按月扣费、算力按时长计费，这类小额高频支付如果每笔都上链，Gas 会吃掉大部分金额。ERC-3135 在 2020 年 8 月 10 日给出的办法是：让一种 ERC-20 附加一组新函数，用户把币存进合约担保，服务商拿着用户签名的消费凭据来“认领”，链上交互被压到最低。这份名为 Exclusive Claimable Token 的提案按 ercs 仓库记录状态为 Stagnant，动机部分写得很诚实：它想连接的不只是链上支付，还有真实世界的小商户。

押金、纪元与认领

接口围绕四个动作。deposit 让用户把代币锁进自己的押金余额，确保够付；claim 是核心，只有 issuer() 返回的发行方能执行，参数是付款人地址、本纪元消耗量、纪元编号和付款人签名；withdraw 把剩余押金退还给指定账户，原文注明预付费模块里由发行方执行、先存后付模块里由用户执行；depositBalanceOf 查询某用户的押金余额与当前纪元。纪元这个设计值得解释：每次认领或取款后纪元加一，新纪元开始时消耗量归零，相当于给每轮对账一个序号，防止旧签名被重复使用。事件侧的 Deposit、Withdraw、Claim、TransferIssuer 把资金动作全部留痕。

一条签名把五个字段钉死

签名内容是理解安全边界的钥匙。原文给出构造式：对代币合约地址、付款人地址、发行方地址、消耗数量、纪元五项拼接后再做一次哈希，加上以太坊签名前缀，由付款人私钥签出。签名前缀里那句带长度的提示词意味着这笔签名不能混进普通转账通道使用；五个字段则把“在哪枚币、谁付、付给谁、付多少、哪一轮”全部焊死，改任何一个都使签名失效。服务商侧的验证循环还要盯两件事：签名恢复出的地址必须等于付款人，未付金额逼近已签额度加容忍值时就中断服务、提示充值。

省 Gas 的另一面

对普通用户，这类机制的直观体验是：先充值、后按量扣、全程不再逐笔发交易。但权责也随之重新分配：押金锁在发行方的合约里，withdraw 谁能执行、执行不顺畅怎么办，取决于实现；签名机制防住了篡改，防不了发行方拿着已签额度之外的空口消耗——原文的验证伪代码特意让服务商自算未付额而不是随口报数，这个细节反过来说明，链下对账服务器的实现质量才是真正的短板。作为 Stagnant 提案，它没有成为通用标准，但“用户签名消费单加发行方独家认领”这套微支付骨架，在各类支付通道设计里反复出现。读到“先存后用、离线计费”的产品时，值得按这份老提案的四件套检查：押金存在哪、签名钉了哪几个字段、纪元怎么防重放、余额怎么退回。

一次扣费争议的举证链

设想最实际的场景：服务停了，你怀疑被多扣了押金。按这份标准的动作留痕，举证链条是清晰的。Deposit 事件记录你每次充值的金额与时间，Claim 事件记录每次认领的纪元与消耗量，depositBalanceOf 给出当前余额与纪元号，链上事件与你的签名记录可以逐条对账。争议点会集中在两处：一是某个纪元的消耗数值是否与你签下的数字一致——签名里五个字段与事件里字段的逐一比对就是你的证据；二是 withdraw 的发起权与到账，预付费模式下退款动作握在发行方手里，链上只能证明流程合规、不能替你把钱催回来。把这套对照读回任何先用后付的链上产品，先问签名钉了什么、事件留了什么、退款谁触发，三问落地，条款里的糊涂账就少一大半。

还要留意签名本身的展示问题：这类模式要求用户钱包对一串包含代币地址、纪元编号的数字签名，普通钱包弹窗里那串十六进制几乎不可读，用户实际签的是客户端软件替你算好的数字。客户端算错消耗量、或页面谎报用量，签名就会照着错误数字生效——原文在服务循环里让服务商自算未付额，正是默认了用户侧计算的脆弱。所以对账习惯应建立在事件流上，而不是信任界面上的消耗计数器。

本文为机制说明，不构成任何投资建议。