网页连上钱包后冒出一句”是否允许本应用为你创建一个新账户”，一些读者第一次遇到时直接拒绝，也有人随手同意。这类请求背后是一个还在草案阶段的接口规范：ERC-7895。它想解决的问题很实际——当一个应用需要单独的链上身份时，让用户逐个手动建账户、再导回钱包，体验糟糕且容易出错。这一篇讲清楚机制、当前状态，以及同意之前该问什么。
它想做的事：钱包替应用生成或接管一个子账户
按 ERC-7895 的定义，钱包可以通过 wallet_addSubAccount 方法响应三种请求：钱包为应用新建一个由自己保管密钥的账户；把一个应用已经生成好签名方式的账户导入钱包跟踪；或者请求把主钱包变成某个已有账户的持有者之一。规范对”子账户”的界定是主账户应当作为其所有者或签名方之一——也就是层级关系：主地址能替子账户动钱，但子账户地址在链上是一个独立账户，有自己的余额和持仓。这与传统的派生路径另开账户思路不同，更接近”应用干活、主钥匙背书”，派生路径层面的账户关系可参考 同一句助记词导入两个钱包会发生什么：地址重合、 nonce 打架与双机纪律。
草案状态：现在有多少钱包真的支持
必须说清楚现状：ERC-7895 在标准仓库中标注为 Draft（草案），不是已定稿的强制接口。这意味着两点。第一，绝大多数主流钱包到今天仍不提供这个 RPC 方法，网页调用会得到”方法不支持”的报错，这属于正常现象而不是钱包坏了。第二，规范细节（参数结构、能力协商字段）在草案阶段仍可能变动，任何教程里写死的行为描述都可能过期。钱包是否支持，以你手上这款钱包的官方文档为准；能力协商按草案设想走 ERC-5792 的 wallet_getCapabilities 查询，应用应先问再请求。
同意之前，值得问的三个问题
其一，这个子账户是合约账户还是普通地址？草案支持两种形态，合约账户意味着有链上部署成本与合约层面的所有权配置，普通地址则只是新生成的密钥对。其二，密钥在哪里？如果钱包说”我来生成并保管”，恢复演练时你会在账户列表里找到它；如果签名方式由应用侧提供，密钥控制权在应用，钱包只是跟踪显示，这两种情况的安全边界完全不同，地址与所有权的基本概念见 生成以太坊地址为什么免费？地址创建与链上激活的区别。其三，谁在承担Gas？子账户通常没有余额，协议若默认应用代付，留意代付方会引导你走哪些流程。
使用场景与理性预期
这个机制适合的场景是清晰的：高频小额操作、给机器人或策略一个隔离资金的操作地址、把不同 dapp 的持仓放进独立账户避免误操作。不适合的是把它当”默认同意”：子账户的每一条转账最终仍由主账户签名背书，权限语义理解错了，等于把主钥匙的授权面越摊越宽。普通用户的稳妥策略是——能拒绝就拒绝，改用钱包自带的多账户功能达到同样的隔离效果；确有需求的，先在小额资产上完整跑一遍创建、使用、资金回迁和恢复找回，再考虑主力场景。
一个常被忽略的问题：备份清单会不会漏掉它
用钱包自带的”添加账户”功能时，新账户由同一句助记词派生，备份助记词就自动覆盖了全部账户；而通过钱包端子账户机制创建的账户，密钥关系不再单纯依赖那句助记词的派生序列——尤其是密钥由应用侧提供的形态，钱包主备份未必能让它在新设备上原样重现。所以真要用这类功能，务必在创建当场问清并记录：这个账户是否出现在钱包的恢复清单里、丢设备后按官方流程能不能找回来、找不到时资金通道还剩哪几条。测试的底线标准就一条：在一台干净设备上走完整恢复，账本里的每个账户都要能重现，任何一个”恢复后消失”的账户都说明当前备份策略有洞，无论它显示的余额多小。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。