钱包 App 不用打开也能回话：CAIP-345 定义的钱包服务端点

有些请求不需要人

先想清楚哪些钱包 RPC 是「不需要人」的：问钱包支持哪些能力、查一批调用的状态、请钱包预先准备一组调用、问某个地址有哪些资产。这类方法（例如 wallet_getCapabilities、wallet_getCallsStatus、wallet_prepareCalls 和 wallet_getAssets）返回的是查询结果，用户既不需要按确认键，也没有任何授权动作。但在 CAIP-25钱包会话如何申请最小权限？ 描述的会话流程里，这些请求默认仍然发给钱包应用本身，钱包不打开就没法应答，体验上平白多了一段往返。CAIP-345 给这类请求开了一条侧门。

属性长什么样

规范的载体是 CAIP-25 会话属性里的一个键 caip345，值是「钱包服务」数组，每个条目含两部分：methods，一个 JSON-RPC 方法名列表；url，一个 JSON-RPC 兼容的 HTTP 端点，必须支持 POST。它可以出现在 sessionProperties 里，也可以按作用域放进 scopedProperties——写作时该提案要求：出现在 caip345 里的方法必须同时出现在对应作用域的 CAIP-25 会话里，也就是说侧门不能绕过 一份 JSON 说清「哪条链、哪些方法、哪几个账户」：CAIP-217 授权作用域语法 那套作用域声明，只能声明该会话本来就覆盖的方法。同一个方法不得登记两个钱包服务条目；每个方法至多一个权威 URL。

缓存与请求约定

这条规范在带宽上花了不少笔墨。端点可以返回 Cache-Control 头声明可缓存性，应用则被建议把 JSON-RPC 请求的 id 字段固定为 0，提高缓存命中率；URL 里允许带查询参数，用来放认证令牌、连接标识这类必要信息。有意不支持的是自定义请求头：浏览器里自定义头会触发预检 OPTIONS 请求，白白增加带宽和服务器负担，所需参数一律走查询串。对于在内容安全策略里收紧了 connect-src 的网页，规范给出的出路是走一层应用自己或第三方的最小代理服务转发。

回退是强制项

规范用 MUST 规定：钱包必须为所有登记为钱包服务的方法保留本地实现路径，以防对端应用不支持这条协议。换言之，钱包服务端点是加速器不是唯一出口：应用支持时优先走端点，应用把请求直发钱包时，钱包仍要照常处理。这也是它被列为草案期间能被谨慎采用的原因——新旧实现的组合都有确定的行为。

为什么端点和会话要绑在一起

单看 URL 很容易高估这条协议的能力：端点是钱包方（或其委托的第三方）运营的黑盒，如果没有会话层约束，任何拿到 URL 的应用都能随便查询。规范把绑定写死在两处：其一，方法必须已在 CAIP-25 会话的作用域里声明过，端点只是换了应答通道，不能凭空扩权；其二，作用域属性（scopedProperties）意味着 eip155 作用域下登记的端点不会被拿去应答其他命名空间的方法。审阅钱包连接弹窗时若出现带 caip345 属性的会话，可以把它翻译成一句人话：这些查询不必等我打开 App，由某个网址代答，查询范围不超过本次授权。URL 本身是否可信、令牌会不会经查询串留在日志里，属于钱包方的实现责任，也是这条协议被审计时最常问的两点。

排障时先分清哪条通道

体感层面，这条协议改变的是「查询卡住」时的排查路径。过去钱包没打开，应用里的资产列表就空白一片，你不知道是网络问题还是钱包问题。有了登记端点后，同一个空白的可能原因多了一条：端点侧故障。实用的区分动作是：先看应用有没有把该请求改走外部 URL（浏览器网络面板里能看到对钱包服务域名的 POST），如果请求发出去了但超时或报错，问题在端点或其依赖的索引服务；如果应用根本没发外部请求、只在等钱包回执，那是钱包本地通路的问题，把钱包 App 打开通常就能推进。另一端，钱包开发者自查这类故障时要同时验两条路径都还活着——只测端点会漏掉回退分支，回退分支坏了对不支持本协议的老应用就是破坏性故障。该提案为草案（Draft），2025 年 2 月起草、6 月更新，落地程度取决于具体钱包 SDK。用户视角值得记住的是一条安全边界：走端点应答的都是查询类方法，签名、发送交易这类需要用户动作的方法不在此列，若某个应用的文案暗示「后台端点替你签了名」，那是与规范设计相反的红旗。本文仅作协议说明，不构成投资建议。