Summary: ERC-7811 is best understood as wallet-to-dapp asset-observation infrastructure rather than as a portfolio app API or a simple token-balance helper. Its core move is to standardize how wallets disclose what assets a user owns across chains, including assets that are not easy for a dapp to infer from raw onchain state alone. The important categorization clue is that ERC-7811 changes which party is authoritative about a user’s actionable balance surface: instead of the dapp relying only on chain indexers, the wallet becomes a discovery and ranking layer that can reveal hidden, cross-account, or otherwise hard-to-infer assets.
What it does:
Defines wallet_getAssets, a JSON-RPC method for requesting a user account’s assets from the wallet across one or more chains
Supports granular assetFilter, assetTypeFilter, and chainFilter parameters so dapps can ask for only the assets relevant to a specific flow
Returns a chain-keyed asset map with address, balance, type, and optional metadata fields
Standardizes well-known asset types for native, erc20, and erc721, while leaving room for later ERCs to define additional asset types
Recommends that wallets return all available assets ordered by estimated value when no specific asset filter is provided
Extends the EIP-5792 capability surface by advertising support through the assetDiscovery capability in wallet_getCapabilities
Key claims:
The draft ERC says wallet_getAssets lets wallets share a user’s full asset list with dapps, including assets not easily found through onchain data alone, which is the clearest signal that this belongs in the corpus as wallet visibility infrastructure
The motivation says dapps currently rely too heavily on onchain balance inference and may therefore block actions a wallet could actually fulfill, framing ERC-7811 as a correction to the dapp-side view of user liquidity
The spec says that if assetFilter is present the wallet MUST only return those requested assets, but if it is omitted the wallet SHOULD return all available assets and is recommended to order them by estimated value descending, which gives the wallet meaningful discretion over what asset surface the dapp sees by default
The standard uses a generic string type for assets and explicitly expects future ERCs to define more types, showing that ERC-7811 is trying to become a broad wallet-asset discovery bus rather than a closed ERC-20-only method
The capabilities section says wallets that support ERC-5792 should expose assetDiscovery in wallet_getCapabilities, which places ERC-7811 directly in the expanding wallet capability-negotiation stack
The standard also references CAIP-25 session scopes, indicating that asset discovery is meant to be part of real wallet-session interoperability rather than a standalone informational endpoint
JAW’s provider docs explicitly say wallet_getAssets implements EIP-7811, supports multichain queries, asset filters, and non-authenticated balance lookup for a provided account, which is good evidence that ERC-7811 is already becoming implementation-facing wallet plumbing
JAW’s examples also show practical compromises such as returning only non-zero balances and filtering by SDK chain preferences, which is a useful reminder that wallet-side discovery standards can still concentrate curation power in the wallet implementation
Whitepaper: No standalone ERC-7811 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC, the raw ERC markdown, and JAW’s implementation-facing RPC documentation; see ../../whitepapers/erc-7811-primary-sources-2026-05-07.md.