余额视图看不到的那部分支付能力
你查余额时看到的是链上可查的那份资产。但有些钱包实际能调动的资金不止于此：可以即时从法币入金通道注入的钱、同一钱包管理的其他子账户里挪过来的资产，都可能在交易执行的瞬间补足缺口。ERC-7682 就是给这种能力一个说法：钱包通过 EIP-5792 的 wallet_getCapabilities 响应声明一个 auxiliaryFunds 对象，告诉应用它拥有链上地址余额之外的资金来源。规范不约束这笔钱的来源形式，原文给的例子就包括链外入金和多账户调度两类。这份 ERC 状态为草案（Draft），声明机制能否被你的钱包用到取决于实现。
能力声明的格式很薄：supported 为 true 表示这条链上有额外资金；可选的 assets 字段用地址数组列出对哪些资产有额外访问权。原文对缺省情况的规定要注意——钱包若不给出 assets 数组，应用应当假定钱包对所有资产都有额外访问权。另一个约定直接借用 EIP-7528：链生币用那个固定的 0xEeee...EEeE 地址表示，而不是写币桥地址或者留空，这条统一记法省掉了很多歧义。
从声明到执行：requiredAssets
仅有声明还不够，应用得告诉钱包这次到底要多少钱。标准允许应用在 wallet_sendCalls 的 capabilities 的 auxiliaryFunds 里带上 requiredAssets 参数，逐项写明资产和数量，钱包据此去做换汇、跨链搬运或入金准备。原文对这一点有两处冷静的限定：其一，声明支持 auxiliaryFunds 的钱包不一定理解 requiredAssets 这个扩展，两者是可分层支持的功能；其二，原生币需求可以从 call 的 value 字段推断，不必在 requiredAssets 里重复声明，这个参数主要是为无法从调用数据推断的代币需求准备的。
为什么需要显式写明？因为复杂调用会牵扯多个合约，光看调用数据很难反推成功执行需要哪几样资产各多少个，猜错的代价是交易上链失败照样烧 gas。把需求写死在执行之前，本质上是给估算多加一层保险。
余额与能力对账的思路并不新：本金、Gas、精度三本账要分开看，参考 钱包余额对不上账？把本金、Gas、代币精度三本账分开勾稽；把额外资金来源算进去，只是让账本多了一行要核对的科目。
用户侧：便利与账本清晰度
对普通用户，这类能力的正面价值很直白：余额不够也能完成操作，不必先手动凑 gas 币再回来操作。反面同样清楚——你手机上的余额页码与钱包实际动用的钱可能不是一回事。如果一笔操作成功了而你的可见余额几乎没变，多出来的钱从哪个子账户挪的、从哪条通道入的账，不会自动出现在交易记录里。这与我们在钱包两本账话题里反复强调的原则一致：链上记录、钱包界面、资金总账是三层不同的账，任何一层说够用都不作数，可以顺带回看 余额对得上、交易记录却是空的？钱包的两本账不在一个地方。
实操上有三个具体动作值得养成：确认多账户钱包的每个子账户余额与用途标签；用涉及法币入金的钱包时，把入金手续费和时间差计入成本，判断标准是完成一笔目标操作从你总资金里真实减少了多少；操作后到账单入口确认资金来源标记。这些核对与接口标准无关，任何钱包都适用。
现状与边界
草案阶段的 auxiliaryFunds 主要在拥抱 EIP-5792 的智能账户与新一代应用之间出现；传统外部账户场景没有代调资金的概念，余额不够就是不够。两条路径的界面差异也在这里：如果某个界面展示余额不足却仍然让操作成功，大概率背后是这类能力或类似机制在工作，不是显示错误。反过来说，任何声称能凭空补足资金、需要你额外授权全部资产来开通的说法，已经越出标准设定，应立即停止操作并复核请求内容。
风险提示
本文只解释标准机制与对账思路，不构成投资建议，也不推荐使用任何具体资金调度功能。动用额外资金的操作同样不可撤销，资金来源不清时先小额验证；对余额与账单的疑问应以区块浏览器和资金平台的正式账单为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。