交易里的 calldata 只是一串十六进制，钱包要把它显示成你看得懂的操作，靠的是合约 ABI。EIP-7896 提议让应用在批量调用请求里直接附上 ABI，钱包不必到处找接口。本文解释这条解码链路、接口附件的信任边界，以及看到模糊弹窗时该做什么。

EIP-5792 的批量调用给人“要么全成要么全败”的印象，但提案 EIP-7867 提出 flowControl 能力，允许应用主动把批次从严格原子降级为宽松模式，并逐条设置失败后继续还是停止。本文按原文讲清 strict 与 loose 的差别、rollback、halt、continue 三个动作，以及降级后用户要多防什么。

批量调用接口里通常是钱包替你签一整包操作。ERC-7836 反过来：应用先向钱包要一个待摘要，自己签好，再让钱包照着执行。本文按草案原文讲清 wallet_prepareCalls 与 wallet_sendPreparedCalls 的往返、密钥类型参数、钱包端必须做的核验，以及用户在这种新模式下应重点盯什么。

网页与钱包之间的请求可能被注入脚本或恶意扩展中途篡改。ERC-7754 提出 TWIST：应用用域名绑定的私钥给请求签名，钱包经 DNS 清单取公钥验签后再处理。本文按原文拆解信任链、两小时缓存窗口与它挡不住什么。

有些钱包能动用的资金不止链上可查的那份：法币入金、多账户调度都可能补齐缺口。ERC-7682 定义 auxiliaryFunds 能力，让钱包在能力查询里声明这种额外资金来源。本文按原文拆解声明格式、requiredAssets 参数与对余额判断的实际影响。

个人消息签名、结构化数据签名、带验证者的签名，过去各走各的 RPC 方法。ERC-7871 提出 wallet_sign，用 EIP-191 的版本字节区分三类请求，并接入能力协商。本文按 ERC 原文拆解参数结构、地址约束与现状边界，并说明用户侧核对方式不变。

网页连接钱包过去要拆成好几步：先要地址，再可能要登录签名，再单独协商附加功能。ERC-7846 提出 wallet_connect 与 wallet_disconnect，把连接、登出和可选能力装进一次协商。本文按 ERC 原文讲清它连接口换法、返回什么、用户要多核对什么，并明确它仍是草案。

同一句调用失败可能来自 HTTP、JSON-RPC 与钱包 Provider 三个层。本文按 JSON-RPC 2.0 与 EIP-1193 的官方编号表拆解 -32700、-32601、4001、4900 等错误码的责任边界与各自的正确处置。