---
eip: <to be assigned>
title: Add wallet_watchAsset to Provider
author: Dan Finlay (@danfinlay), Esteban Mino (@estebanmino)
discussions-to: https://ethereum-magicians.org/t/eip-747-eth-watchtoken/1048
status: WIP
type: Interface
category: Interface
created: August 13, 2018
---
<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
A method for allowing users to easily track new assets with a suggestion from sites they are visiting.
## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->
Web3 JavaScript wallet browsers may implement `wallet_watchAsset()` to allow any website to suggest a token for the user's wallet to track.

Another open question: Would we want the method to declare the format of token being suggested? ERC-20 is old and dated, and we should be looking forward.

What if instead, the method was eth_watchAsset, and included a format field to describe the asset being added (like erc-20, or erc-721, even!).

A bit more on NFTs

I don’t want to go too deep down the 721 rabbit hole, but just thinking ahead a bit:
One thing NFTs require is a special way of looking up their individual images. Adding an NFT might also include a short template string, highly restricted, that instructs the client on how to add the given NFT to the user’s wallet.

That feature might require an additional parameter, or maybe we should just pack more of these into a big, unordered options object. Ordered params are annoying anyways.

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).

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):

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).