New Web3 Provider Method: eth_watchToken

[danfinlay]

Today, most web3-compatible browsers have a notion of watching tokens, usually to help a user watch their current balances of tokens.

While it is possible to derive an account's token balances by walking the full history of the blockchain, this is especially impractical in the context of light clients, and so users are frequently instructed to "add this token to your wallet", to help their wallet identify tokens they care about.

To help ease this experience, I'd like to propose a new optional method to be exposed in web3-compatible browsers, eth_watchToken.

This method would take a single parameter, a JavaScript object with the following keys:

• address (required): The address of the token to watch, as a hex-prefixed string.
• symbol: A string representing the ticker symbol. Should be three characters. (Required if the token at the given address does not implement a public symbol() returns string method.
• decimals: number, representing the number of digits to treat as decimals. (Required if the token at the given address does not implement a public decimals() returns uint8 method.
• name: string, representing the token's name. Optional.

Web3 browsers should then show some confirmation to the user, requesting their permission to track the given token.

If one of the options (symbol, decimals, name) differs from the result of the token's own public method, I'm not sure what's best, probably default to the page? Open to opinions here, for now this is undefined behavior for the proposed spec.

Valid error messages:

Valid errors I'd like to propose, for the sake of cross-client consistency, are:

• Problem prompting the user.
• Problem tracking the token.
• User rejected request.

[skmgoldin]

This would be a useful convenience function. Practically speaking, in the workaday life of an Ethereum developer, we're dealing with ERC-20 tokens a lot these days.

[mickys]

If this is to be implemented, it would need some changes:
1 - symbol ( not limited to 3 characters, most ERC20 implementations, including the standard holds this as a string )
2 - token type. - you really want to detect the type if possible ( check methods on said contract ), else fallback to the user's choice.

Type might not be implemented in web3 browsers, but should really be considered as it would allow thin clients to provide different functionality based on used token standard.

[Arachnid]

This seems too high level for an RPC method. The node (which is what the RPC communicates with, not the browser) shouldn't have to care about tokens.

[kumavis]

This seems too high level for an RPC method.

I mostly agree

The node (which is what the RPC communicates with, not the browser)

@Arachnid this is incorrect. The dapp uses rpc to talk to the node (data lookups) and the browser (identity mgmt)

[kumavis]

@mickys you listed token type -- what types are there?

[mickys]

@kumavis
Types, you have ERC20, ERC677, ERC223 and many more in the works these days.
The idea behind having a type is the fact that a "watcher" should be able to use it to determine the best method to use to "transfer tokens" and such.

Back to the "eth_watchToken" metod, i would personally like to see this implemented in a smart contract rather than a RPC method. As that would also allow contracts to use it for validation.

[Arachnid]

@kumavis why would the dapp need an rpc to communicate with the browser? It can do that directly via js.

[danfinlay]

@Arachnid asked:

@kumavis why would the dapp need an rpc to communicate with the browser? It can do that directly via js.

Sorry for replying slow, this isn't a very urgent proposal.

I'm not actually proposing a new RPC method, never once said "RPC" in the original post. Currently, the JS interface actually uses an API (the Ethereum Provider API, poorly documented) that passes very RPC-looking strings to their data provider (wallet). Something like:

web3.currentProvider.sendAsync({
  method: 'eth_sendRawTransaction',
  data: '0x012341343451341abcdef',
}, callback)

In this context, I am not suggesting RPC providers implement eth_watchToken. I'm suggesting wallet providers do. This would mean this method should not be available on RPCs (the same way I don't think eth_sign or eth_sendTransaction should be on the RPC, separation of signer from data provider), but these methods should be available on the EthereumProvider API.

By being on the EthereumProvider, JS abstractions like Web3, EthJS, or Parity.js would all be able to expose these methods in the ways they most desire.

It's unfortunate that we basically have to have this conversation whenever trying to iterate on the JS API, I'll try to write a general distinction post at some point and start linking to it when proposing provider (not RPC) changes.

[Boydbueno]

Adding a new token can be quite a hassle for new users. By taking this away from the user the usability of many dapps will probably increase. I think that increasing the usability of dapps is very important to increase user adoption.

[danfinlay]

This would be a provider-based version of #961

I now am starting to think it may also make sense for sites to suggest the token's logo. At MetaMask, we've tried to curate a list of tokens for a while, but it's clearly unsustainable. It seems like a good solution to me to allow users to trust whatever source of token logos they want to find around the web.

Thoughts?

[kyriediculous]

Contract metadata stored on swarm could help with that last issue perhaps?

[axic]

The draft has been merged. It designates https://ethereum-magicians.org/t/eip-747-wallet-watchasset/1048 as the official discussion URL.

[MrThingchai]

Scam link removed manually