ERC-8199 沙盒智能钱包：给高频代理划一间隔离房，房东钥匙始终在手里

让程序替你执行交易，最常被推荐的方案是会话密钥或共享账户密钥，但两类方案都有一个共同的心病：代理和房东之间有一条随时能出事的通道——密钥泄露或被滥用，资金可能直达核心账户。ERC-8199（Sandboxed Smart Wallet）换一个拓扑：干脆给代理盖一间隔离房，房子和主金库物理分开，房东手里只留一把能随时进屋的门锁。按以太坊 ercs 仓库的记录，这份提案状态为 Draft，创建于 2026 年 3 月 19 日。

Agent 结构体就是权限合同

标准的接口以一个结构体为中心：每个 Agent 由代理密钥 agentKey、一个打包了有效起止时间（validAfter 与 validUntil 各占 128 位）的 validityTimestamp，以及一串 Check 检查器组成；每条 Check 指定一个目标合约地址 to 和一段 termsData 条件数据。registerAgents 只能由房东调用，登记成功发 AgentRegistered，若同一密钥已有活跃登记则回滚——防止悄悄覆盖现行权限；removeAgents 同样只有房东能动，且标准写明即使代理的时间窗已过期也必须能成功移除并发 AgentRemoved，不留僵尸条目。getAgents 返回全部代理而不做时间过滤，审计者拿到的是完整名单，是否生效由调用方自己对照时间窗——isAgentActive 则回答”此刻可用吗”这个即时问题。

时间窗与逐合约条件的组合，语义上等于一份有期限、有范围的委托书：这个密钥只能在这个时间段内、对列出的那些合约、按 termsData 声明的条件动作。

执行路径的三道闸

沙盒的精髓在执行流。代理发起的操作走 invokeAgentExec，先经 preCheck：合约逐一执行登记在册的检查器，任何一条拒绝就把这笔动作挡在沙盒外；动作完成后还有 postCheck 做事后校验，比如核对头寸是否落在预设区间。房东一侧走 executeFromOwner：由房东签名直接执行，随时可以进屋调整、转走资产或更换规则——标准要求房东对沙盒钱包保持完全控制，沙盒限制的是代理，从不限制房东。

这个双通道设计与更早在智能账户里出现过的多签或模块方案的区别，在于”信任半径”：共享密钥方案里，代理密钥泄露威胁的是整个账户；8199 的拓扑下，泄露最多损失这间隔离房里的注资——因为主钱包的资产从未进入代理可触达的权限面。

使用与审查的注意点

与授权、会话密钥并排比较

把 8199 放进既有的委托工具箱里，位置立刻清晰。ERC-20 式 approve 把额度授权交给代币合约，范围限于单一资产、无法表达时间窗，且对所有合约生效的通用授权是钓鱼站最爱骗的签名类型；会话密钥方案在钱包内签一段”某私钥临时代表我”的约定，泄露风险直接落在主密钥体系边缘；多签要求每笔动作凑齐人数，自动化无从谈起。8199 的差别是把委托做成一个独立合约实例：资产真的注进沙盒钱包自己的余额，代理签名只在这个实例内有效，时间窗与逐合约检查器写在链上状态而不是某个链下策略服务器，房东通道与代理通道在合约层物理分开——代理密钥泄露，攻击者能做的极限是在剩余时间窗内、限于登记合约与 termsData 允许的范围内消耗沙盒余额，碰不到房东主钱包。代价同样清楚：资金要预先搬进沙盒才谈得上被策略使用，注资那一步本身走房东通道、多一笔链上成本；而 getAgents 返回全量不加时间过滤的设计意味着安全巡检的责任在工具方，任何显示”当前活跃代理”的面板都要自己套时间窗，读到 AgentRegistered 与 AgentRemoved 事件对不完整的历史更要追问删除失败的原因。Draft 状态的接口仍可能调整，接入前以合约实现为准。

给自动化策略注资前，把 getAgents() 拉出来逐个看三件事：时间窗是否贴合策略生命周期——过期不删的密钥依然是登记表上的攻击面；Check 列表是否覆盖了策略实际需要的合约——多列一个无关合约就多开一个出口；termsData 的内容是否可解释——它按目标合约解释，读不懂的条件等于无法审计的授权。同时确认沙盒余额与主账户的资金桥是单向、定额的，而不是给代理留了一个可随时加宽的龙头。Draft 状态的接口细节仍在变化，接入前以合约实现为准。本文为机制说明，不构成任何投资建议。