ERC-4546 一次授权处处存管：把 approve 的重复动作焊进一个公共合约

给去中心化应用转入 ERC-20 代币时，多数钱包用户都被同一套流程折磨过：先签一笔 approve 精确数额，入金时再签一笔；嫌麻烦的直接批一个无限额度，然后在各个应用里挂着一排不知道什么时候才能撤掉的授权。2021 年 12 月 11 日创建的 ERC-4546 瞄准的正是这个重复，它提出一个叫 Wrapped Deposits 的公共存管合约，提案状态目前是 Stagnant。思路一句话能说完：用户对这一个合约只做一次额度设置，之后向任何支持它的应用入金，都不再需要逐次批准。

合约怎么运作

按原文要求，存管合约部署在一个可识别的地址上，并且必须不可升级、状态变量不可更改——它越简单、越一动不动，用户才越敢把长期授权押在上面。合约暴露 depositERC20、depositERC721、safeDepositERC721、safeDepositERC1155、batchDepositERC1155、depositEther 一组函数，参数里都带一个 to，即真正的收款应用地址。每次调用时合约先访问 to 上对应的接收接口，比如 ERC-721 的 acceptERC721Deposit、ERC-1155 的 acceptERC1155Deposit，确认对方愿意且能够接收，确认失败整笔回滚；to 是空地址同样直接拒绝。对用户而言动作只剩一个：在 ERC-20、ERC-721、ERC-1155 或原生币各自的合约上，对这个存管地址设置一次额度，此后所有入金都走这一个入口。

省掉的和换上的

省掉的东西很清楚：每笔入金少一次 approve 交易的费用与等待，无限授权的暴露面也从几十个应用合约收缩为一个固定的公共地址。换上的东西值得用放大镜看。原来每个应用的授权彼此隔离，一个应用出事不牵连其他应用；收拢到存管合约后，信任的焦点从一堆应用变成这一个合约。它靠的是代码可读、不可升级、无需权限这三件事来压低风险，但这仍然是一次集中化：如果用户的额度长期高挂，任何一次实现层面的意外都会同时波及所有经由它的存款路径。接收侧的确认回调同样引入新的依赖，应用没实现对应接口就收不了那种资产。

放回当时的主流做法里看，差异更直观。721 入金的传统路径是 safeTransferFrom 直接转给应用，应用在自己合约里实现 onERC721Received 回调，每次入金都要先对该应用做一次 approve 或 setApprovalForAll；有些市场还要求用户额外授予一个代操作入口，把铸造、挂单等动作也一并委托给它的合约。ERC-4546 的折中是把中转地址从每个应用各一个变成公共一个：应用只要实现 accept 系列接口就能开门，用户不再需要逐个应用建立信任关系，代操作权限也不再散落在几十个合约里。作为交换，存管地址本身成为一个必须永久正确的基础设施，它连一次热修复的余地都没有，合约越干净，用户越安心，开发反而越受束缚。

为什么没有流行

存管合约模式在细分场景里其实一直存在，各应用的存入合约、桥的托管合约都是它的变体，区别只是那些合约归单个应用所有，而 ERC-4546 想做一个公共中立的版本。公共合约意味着没有任何应用方有动力为它的安全预算买单，标准提案很难养活一个需要持续审计的共享基础设施。另外它和当时正热的账户抽象路线也有些错位：如果未来钱包本身能替用户编排多步操作，逐次 approve 的痛点会被另一层解决，公共存管的必要性就进一步下降。

对用户来说可以带走的经验有两条：其一，入金前确认资产真正从哪个地址流向哪个地址，代理存管会改变这条路径；其二，定期清理不用的授权额度，无论对方是应用合约还是公共存管合约，挂着的高额度都是同一种敞口。核对手续其实不重：钱包的授权管理页拉一份清单，把每个被授权合约核对到具体应用，不再使用的一律降为零额度，这一步每半年做一次，比事后追查被盗记录便宜得多。本文为机制说明，不构成任何投资建议。