This is a proposal for a new JSON-RPC call for retrieving from a wallet a selection of owned assets by an Ethereum address, with the user's permission.
There is no standardized way for a dApp to request a list of owned assets from a user. Now, each dApp needs to keep a list of all the popular or existing assets and check the user's balance against the blockchain, for each of these assets. This leads to duplicated effort across dApps. It also leads to the user being presented with asset options that the user does not care about, from various, unwanted airdrops.
There are financial dApps that require a list of owned assets from a user, for various purposes - calculating taxes, selecting customized payment options, etc. Each of these dApps are now forced to keep a list of popular assets (smart contract addresses, ABIs) and retrieve the user's data from the blockchain, for each asset. This leads to effort duplication and nonoptimal UX where the user is presented with either more or less asset options than the user would like - various airdrops, incomplete list of assets kept by the dApp.
This list of owned assets can be retrieved from the wallet used by the user. The wallet can allow the user to manage only the assets that the user is interested in. Therefore, a new JSON-RPC method is proposed: wallet_getOwnedAssets. This method is complementary to EIP-747, which proposes a way for sites to suggest users new assets to watch on their wallet.
New JSON-RPC method to be added to web3 browsers: wallet_getOwnedAssets. This method is for dApp-wallet communication and only targets the assets that have already been whitelisted by the wallet, for the user account.
Arguments:
address, Ethereum address that owns the assetschainId - type uint, chain id respecting EIP-155; optionallimit - type uint, the maximum number of owned assets expected by the dApp to be returned; optionaltypes - type string[], array of asset interface identifiers such as ['ERC20', 'ERC721']; optionaljustification - type string, human-readable text provided by the dApp, explaining the intended purpose of this request; optional but recommendedResult:
address - type address, Ethereum checksummed addresschainId - type uint, identifier for the chain on which the assets are deployedtype - type string, asset interface ERC identifier; e.g. ERC20; optional - EIP-1820 could be usedoptions - an object with asset-specific fields; ERC20 tokens example:
name - type string, token name; optional if the token does not implement itsymbol - type string, token symbol; optional if the token does not implement iticon- type base64, token icon; optionalbalance - type uint, the number of tokens that the user owns, in the smallest token denominationdecimals - type uint, the number of decimals implemented by the token; optional1) A request to return all of the user's owned assets:
Result:
2) A request to return one ERC20 owned asset, deployed on chainId 1:
Result:
The wallet should display a UI to the user, showing the request. The user can:
If all owned assets are requested, the total number of owned assets will be shown to the user. The user can also choose to select the assets that will be returned to the dApp, amending the request.
If a selection is requested, the user will select from the list of owned assets.
As an optimization, wallets can keep a list of frequently used assets by the user, and show that list first, with the option of expanding that list with owned assets that the user uses less frequently.
In order to avoid duplication of effort for dApps that require keeping a list of all or popular assets and to provide optimal UX, the wallet_getOwnedAssets JSON-RPC method is proposed.
The chainId and types optional parameters enable dApps to provide options in order to restrict the selection list that the user will be presented with by the wallet, in accordance with the dApp's functionality. The limit parameter enables the dApp to tell the user an upper limit of accounts that the user can select. It remains to be seen if a lower bound should also be provided. At the moment, this lower bound can be considered as being 1.
The options response field provides the dApp with asset-specific options, enabling better UX through using the same visual and text identifiers that the wallet uses, making it easier for the user to understand the dApp's UI.
The address, type response fields provide enough information about the asset, enabling dApps to provide additional asset-specific functionality.
The balance response field is an optimization, allowing dApps to show the user's balance without querying the blockchain. Usually, this information is already public.
Not relevant, as this is a new method.
To be done.
To be done.
Copyright and related rights waived via CC0.