Title: ERC_7811__Wallet_Asset_Discovery
Category: ERCs

Author: lukaisailovic
Date: 2024-11-09T20:55:52.976Z

JSON-RPC method for wallets to share a user’s complete asset list with Dapps, including assets not easily discoverable through on-chain information alone.
https://github.com/ethereum/ERCs/pull/709

Author: SamWilsn
Date: 2024-12-09T18:07:31.872Z

requiredAssets is an optional field that specifies only the assets Dapp cares about on the specific chains. If it is provided, the response from the wallet SHOULD include those assets.

The name requiredAssets paired with a “SHOULD” requirement is a little weird.

Author: lukaisailovic
Date: 2024-12-14T10:12:11.662Z

@SamWilsn The use case is that if the dapp only needs a certain few assets, the wallet shouldn’t return everything it has. However, if dapp requested the asset and user doesn’t have it (wallet has nothing to return), it still shouldn’t fail the request.
What do you think, is there a better way to handle it?

Author: SamWilsn
Date: 2024-12-16T15:22:50.998Z

I would just name it differently in that case. Something like onlyAssets or assetsFilter maybe? My complaint is only about the name, and not the functionality.

Author: lukaisailovic
Date: 2024-12-16T15:50:36.760Z

Thanks a good point, I’ll update the name!

Author: montycheese
Date: 2025-01-14T19:22:40.224Z

What’s the expected behavior if requiredAssets is not provided? As an app developer I’d likely want a way to fetch all of the assets contained within the wallet (that the wallet is aware of)

Author: montycheese
Date: 2025-01-14T19:40:10.260Z

Also what if this allowed requesting assets for multiple wallet accounts in the same call to save on number of confirmation screens?
e.g.
type WalletGetAssetsRequest = {
  params: [{
    account: Hex;
    requiredAssets?: Record<Hex, Hex[]>;
   }]
};

Author: ajhodges
Date: 2025-01-15T19:11:46.519Z

Hey! Wanted to chime in with some feedback after a review of the current proposal:
Some concerns:

it’s not paginated, this asset list could get extremely long
the filter isn’t very powerful; i.e. if I only care about ERC20s, there’s no way to request only erc20s (if you dont care about NFTs)
we might also want an optional spam filter (i.e. a wallet would filter spam assets by default, but the caller could request an unfiltered list)
the NFT balances aren’t aggregated by collection, which can put a lot of work on the client to attempt to go through and aggregate them for display purposes

Author: lukaisailovic
Date: 2025-01-16T15:12:37.024Z

Good point! Added clarification in the spec

Author: lukaisailovic
Date: 2025-01-16T15:17:04.493Z

Also what if this allowed requesting assets for multiple wallet accounts in the same call to save on number of confirmation screens?

@montycheese batching is something that can be added to basically any RPC call out there atm. I think the batching should be solved at the top level and should work with any call, not in the call itself.

Hey! Wanted to chime in with some feedback after a review of the current proposal:
Some concerns:

it’s not paginated, this asset list could get extremely long
the filter isn’t very powerful; i.e. if I only care about ERC20s, there’s no way to request only erc20s (if you dont care about NFTs)
we might also want an optional spam filter (i.e. a wallet would filter spam assets by default, but the caller could request an unfiltered list)
the NFT balances aren’t aggregated by collection, which can put a lot of work on the client to attempt to go through and aggregate them for display purposes


@ajhodges
Agree regarding the pagination. We’ve been discussing this for some time now and none of the solutions feel pretty. Still will probably need to be solved.
For other stuff, I don’t think it needs to be solved at the RPC level. You can just filter/group on the client side. It seems pretty simple. Would be curious to hear your take on why do you think wallet should do it rather than the client

Author: ajhodges
Date: 2025-01-22T15:24:19.372Z

lukaisailovic:

Agree regarding the pagination. We’ve been discussing this for some time now and none of the solutions feel pretty. Still will probably need to be solved.
For other stuff, I don’t think it needs to be solved at the RPC level. You can just filter/group on the client side. It seems pretty simple. Would be curious to hear your take on why do you think wallet should do it rather than the client


I’m thinking of use cases beyond the typical browser extension wallet → browser app. i.e. a server-based wallet. Loading thousands of token balances in a single request is likely going to be very slow/unreliable. Think of a worst-case scenario wallet like vitalik.eth that has hundreds of legit tokens in it and thousands more spam tokens. This is what we should design for. IMHO this means the request should have flexible filters and pagination.

Author: lukaisailovic
Date: 2025-01-22T18:44:32.368Z

ajhodges:

I’m thinking of use cases beyond the typical browser extension wallet → browser app. i.e. a server-based wallet. Loading thousands of token balances in a single request is likely going to be very slow/unreliable. Think of a worst-case scenario wallet like vitalik.eth that has hundreds of legit tokens in it and thousands more spam tokens. This is what we should design for. IMHO this means the request should have flexible filters and pagination.


Agree regarding pagination, that’s a must-have. It will be added.
Curious how would you solve the filtering issue? For example, it can also be assumed that the wallet would filter the spam tokens anyways and would not send them back to the client.
There are two options IMO:


Define a few filters like, onlyTokens, onlyNFTs, noSpam etc and wallet MUST implement them when indicating support for 7811


Have something more open-ended like capabilities, but then say if the filter is provided wallet SHOULD reflect that in the response.


Also keep in mind that this will probably not be used directly by the client. It will be wrapped in a library/SDK first, like we don’t use any RPCs directly today really.
Would love to hear your thoughts

Author: ajhodges
Date: 2025-01-22T19:03:04.227Z

I think I lean towards having some sane filters defined in the spec vs leaning on a capability approach. I would think a capability-per-filter would lead to fragmented support and diminish the overall usefulness of filters in general.
The assets filter is one example that’s already defined in the spec. I could also see a ‘assetType’ filter, ‘spam’ filter, ‘chain’ filter
i.e.
{
  "account": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
  "assetFilter": {
    "0x1": ["0x456", "native"]
  },
  "assetTypeFilter": ["ERC20", "native"],
  "chainFilter": ["0x1"],
  "spamFilter": true
}

Maybe spam filter could be an optional one? Though I feel like most wallets have spam filtering in place these days

For example, it can also be assumed that the wallet would filter the spam tokens anyways and would not send them back to the client.

I 100% expect wallets to filter spam by default, I am just thinking of the case where a dapp may want to request unfiltered asset ownerships to avoid wallets flagging false positives. Maybe this isn’t a thing though

Author: lukaisailovic
Date: 2025-01-22T19:18:49.283Z

I think we should drop the spam filter. I can’t see a use case where the dapp would want spam tokens.
Aligned on the other stuff!
Currently we have this in the spec

If the assetFilter field is provided and the assets array is empty, the wallet MUST restrict results to the requested chains and SHOULD return all assets on those chains.

Kinda like chainFilter, but having explicit field for that is much cleaner.
edit: actually even the statement in the spec is incomplete, its missing the part where the client should provide the key (chainId) but can leave out the asset array

Author: lukaisailovic
Date: 2025-01-26T10:07:48.838Z

@ajhodges Updated the spec with included filters. Let me know what do you think