ERC-7811 introduces wallet_getAssets, a JSON-RPC method for wallets to report a user's complete asset holdings to dApps. Wallets return balances across chains and asset types (native, ERC-20, ERC-721), including assets not easily discoverable through on-chain indexing alone.
Dapps currently guess user balances from on-chain data, missing cross-chain assets or restricting actions the wallet could actually complete. This lets wallets share their knowledge of user holdings, enabling smarter UX that accounts for total available assets rather than just current-chain balances.
This ERC introduces a new RPC call, wallet_getAssets, for wallets to declare to the Dapp what assets are owned by the user. This allows for more accurate asset discovery and the use of assets that aren’t available on-chain but can be provided by the wallet
Currently, Dapps primarily rely on on-chain data to determine a user's balance, which can be limiting. Furthermore, a Dapp might restrict the user from initiating actions that the wallet could otherwise resolve, as it cannot account for the total assets a user has across different accounts or chains.
Wallets already have information about a user's assets, including those not visible on-chain, and need a way to communicate that information to Dapps.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
wallet_getAssetsaccount is a REQUIRED field that indicates for which account assets are requested.
assetFilter is OPTIONAL field that accepts a list of assets identifiers. Each asset identifier is an object that contains address and type fields and is scoped by chainId, where ChainId MUST be a valid EIP-155 chainId.
If the assetFilter field is provided, the wallet MUST only return the assets specified within it, even if assetTypeFilter or chainFilter could have further filtered the result. This effectively disregards the assetTypeFilter and chainFilter fields entirely. The reason for this is that they are already implicitly defined within the assetFilter.
If the assetFilter field is omitted, the wallet SHOULD return all available assets for the requested account. It is RECOMMENDED that the returned assets be ordered by estimated value in descending order, as determined by the wallet.
assetTypeFilter is an OPTIONAL field that specifies an array of asset types, as defined in this ERC. If assetTypeFilter field is provided, wallet MUST include only assets with those types in the response.
chainFilter is an OPTIONAL field that specifies an array of chain ids, where each value in the array MUST be a valid EIP-155 chainId
Consumers of wallet_getAssets SHOULD set assetFilter, assetTypeFilter and chainFilter with as granular as reasonably possible values. For example, if an app is only interested in interacting with a single token on a single chain, it should provide filters for this. Doing this both ensures that wallets and the underlying infrastructure do not incur excessive cost, as well as significantly increased performance to client applications.
The key MUST be EIP-155 chainId
Asset fields:
address is the address of the asset as Hex or native string for native assets.
balance is the balance of the asset as Hex
type: A string indicating the type of the asset. Common asset types include but aren’t limited to:
metadata: An OPTIONAL object containing additional information about the asset. The specific fields within the metadata object may vary depending on the asset type and the wallet's implementation.
Below are expansions of metadata for well-known asset types. Implementations that are compliant with this ERC and return these well-known asset types MUST return at least these fields in metadata. Implementations MAY return more fields than specified here.
This ERC does not specify an exhaustive list of asset types.
Since the type is a generic string, there could be a mismatch between the type Dapp expects and the one returned by the wallet.
It’s important that no two assets share the same type.
Therefore, new asset types should be specified in future ERCs.
Native
Example:
ERC-20 Token
Example:
ERC-721 Token
Example:
If the wallet is using CAIP-25 authorization, wallet SHOULD include wallet_getAssets in the methods array in sessionScopes of eip155 namespace.
If the wallet supports ERC-5792 wallet SHOULD respond on wallet_getCapabilities request using the assetDiscovery key. Value should be an object with supported key and value true
Wallet SHOULD include this for every chainId.
Copyright and related rights waived via CC0.