ERC-1175 把 ERC-20 结算压成一次调用：钱包合约与商店合约的配对账本

用 ERC-20 代币买东西，链上标准动作是两拍：先 approve 授权，再等商店 transferFrom 划走。ERC-1175 想把这两拍压成一拍。这份标准创建于 2018 年 6 月 21 日，仓库记录状态为 Stagnant，属于长期无人推进的归档方案，摘要的描述是：钱包与商店之间由“被认证的合约”建立起互信，买卖只需要一个简单的流程。它解决的问题很具体——规范动机部分说，尽管新标准不断发布，当时在开发的大多数代币还是 ERC-20，而 ERC-20 支付绕不开那两拍，于是给“一个钱包装多种代币、对接互信商店”设计了一对小合约。

钱包中心：先登记，再谈身份

一切从钱包中心合约开始。createWallet() 部署一个新钱包合约并登记入列，返回其地址；isWallet(address) 回答“这个地址是不是我铸造出来的钱包”。商店侧完全对称：createShop(address _erc20) 创建一个绑定某条 ERC-20 代币的商店合约，isShop(address) 做同样的出身校验。两族事件 Wallet(owner, wallet) 与 Shop(owner, shop, erc20) 让所有者事后能在事件日志里找回自己名下的钱包和店铺，钱包中心就是这套体系的户籍处。这套“先验出身”的登记设计是后面一切简化支付的地基：合约本身不验身份，身份等于“由中心铸造”。

钱包侧的三种花法

钱包合约要求由钱包中心铸造，侧栏函数包括 balanceOf(address _erc20) 查各代币余额、withdrawal(address _erc20, uint256 _value) 把代币提现回所有者，这两个入口带 onlyOwner。支付口有三个，差别全在信任前提上。paySafe(address _shop, uint256 _item) 付给由合约创建的安全商店，接口上同时挂着 onlyOwner 和 onlyShop 两道修饰符——签名者是钱包主人，收钱的那半边必须是登记在册的商店合约，按商品序号直接结算，一次调用完成。动机部分写得很清楚：ERC-20 原本要 approve 加 transferFrom 两次调用，用这套钱包合约后 paySafe 一次调用就走完。payUnsafe(address _shop, uint256 _item) 是另一条路，动机部分说得坦白：如果只复用商店接口，就可以用 payUnsafe 交易——它不要求目标在商店名册里，便利的代价是信任前提整个让渡给使用者。payCancel(address _shop, uint256 _item) 留给取消与退款，规范注释写明它只适用于按周计费的模型；钱包侧另有 refund(uint256 _item, uint256 _value) 接收退回的款项。

商店侧同样是一整套接口：price(uint256 _item) 让买家在付款前就能查到商品对应的代币地址与价格，resister 与 update 供店主上架和改价改库存，pay(uint256 _item) 带 onlyWallet 修饰符确保只接受来自登记钱包的付款，退款口 refund 同时受 onlyWallet 与 onlyOwner 约束。同一笔钱在链上留下两种截然不同的足迹：走 paySafe，对手方地址是登记过的合约，事件里商店项与代币地址一查对得上号；走 payUnsafe，对手方可以是任意地址，事后追责没有名册可依。支付与退款也各有对应事件：Pay(_shop, _item, _value) 与 Refund(_shop, _item, _value)，三个字段全部 indexed，等于给每笔消费留了可检索的回执，对账工具不需要解析交易输入就能重建账本。

这套设计停在哪里

把规范通读一遍会发现它简化支付的前提是“双方都是钱包中心铸造的合约”，而这恰是它没有铺开的原因。商店要为每个商品维护序号并主动收款，钱包是每用户一个合约，部署成本与迁移摩擦都被转嫁给用户；更重要的是，把 onlyShop 当成信任锚意味着钱包中心成为单点——名册出错或被弃管，paySafe 的安全含义就蒸发了，而 payCancel 把商业条款（周付、可退）直接编码进协议接口的做法，也让通用性大打折扣。这份 Stagnant 文档今天的价值是两面镜子：一面照出 ERC-20 两拍支付的历史痛点，后来社区给出的答案是 ERC-681 那样的请求格式与 EIP-712 签名授权，把复杂度放进离线签名而不是常驻合约；另一面是照妖镜，今天任何“一次调用完成代币支付”的方案，都值得拿这三个函数逐条对照问一句：信任锚在哪个合约、名册由谁维护、出纠纷时链上留下什么证据。答案为“项目方后台”的，它实际给你的不是合约互信，是托管依赖。本文为机制说明，不构成任何投资建议。