ERC-8187 Token Puller：余额不在这儿也能扣款的取款合约怎么设上限

订阅服务最常见的尴尬是：你授权了额度，但扣款那天钱包里刚好没币，扣款失败、服务中断，还得手动补一次。ERC-8187 提出一个换法的思路：不要把授权绑死在某个余额上，而是授权一个取款者合约在限额内想办法把钱取到——它可以先去你授权的借贷协议里取，也可以从你指定的池子里换，取到之后再划走。按照以太坊 ercs 仓库的记录，这份提案名为 Token Puller，状态为 Draft，创建于 2026 年 2 月 27 日。

限额、额度、可取量是三个不同的数

接口的关键词是 limit 而不是 amount。approvePull(address token, address spender, uint256 limit) 设定的是某个取款者在你名下的累计上限，pullAllowance(token, owner, spender) 读回这个上限还剩多少可用；pullFrom(address token, address owner, address to, uint256 amount) 由取款者调用完成实际划转；maxPullable(token, owner, upTo) 则回答更现实的问题——考虑当前来源可得性之后，此刻最多能动多少。三个数分开，就出现了传统 ERC-20 allowance 里没有的一种状态：授权仍然有效、余额此刻不足。对定期扣款的场景，这种区分是核心，因为扣款失败的原因第一次变得可编程。

permitPull 与原子组合

permitPull 把签名化的授权（EIP-712 签名，并借助 ERC-6492 让尚未部署的智能账户也能签）和取款合并为一次调用，pullFromWithPermit 则把签完的授权立刻兑现成一次划转。这两条路径适合两种人：一次性授权（今天这一笔，签完作废）和链下审批流（财务系统里点通过，签名传给服务端执行）。标准同时提到授权可以委托或转让、可以被持有人放弃（renounce），给了授权关系一个明确的退出动作，而不是只能靠设回零来暗示。

它没有解决什么

最值得留意的一条：取款逻辑写在取款者合约里，同一份授权在不同取款者实现下可能表现完全不同——一个可能只是从你的余额扣，另一个可能先赎回你在协议里的存款。评估它的安全边界时，看的是取款者的源码是否只碰你显式许可的来源、limit 是不是累计口径、跨期扣款是否共享同一个 limit。标准把限额语义统一了，但没规定取款者能从哪些外部协议搬钱，这部分仍然是各家实现的责任。对使用方最实用的自查是：调用 pullAllowance 看你给这个地址的累计上限是多少，再决定这个数是否与该服务的年费总额相当；上限远大于应付总额，说明你授权了超出必要范围的取用能力。

与 ERC-6932 类订阅代币的关系

与订阅场景的完整拼合

把这套接口放进一个真实的订阅生命周期，动作序列大致是：签约时调用 approvePull 设一个与年费相当的累计上限，而不是无限额度；每期账单由取款者调用 pullFrom，接近上限时 maxPullable 会提前暴露余额缺口，让扣款程序有机会先充值而不是直接失败；服务终止时调用一次额度归零的 approvePull 或走标准提及的 renounce 路径，把授权关系正式了断。与土办法对比进步在哪里：额度语义从无限期无限次收敛成有限额有限次，退订从依赖商户自觉变成链上可验证动作，欠费与停服的因果第一次可以用 pullAllowance 数值解释。同时该保持的清醒也要保留：累计口径下部分退款怎么返还额度、汇率波动资产怎么折算，标准都未规定，签约前问清实现方的这两处细节，比任何品牌承诺都实际。

订阅代币标准把周期语义做进代币合约，而 Token Puller 把取款的资金组织能力做进一个独立合约，两者解决的是同一片需求的两半：前者管什么时候该扣、扣多少；后者管扣的时候钱从哪儿来。一个完整的产品可能两者都用，也可能只用其一。看懂这一点，就不会被都支持自动扣款这种笼统说法混淆——先问周期字段在哪个合约，再问限额字段在哪个合约，两个答案分别可查，才构成完整理解。按 ercs 仓库口径该提案为 Draft，尚未定型，接入前以合约实际函数列表为准。本文为机制说明，不构成任何投资建议。