wallet_getAssets 是什么：让钱包替应用回答“你有哪些资产”

一句话理解

ERC-7811（Wallet Asset Discovery，2024 年提出，仍是草案）增加的不是合约函数，而是一个钱包 JSON-RPC 方法：wallet_getAssets。应用向钱包提问“某个地址有哪些资产”，钱包返回一份按链分组、带类型和余额的清单。标准文档给出的定位写得很直白：让钱包把它已经掌握的资产信息告诉应用，包括那些只靠链上数据不容易发现的资产。

这里的机制要点是：资产清单不是从合约里读出来的，而是来自钱包这一层。

请求和响应长什么样

请求必须带一个 account 地址；三个可选过滤器——按链限定具体资产地址与类型的 assetFilter、按资产类型过滤的 assetTypeFilter、按链号过滤的 chainFilter，链号必须是符合 EIP-155 的合法链 ID。规则里有几条硬约束：给了 assetFilter 时，钱包必须只返回其中列出的资产，其余过滤器字段实际被忽略（因为信息已经隐含在里面）；不给时，钱包应当返回该地址全部可用资产，并建议按钱包估计的价值从高到低排列。文档还建议调用方把过滤条件设得尽可能精细，以免钱包和基础设施承担不必要的开销。

响应是“链号到资产数组”的映射，每项资产含地址（原生资产写作 native）、余额、类型和元数据。类型字段的常见取值是 native、erc20、erc721，并明确允许扩展到其他字符串。

与钱包其他能力的衔接也写了：如果钱包用 CAIP-25 授权，应当在会话作用域的 methods 里带上 wallet_getAssets；如果支持 ERC-5792，则在能力查询响应里给每条链加上 assetDiscovery 为支持的标记。

为什么它落在钱包层

链上资产发现主要靠扫事件日志：扫 Transfer 到某地址，再逐个合约取元数据。这套办法对常见标准可靠，但总有例外——批量事件型铸造、跨链资产、尚未上链但钱包已知的资产。钱包早就知道这些信息，只是原先没有标准化通道把它交给应用。标准文档的动机部分还提到另一半价值：应用因为看不见用户全部资产，会限制用户发起某些其实钱包能解决的操作。

信任边界要讲清楚

这条方法给应用带来的不是链上事实，而是钱包的自我报告。所以它的价值主张“更准确的发现”伴随一个新的信任点：应用如果无条件相信钱包返回的清单，就等于把余额判断交给了钱包软件。规范的动机部分明确说这份清单“包含链上不可用的资产”，意味着它是给交互体验用的，不是权属凭证。

对普通用户的三点提醒：应用展示“你的某个 NFT 符合条件”只是筛选提示，真要用某资产时仍应以被查询合约的真实归属为准；钱包版本与实现不同，同一账户在不同钱包里给出的清单可以不一样；这个能力目前支持的钱包和应用都还不多，看不到相关功能不代表资产有问题。

对技术读者：这条标准对 ERC-721 与 ERC-20 有依赖声明，也和 ERC-5792 的能力协商配合使用，评估具体钱包实现时看它是否声明了上述支持标记。

支持声明与查询开关

草案还把这项能力接进了钱包的协商机制。走 CAIP-25 授权的钱包，应当在会话作用域的 methods 数组里把 wallet_getAssets 列出来，让应用在建会话时就知道能问这个问题；支持 ERC-5792 批量能力查询的钱包，应当在每条链的能力响应里带一个 assetDiscovery 键，值为 {"supported": true}。对应用开发者，这意味着体验可以这样组织：先查能力，支持才发起资产发现；不支持时回退到传统的链上扫描，而不是直接假设用户没有资产。过滤参数也被建议尽量精细——只要某一链上某一种资产的话，就把过滤器写成那样，既省钱包的开销，也让响应更快。

风险提示：本文为标准机制科普，不构成任何投资建议；资产归属以链上合约状态为准，钱包返回的清单仅反映钱包侧的数据视图。