链上偶尔能碰到一种奇怪的地址：合约代码确认已部署、谁都能查，但它对外几乎不响应任何调用；奇怪的是它的余额和持仓又会突然变动。ERC-7613 给这种形态起了名字——木偶合约（Puppet）。提案在 2024 年 2 月登记，按 2026 年 8 月 26 日核验仍是草案状态。这份规范想解决的问题在 NFT 场景里并不罕见：一个地址收到了转进来的藏品或代币，但这个地址本身不会主动发起任何交易，收进去的东西按理说就没人动得了——木偶合约就是给这类地址配的一根提线。
机制按规范原文可以缩成两句话。正常情况：任何人调用这个合约，它表现得像一个普通外部账户，什么都不做、没有任何接口。例外情况：调用者是部署它的地址时，合约把调用委托给 calldata 里带进来的目标地址执行，于是部署者可以在木偶的地址上下文里跑任意逻辑。翻译成人话：同一个地址有两副面孔，公众面前是空壳，部署者手里是提线木偶，资产在木偶名下时，只有部署者有能力把它们操作出去。
它和传统代理合约的区别值得单列。ERC-1967 那类透明代理是所有调用者都会看到同一张转发脸，转发目标写在约定的存储槽里、可以被区块浏览器识别展示；木偶恰恰相反，转发只服务一个调用者——部署者——而且转发逻辑不对外暴露接口，浏览器看到它就是一段极简代码。前者的设计目标是可发现与可验证，后者的设计目标是行为最小化，两者对审计工具友好度完全不同，这也是草案状态迟迟未定的原因之一：标准要解决的正是这类地址既有用又有识别难的问题。顺带解释一个术语：调用数据就是随交易一起发进合约的那串编码参数，规范特意把转发目标藏在它里面，而不是存在合约自己的存储里，这样同一个木偶合约在不同调用里可以指向不同的目标，地址本身不承诺任何固定行为。
对收藏者来说，这类机制出现在两个位置。一处是项目方金库：某个地址收集版税、归集库存，需要定期把资产转到运营地址——给金库地址配一根提线，比让金库自己长出一堆用户可见接口少出漏洞的机会。另一处就是前面说的存款地址场景：交互把 NFT 转到一个不会用钥匙的地址，能取回的只有掌握部署权的那一方。理解到这里，核对清单就出来了。
第一步，在区块浏览器看这个地址的代码标签：显示为木偶类合约的，重点看部署者是谁、部署交易的来源。第二步，读部署记录：提线在谁手里，资产的实际处置权就在谁手里，这句话在审计意义上等于把信任问题从地址转移到部署者地址。第三步，看历史操作：每次资产被操作出账时，发起方是不是部署者地址、目标合约是什么。三项查不出矛盾的，机制说明就闭环了；任何一项查不了（例如部署者未验证、历史被批量清空），风险评价直接上调。
最后放一条通用提醒：一个地址没有公开接口不代表它持有资产就安全或危险，它只代表控制权被收拢到了少数人手里。判断标准从有没有接口变成对部署者的信任——而信任的替代品不是更漂亮的界面，是部署者地址的可归因性、操作历史的透明度和操作权限是否多签。这份提案目前仍是草案，正式接口在定稿前可能继续修订，引用本文的读者请在链上核对具体实现。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。