Proposal for AddToken URI standard

EIPS/EIP-961.md

@@ -0,0 +1,61 @@
+---
+    eip: 961
+    title: URL Format for Tokens
+    status: Active
+    type: Standards Track
+    author: Kylan Hurt <kylan@edgesecure.co>, Eliran Zach <eliran@edgesecure.co>
+    created: 2018-04-01
+    requires: 20, 137, 831
+---
+
+## Simple Summary
+A standard way of representing token information, facilitating the process of adding ERC #20 tokens as URLs on the application layer.
+
+## Abstract
+URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format for fundamental token information allows for instant invocation of the user's preferred wallet application (even if it is a webapp or a swarm đapp), with the correct parameterization of the token's information only to be confirmed by the user.
+
+## Motivation
+The convenience of representing payment requests by standard URLs has been a significant factor in the cryptocurrency. Extending this convenient mechanism to support embedding of basic token information would help to facilitate the usage of Ethereum-based tokens. In particular, QR-code embedded URLs could be generated by token-generators to help users track the tokens via any wallet software that has the ability to scan QR codes (particularly mobile wallets). For example, rather than users needing to find the contract address and number of decimal places for a given token through an online directory, they could simply scan a QR-code provided by the token generator with this data embedded. The wallet software could then automatically add the tokens to the user's wallet. This would improve the user experience associated with purchasing and holding tokens as a digital asset.
+
+
+## Specification
+
+### Syntax
+Token data URLs contain "ethereum" in their schema (protocol) part and are constructed as follows:
+
+    request                 = "ethereum" ":" "token_info-" target_address "@" chain_id [ "?" parameters ]
+    target_address          = ethereum_address
+    chain_id                = 1*DIGIT
+    ethereum_address        = ( "0x" 40*40HEXDIG ) / ENS_NAME
+    parameters              = parameter *( "&" parameter )
+    parameter               = key "=" value
+    key                     = "symbol" / "decimals" / "name" / "type"
+    value                   = STRING / number (0-18) / STRING / STRING
+
+Where all of the key + value pairs are optional, allowing for maximum flexibility on the application layer.
+
+
+### Semantics
+
+`target_address` is mandatory and denotes the contract address with which the user is asked to interact.
+
+`chain_id` is mandatory and contains the decimal chain ID, such that transactions on various test- and private networks can be requested.
+
+If using ENS names instead of hexadecimal addresses, the resolution is up to the payer, at any time between receiving the URL and sending the transaction. Hexadecimal addresses always take precedence over ENS names, i.e. even if there exists a matching ENS name consisting of 40 hexadecimal digits, it should never be resolved. Instead, the hexadecimal address should be used directly.
+
+1. `symbol` (optional) is the token symbol (STRING) - Defaults to "SYM"
+2. `decimals` (optional) is a whole number between 0 and 18 (inclusive) - Defaults to 18
+3. `name` (optional) is a more user-friendly name (STRING) for the token, typically the name of the project that generated the tokens - Defaults to the value of symbol
+4. `type` (optional) is the type of token (STRING), e.g. "ERC20". - Defaults to "ERC20"
+
+Note: `STRING` is a URL-encoded unicode string of arbitrary length, where delimiters and the percentage symbol (`%`) are mandatorily hex-encoded with a `%` prefix.
+
+## Rationale
+The proposed format is chosen to resemble `ethereum:pay` URLs as closely as possible, as both users and application programmers are already familiar with that format. Individuals generating these URLs are free to add and remove arbitrary parameters as they see fit.
+
+## Compatibility and Versioning
+Future upgrades that are partially or fully incompatible with this proposal must use a prefix other than `token_info-` that is separated by a dash (`-`) character from whatever follows it, as specified by ERC #831.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).