看起来是空地址，主人却能替它办事：ERC-7613 Puppet 代理的两种面孔

一个地址在浏览器里从没主动发起过交易、合约页显示不出代码、却持有资产、偶尔替别人执行签名验证——这不是灵异事件，多半是一种特殊代理合约在按设计工作。ERC-7613 给这种结构起了名字：Puppet（傀儡代理）。看懂它，能帮你把”查不到的地址”从恐慌清单里划掉。

规范原文的两种行为

提案文本对 Puppet 的定义只有一句话的骨架：这种合约平时像一个空账户——什么都不做、没有任何对外接口；唯独当调用者是当初部署它的地址时，它把调用委托给 calldata 里指定的实现合约执行。于是同一个地址有两种面孔：对公众，它是零代码、零入口的”空壳”；对部署者，它是万能的操作替身，部署者想让它在谁身上执行什么逻辑都可以。规范还特意设置了与 EIP-1967 代理的互斥检查：实现合约地址不能占在 1967 那个约定槽位上——因为那个槽是全行业用来”公开实现地址”的，Puppet 故意不用它，才造成外部查不到实现的观感。这是设计特征，不是漏洞，但也是审计盲区。

谁在用这种结构

从用途倒推最直观。智能账户生态里，它适合做”确定性地址的部署模板”：先按固定地址预埋一个傀儡，等需要时再由工厂合约（部署者）注入逻辑并接管资产，整个生命周期里这个地址从没主动上链，直到第一次被调用才”激活”——这与生成以太坊地址为什么免费？地址创建与链上激活的区别讲的”地址创建与链上激活的区别”衔接得很好。另一种常见来源是确定性工具地址：批量部署器、工厂的辅助件、测试残留的部署模板。也就是说，见到傀儡地址第一反应不该是”被盗了”，而是”它是谁的工具”。

排查路径：五步给陌生地址定性

第一步，看这个地址的创建交易：浏览器地址页找”Created”或合约创建记录，顺 from 找到部署者——Puppet 没有自报家门的接口，部署者就是它的说明书作者。第二步，反查部署者：部署者若是知名协议的工厂合约，基本可以定性为基础设施地址。第三步，看激活史：Puppet 只有部署者调得动，它的每一笔”执行”交易都应由部署者发起；一旦出现第三方成功与它交互的记录，说明该地址的实现或访问控制与规范不符，属于要回避的异常形态。第四步，看它名下的授权关系：资产若因它受损，检查它是否被登记进某个账户的模块——一个自己不主动作恶的地址，完全可能被账户逻辑授权成执行通道，模块清单排查思路与硬件钱包到手先做哪几件事？开箱、初始状态与真伪核验之后的那套账户权限审计一致。第五步，交叉验证多浏览器显示，防止是假浏览器给你看了残缺数据搜索引擎广告位里的假官网：从点击到钱包弹窗的完整链条。

对账户安全的一个提醒

傀儡结构对普通用户最大的启示反向而来：能操作一个合约的逻辑不在合约自己身上，而在”谁能调用它”。你授权过的智能账户模块、批过的角色、签过的委托执行ERC-7836 的两步流程：应用先签名、钱包后执行，你让渡了什么，都是同一类”平时沉默、条件触发才显形”的结构。定期盘点的方法在栏目里反复出现：断开连接和撤销授权是两回事钱包连接过的网站清单怎么清：断开连接和撤销授权是两件事，授权有到期与否的差别，批量授权要按笔核对而不是整体放行。把 Puppet 当作教材而非威胁——它只是把”沉默权限”这件事画得最极端的一幅图。

什么时候可以停止追问

如果满足三条，这个傀儡地址不值得继续花时间：你能说出部署者的公开身份（协议工厂或工具项目）；它名下资产来源与你自己的操作记录对得上；它的历史执行全部来自部署者。三条缺一，就升级到多浏览器、归档节点双通道取证收据里的日志也能查账：topics 和 data 怎么反查一笔转账，涉及资产损失再谈报案与链上追踪。链上调查的乐趣与纪律都一样：结构越沉默，越要回到”谁、何时、被谁调用”这三个不会说谎的字段。

风险提示：合约结构本身中性，既能做模板也能藏风险；遇到无法定性的地址不要向其转入资产或签名授权，本文不构成投资建议。