Merge 20ee1ff into 82ee377

ERCS/erc-1363.md

@@ -1,43 +1,38 @@
 ---
 eip: 1363
 title: Payable Token
+description: Fungible token extension that supports executing callbacks on receiver contracts.
 author: Vittorio Minacori (@vittominacori)
-discussions-to: https://github.com/ethereum/eips/issues/1363
+discussions-to: https://ethereum-magicians.org/t/erc-1363-payable-token/16225
 status: Final
 type: Standards Track
 category: ERC
 created: 2018-08-30
 requires: 20, 165
 ---
 
-## Simple Summary
-Defines a token interface for [ERC-20](./eip-20.md) tokens that supports executing recipient code after `transfer` or `transferFrom`, or spender code after `approve`.
-
 ## Abstract
-Standard functions a token contract and contracts working with tokens can implement to make a token Payable.
-
-`transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract.  
 
-`approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract.
+This proposal defines an extension interface for [ERC-20](./erc-20.md) tokens that supports executing code on a recipient contract after transfers, or code on a spender contract after approvals, in a single transaction.
 
-## Motivation
-There is no way to execute code after a [ERC-20](./eip-20.md) transfer or approval (i.e. making a payment), so to make an action it is required to send another transaction and pay GAS twice.
+The following standard allows for the implementation of a standard API for tokens interaction with smart contracts after `transfer`, `transferFrom` or `approve`.
+This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party, and then make a callback on the receiver or spender contract.
 
-This proposal wants to make token payments easier and working without the use of any other listener. It allows to make a callback after a transfer or approval in a single transaction.
+The following are functions and callbacks introduced by this ERC:
 
-There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments. 
+* `transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract.
+* `approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract.
 
-Examples could be 
-* to create a token payable crowdsale
-* selling services for tokens 
-* paying invoices
-* making subscriptions
+## Motivation
 
-For these reasons it was named as **"Payable Token"**.
+There is no way to execute code on a receiver/spender contract after an ERC-20 `transfer`, `transferFrom` or `approve` so, to perform an action, it is required to send another transaction.
+This introduces complexity in UI development and friction on adoption as users must wait for the first transaction to be executed and then submit the second one. They must also pay GAS twice.
 
-Anyway you can use it for specific utilities or for any other purposes who require the execution of a callback after a transfer or approval received.
+This proposal aims to make tokens capable of performing actions more easily and working without the use of any off-chain listener.
+It allows to make a callback on a receiver/spender contract, after a transfer or an approval, in a single transaction.
 
-This proposal has been inspired by the [ERC-721](./eip-721.md) `onERC721Received` and `ERC721TokenReceiver` behaviours. 
+Tokens defined by this ERC can be used for specific utilities in all cases that require a callback to be executed after a transfer or an approval received.
+This ERC is also useful for avoiding token loss or token locking in contracts by verifying the recipient contract's ability to handle tokens.
 
 ## Specification
 Implementing contracts **MUST** implement the [ERC-1363](./eip-1363.md) interface as well as the [ERC-20](./eip-20.md) and [ERC-165](./eip-165.md) interfaces.
@@ -192,7 +187,22 @@ interface ERC1363Spender {
 ``` 
 
 ## Rationale
-The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [ERC-20](./eip-20.md) naming. They want to highlight that they have the same behaviours of `transfer`, `transferFrom` and `approve` with the addition of a callback on receiver or spender.
+
+There are many proposed uses of Ethereum smart contracts that can accept ERC-20 callbacks.
+
+Examples could be:
+
+* creating a token payable crowdsale
+* selling services for tokens
+* paying invoices
+* making subscriptions
+
+For these reasons it was originally named **"Payable Token"**.
+
+The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [ERC-20](./erc-20.md) naming.
+They want to highlight that they have the same behaviors of `transfer`, `transferFrom` and `approve` with the addition of a callback on receiver or spender contracts.
+
+`ERC1363Receiver` and `ERC1363Spender` were inspired by the [ERC-721](./erc-721.md) `ERC721TokenReceiver` behavior.
 
 ## Backwards Compatibility
 This proposal has been inspired also by [ERC-223](https://github.com/ethereum/EIPs/issues/223) and [ERC-677](https://github.com/ethereum/EIPs/issues/677) but it uses the [ERC-721](./eip-721.md) approach, so it doesn't override the [ERC-20](./eip-20.md) `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the [ERC-20](./eip-20.md) backwards compatibility.