I support making this method support arbitrary asset types. It would, presumably, include the asset type identifier (e.g., ERC20, ERC777, ERC721, etc.) and an object that includes parameters specific to that asset type. If the wallet understands the referenced asset type, it will proceed to parse the object for details.
The method would return an error if it doesn’t understand the asset type (error response structure should be well defined so they are easy to switch on in dapps) and if the provided parameters don’t match what is expected for the asset then it would similarly error.
There may be value in creating a workflow (similar to how BIP does SLIPs) for getting new asset types registered (with their associated parameters structure).
On first glance that feels very Metamask/wallet specific, and not necessarily something a client (like Ganache or geth) should implement. Would it be better to create a new prefix, perhaps something like metamask_watchToken or wallet_watchToken?
I totally agree, and in fact we’ve already updated the EIP to reflect that change. I’ll now edit the subject post, too. (Was initially eth_watchToken, is now wallet_watchAsset, for those viewing after edits).
I got pointed here after trying to get my BorisCoin added to MetaMask via Github PR, but I don’t have a “reputation” on EtherScan, so watching this with interest
Is the flow something like:
User visits BorisCoinDotClub with web3 enabled app
BorisCoinDotClub prompts web3 provider to “track BorisCoin” or similar
User accepts and web3 provider adds to wallet
Another thought is that this might be combined with receiving tokens in some way, but not sure how that would work.
Yes, the flow will be very much like that. I’ve made a simple general purpose token-adding app that people can use for suggesting their tokens (only works with our current develop branch, you can pull a recent build like this one or take my word for it):
I like this idea for a new RPC endpoint / method! Is the proposed name wallet_watchAsset / web3.wallet.watchAsset or eth_watchAsset / web3.eth.watchAsset?
The RPC-type method would be wallet_watchAsset, MetaMask is initially releasing it namespaced under metamask_watchAsset. Generally, the web3.js library exposes underscored namespaces as objects, so that would imply web3.wallet.watchAsset, although this EIP reflects no official endorsement from web3.js, nor would any RPC provider be required to implement this method, since it would really only be useful at the signer/wallet layer, hence the wallet_ namespace.
We’re trying to make wallet_ happen, because for too long it’s been confusing when things were under eth_ whether they required a signature or not. Like eth_sendTransaction versus eth_sendRawTransaction. The namespace does not reflect the fact that one requires a signature and the other doesn’t, which is a large fundamental difference.
Hello,
I first heared about this EIP at Devcon when metamask presented it’s implementation and I was wondering about the hability to expand the watchAsset capability beyound ERC20 and ERC721 tokens.
I am developping smart contracts that contain an (ERC20 based) Escrow. Users can deposit tokens to the escrow using the “allow-deposit” scheme of ERC20. This increases the user balance. This balanced can be withdrawn. In the operation of the Escrow, the balanced can be locked. The locked stake will either be returned of seized depending on the users actions.
My escrow has therefore a viewAccount(address) method that returns 2 uint256 (called “stake” and “locked”). I was wondering if there is any way to have these watched using an extension to EIP747. I’m not aware of any EIP that discusses the API of escrow smart contracts, but that might be a first step.
That’s a very interesting and unique use case, probably meriting a fresh thread.
We are definitely planning to expand this method to include ERC721 tokens, and as you can see, we’ve kept the image rendering logic fairly open ended. Maybe once we have ERC721 support, we devise some image display logic that allowed us to render that given escrow’s contained balance.
If that seems hacky, I’m sure we could also do other things, like making escrow its own type, although I’m certain this will be slower to get all the wallets to implement (we have a long list of “asset types” that we want to integrate, so finding common types is key to getting us to cover bases).
@danfinlay there’s a UX problem that this spec does not adequately address: when the user has already added the asset (manually or through wallet_watchAsset), there should be a way to avoid asking them to add it repeatedly in a dApp.
IMO, this would be best achieved by specifying that a wallet_watchAsset should not prompt the user in case the asset is already monitored by the wallet, instead silently reporting success. This way a dApp could detect that the user has some tokens of a specific type and prompt the user to add it, which would just be a no-op in case they have already added these.
I had also thought it might make sense to grant some sites (like etherscan, or whatever registry you prefer) permission to freely update your token list, and maybe even read from it (possibly as a separate permission).
@danfinlay@phraktle Are there any news about this feature(checking if a token already exists in Metamask)? Now it’s like very tricky for me to know that info, I must store flags in localStorage… But if localStorage is deleted or browser/machine changed, that user must again confirm the token. Or when token is manually deleted in Metamask, localStorage must be deleted. And further “Add Token” popup is not showing explicitly every time, user sometimes must go to the Metamask and only then see the popup. Additionally I must save one flag for each account. So to much complications I think, this can be very useful feature…
I think that a page should not automatically request to add token, instead a user action should be needed, so user have to press something to request add token. Otherwise it might become a vector of phishing, e.g. user open a page it starts requesting to add fake tokens. WDYT?
While I understand your point, I don’t think it makes a huge difference. A user confirmation popup is requested already. A scammy website could still force the popup onto the user and scam them this way.
If a website shows many popups unrequested, it’s fairly likely a user will just exit anyway. Popups are an annoyance on any website. Abusing this is likely to get the browser tab closed anyhow.
I guess this is one of the rationales behind the wallet requiring a unique Symbol for each token added?
Well wallets can still cache, but yes I agree there’s a privacy leak through the image URL.
I agree a multiformat/cid is a better thing to use, as the user can provide their own method of accessing it that could be more privacy-preserving.
I think this is an interesting idea, but I don’t think a permissions request is less secure for loading on page load. I do think there’s some benefit to requiring user interaction, but as a browser extension I don’t have the ability to enforce this, and neither would a library-based wallet like WalletConnect, so that particular feature will need to be reserved for full browser manufacturers.
