有些钱包 RPC 方法根本不需要用户动手，却仍要把用户从应用里拽回钱包确认一遍。CAIP-345 允许钱包在会话属性里登记一个 JSON-RPC 的 HTTP 端点，把这类方法改由端点直接应答。本文拆解这个 wallet service 属性的结构、缓存约定、失败回退要求，以及它为什么不收自定义请求头。

登录网站时既要记得钱包、又要记得地址，新用户记不住。CAIP-275 让域名持有者在域名 NFT 的文本记录里放一个 authenticator 字段，指向一份登录流程配置，应用照着配置依次尝试扩展、扫码、通用链接等连接方式。本文拆解这条查找链和配置文件结构，并说明它没有解决的问题。

链上信誉大多靠平台打分，换个平台就得重攒。CAIP-261 提出一套对等信任断言的数据框架：用可验证凭证声明「在某个维度、多大程度上信任某个地址」，正负皆可、附带理由，让信任图谱能跨系统流转。本文拆解它的标识方案、数据模型与取值范围，并说明评分计算为何被刻意留在范围之外。

同一个跨链资产在不同钱包里被当成几个不相干的币，是聚合资产视图老大难。CAIP-390 用一份最小 JSON 模式统一名称、精度、图标、链接，并用 locations 字段以 CAIP-19 标识登记同资产在各链的分身合约。本文逐项拆解字段约束、受控链接词汇与消费方必须自查的三件事。

网站登录时让你签的那条消息，装进什么容器传来传去？编号 74 的链无关协议给出 CACAO 能力对象：头部加负载的两层结构、did:pkh 签发者标识、按 EIP-191 或 EIP-1271 提示验签，再用 CBOR 与 CAR 做确定性序列化和传输。本文按原文拆解字段表、能力链回传机制与新旧头部兼容，并说明它当前的规范状态。

交易哈希抄错一位就前功尽弃，于是有人提议直接报「区块高度加块内序号」的位置坐标。编号 136 的 TxRef 用 Bech32m 编码把比特币交易的位置写成人能抄的短串，但原文自己强调这是弱关联：重组时位置可能指向另一笔甚至空位。本文拆解 TxRef 的编码结构、六个确认数以下不得展示的显示纪律，以及把它换回交易哈希的交叉核对方法。

可验证凭证和 DID 讲清了链下身份的骨架，但钱包在这条链路上该暴露什么接口？编号 169 的草案给出一族 wallet_creds 前缀的方法：store 存、verify 验、issue 签发、present 出示、metadata 报能力，其中 issue 的方向特意反转——由钱包反过来调用应用。本文按原文拆五个方法的参数、错误码与出示交换用的表示交换数据模型，并交代它与特性发现流程的依赖关系。

命令行脚本、部署机器人和 AI 代理要用钱包签名，浏览器那套多钱包发现机制在终端里没有对应物。一份尚未编号的 CLI Wallet Protocol 草案把 git 凭证助手的模式搬了过来：钱包厂商提供 PATH 上的可执行文件，操作走标准输入输出 JSON，配零到六号语义化退出码，再用带限额与限频策略的会话让代理在人类一次授权后自主操作。本文拆解操作约定、时间预算与会话边界。

同一份钱包签名，怎么在离线校验、索引服务和多条链之间引用同一个标识？编号 380 的便携证明协议给了一个答案：把五个核心字段做确定性 JSON 序列化，用 SHAKE-256 算出 32 字节的 qHash 锚点，验证方离线验一次、到处引用。本文拆解规范子集字段、六行签名消息、五分钟时效窗口与 EIP-191 到 1271 再到 6492 的三级验签顺序，并明确它不是登录协议。

钱包与网站建立会话时，除了约定「开放哪条链、哪几个账户、哪些方法」，还有两件常被默认拍板的事：RPC 接口以哪个版本文档为准，请求实际路由到哪些节点。编号 211 的草案把这两件事写进授权作用域里的 rpcDocuments 与 rpcEndpoints 两个有序数组，配 assumed、implicit、explicit 三层取值模型与冲突时按数组顺序定优先级的规则。本文拆解语法与安全考量。