From 8bcc0dda9a24ed57e0668e331c0c782977472511 Mon Sep 17 00:00:00 2001 From: Kylan Hurt Date: Sun, 1 Apr 2018 12:16:47 -0700 Subject: [PATCH 1/3] Submit EIP for AddToken URI standard --- EIPS/EIP-X-add-token-uri-kylanhurt.md | 60 +++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 EIPS/EIP-X-add-token-uri-kylanhurt.md diff --git a/EIPS/EIP-X-add-token-uri-kylanhurt.md b/EIPS/EIP-X-add-token-uri-kylanhurt.md new file mode 100644 index 00000000000000..db923c5666a365 --- /dev/null +++ b/EIPS/EIP-X-add-token-uri-kylanhurt.md @@ -0,0 +1,60 @@ +## Preamble + + EIP: + Title: URL Format for Tokens + Author: Kylan Hurt , Eliran Zach + Type: Standard Track + Category: ERC + Status: Draft + Created: 2018-04-01 + Requires: 20, 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-" ]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 either the beneficiary of native token payment (see below) or the contract address with which the user is asked to interact. + +`chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective. + +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. + +* `symbol` (optional) is the token symbol (STRING) - Defaults to "SYM" +* `decimals` (optional) is a whole number between 0 and 18 (inclusive) - Defaults to 18 +* `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 +* `type` (optional) is the type of token (STRING), eg "ERC20". - Defaults to "ERC20" + +## 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-` 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/). From 602e817550bd7674eac65267aa79c76e89ab672f Mon Sep 17 00:00:00 2001 From: Kylan Hurt Date: Wed, 11 Apr 2018 20:51:36 -0700 Subject: [PATCH 2/3] Update EIP based on PR comments --- ...-add-token-uri-kylanhurt.md => EIP-961.md} | 32 +++++++++---------- 1 file changed, 15 insertions(+), 17 deletions(-) rename EIPS/{EIP-X-add-token-uri-kylanhurt.md => EIP-961.md} (74%) diff --git a/EIPS/EIP-X-add-token-uri-kylanhurt.md b/EIPS/EIP-961.md similarity index 74% rename from EIPS/EIP-X-add-token-uri-kylanhurt.md rename to EIPS/EIP-961.md index db923c5666a365..61a02d684e0b8e 100644 --- a/EIPS/EIP-X-add-token-uri-kylanhurt.md +++ b/EIPS/EIP-961.md @@ -1,13 +1,11 @@ -## Preamble - - EIP: - Title: URL Format for Tokens - Author: Kylan Hurt , Eliran Zach - Type: Standard Track - Category: ERC - Status: Draft - Created: 2018-04-01 - Requires: 20, 831 +--- + eip: 961 + title: URL Format for Tokens + status: Active + type: Standards Track + author: Kylan Hurt , Eliran Zach + created: 2018-04-01 +--- ## Simple Summary A standard way of representing token information, facilitating the process of adding ERC #20 tokens as URLs on the application layer. @@ -24,7 +22,7 @@ The convenience of representing payment requests by standard URLs has been a sig ### Syntax Token data URLs contain "ethereum" in their schema (protocol) part and are constructed as follows: - request = "ethereum" ":" [ "token-" ]target_address [ "@" chain_id ] [ "?" parameters ] + request = "ethereum" ":" "token_info-" target_address [ "@" chain_id ] [ "?" parameters ] target_address = ethereum_address chain_id = 1*DIGIT ethereum_address = ( "0x" 40*40HEXDIG ) / ENS_NAME @@ -42,18 +40,18 @@ Where all of the key + value pairs are optional, allowing for maximum flexibilit `chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective. -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. +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. -* `symbol` (optional) is the token symbol (STRING) - Defaults to "SYM" -* `decimals` (optional) is a whole number between 0 and 18 (inclusive) - Defaults to 18 -* `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 -* `type` (optional) is the type of token (STRING), eg "ERC20". - Defaults to "ERC20" +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" ## 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-` that is separated by a dash (`-`) character from whatever follows it, as specified by ERC #831. +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 From a5b50297758632ac7f3f1175c34c1693c20e6ef5 Mon Sep 17 00:00:00 2001 From: Kylan Hurt Date: Mon, 16 Apr 2018 14:47:39 -0700 Subject: [PATCH 3/3] Inclusion of other required EIPs, explanation of STRING, make some parameters mandatory --- EIPS/EIP-961.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/EIPS/EIP-961.md b/EIPS/EIP-961.md index 61a02d684e0b8e..7a1155c7a46d5f 100644 --- a/EIPS/EIP-961.md +++ b/EIPS/EIP-961.md @@ -5,6 +5,7 @@ type: Standards Track author: Kylan Hurt , Eliran Zach created: 2018-04-01 + requires: 20, 137, 831 --- ## Simple Summary @@ -22,7 +23,7 @@ The convenience of representing payment requests by standard URLs has been a sig ### 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 ] + request = "ethereum" ":" "token_info-" target_address "@" chain_id [ "?" parameters ] target_address = ethereum_address chain_id = 1*DIGIT ethereum_address = ( "0x" 40*40HEXDIG ) / ENS_NAME @@ -36,9 +37,9 @@ Where all of the key + value pairs are optional, allowing for maximum flexibilit ### Semantics -`target_address` is mandatory and denotes either the beneficiary of native token payment (see below) or the contract address with which the user is asked to interact. +`target_address` is mandatory and denotes the contract address with which the user is asked to interact. -`chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective. +`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. @@ -47,6 +48,8 @@ If using ENS names instead of hexadecimal addresses, the resolution is up to the 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.