This is a proposal targeting wallet API standardization: a new JSON-RPC method wallet_getOwnedTokens, for retrieving a selection of owned tokens by an Ethereum address, with the owner’s permission.
There are financial dApps that require a list of owned tokens 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 tokens (smart contract addresses, ABIs) and retrieve the user’s data from the blockchain, for each token. This leads to effort duplication and nonoptimal UX where the user is presented with either more or less token options than the user would like - various airdrops, incomplete list of tokens kept by the dApp.
Thanks for the initiative! I think the chainId should also be part of this EIP as users can own tokens on different chains. This might also help us on the path to ETH 2.0. I suggest a chainId field in the response and perhaps also one (optional) in the request to filter for specific chainID(s)
Hey Loredana thank you for the initiative! You know I really want this to be standardized
Only comment I got is that we perhaps don’t need the optional fields of symbol, name and icon since the first two would be part of the token contract/abi anyway and the icon would be handled by the dapp and would most probably use something like https://github.com/atomiclabs/cryptocurrency-icons
If you really want them then we could go for more of the optional attributes like the decimals e.t.c.
I don’t see how your suggested spam attack is any more powerful if this proposal were adopted.
In the MetaMask case, we would - in my assessment - implement this without causing any additional Ethereum node queries. Our wallet already maintains lists of owned tokens and would simply return that.
I think this kind of spam attack can be mitigated at the wallet layer, using a token whitelist, which is what MetaMask does today. Just because there is a getOwnedTokens method does not mean the wallet needs to scan the blockchain for all tokens.
For similar concerns, at MetaMask we proposed, implemented, and comply with EIP 747, a method that allows dapps to explicitly ask to list individual tokens in a user’s wallet. We only detect some major known tokens, and we do not autodetect all known tokens, precisely to avoid spammy airdrops.
I would expect getOwnedTokens to only return the tokens that a user’s wallet is already tracking, and to not invoke additional scanning of the blockchain.
EIP 747 also is forward-extensible for defining types of assets (it is wallet_watchAsset, not watchToken), and proposes a schema for defining the asset type.
Nice, then the wallet can return an error like (if ERC721 is not supported):
I would just return  instead of an error, to avoid error catches that are not related to the user rejecting the request. What do you say? The purpose of the error for wallet_watchAsset indeed makes sense.
It is slightly more descriptive, but EIP-747 is already using type, so I’m torn between descriptiveness and consistency.
For the sake of forward-extensibility. ERC-20 and ERC721 may have all of those parameters in common, but a subscription might have very different features, for example. For this reason, we isolated all of the interface-specific parameters into an interface-dependent options object.
The current request proposal, with the optional filter arguments looks like this:
"justification": "Select up to 10 frequently used tokens and we will tell you what services accepted them as payment."
I imagine an ongoing permission can work with wallet_getOwnedAssets:
dApp requests ongoing access to all assets and user agrees.
dApp requests ongoing access to all ERC20 & ERC721 assets and user agrees.
dApp requests ongoing access to all ERC20 & ERC721 assets and user only wants to grant access for some assets. In this case, the wallet needs to remember what assets were chosen. Indeed, a bit more work for the wallet.
I think this API is a little clearer if we distinguish two methods, one for ongoing usage, and one that initiates a specific selection.
It might help me imagine how you’re proposing these are compatible by giving hypothetical code for how the extended permission would be granted.
For example, today under the current wallet permissions proposal, any method that hasn’t been granted permission using requestPermission would get an unauthorized 4001 error. Would you suggest that some methods, like this, might instead trigger confirmations on each request instead?
I think I slightly prefer them being separate methods, for the sake of a simpler implementation for the wallet, but I understand that an ideal interface should dictate implementation, not the other way around.
Item 3: I think making more-specific attenuations is always a good feature, and wallets could always add this enhancement as they are able to, so it doesn’t need to block the proposal.
Hi, i am facing the same issue - when trying to use the “wallet_getOwnedAssets” I still see it does not exists inside “window.ethereum.requests” API. Can anyone at Metamask team give us a realistic implementation deadline for this long awaited feature?
also what are the other work arounds for now? how do dapp developpers manage to check if a Token is already in the “watchlist” of a user’s wallet? and if it is not then triggering the “wallet_watchAsset” methods?