ERC-1363: Move to Final (#3027)

EIPS/eip-1363.md

@@ -3,8 +3,7 @@ eip: 1363
 title: ERC-1363 Payable Token
 author: Vittorio Minacori (@vittominacori)
 discussions-to: https://github.com/ethereum/eips/issues/1363
-status: Last Call
+status: Final
-review-period-end: 2020-09-30
 type: Standards Track
 category: ERC
 created: 2020-01-31
@@ -12,21 +11,36 @@ requires: 20, 165
 ---
 
 ## Simple Summary
-Defines a token interface for ERC-20 tokens that supports executing recipient code on `transfer` or spender code on `approve`.
+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
-The following describes standard functions a token contract and contracts working with specified token can implement to make a Token Payable.
+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.
 
 ## Motivation
-This proposal allows to implement an ERC-20 compatible token that can be used for payments.
+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.
 
-It defines `transferAndCall` and `transferFromAndCall` functions that will call an `onTransferReceived` on a `ERC1363Receiver` 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.
-It defines `approveAndCall` functions that will call an `onApprovalReceived` on a `ERC1363Spender` contract.
 
-This proposal is inspired by the ERC-721 `onERC721Received` and `ERC721TokenReceiver` behaviours. 
+There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments. 
+
+Examples could be 
+* to create a token payable crowdsale
+* selling services for tokens 
+* paying invoices
+* making subscriptions
+
+For these reasons it was named as **"Payable Token"**.
+
+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 has been inspired by the [ERC-721](./eip-721.md) `onERC721Received` and `ERC721TokenReceiver` behaviours. 
 
 ## Specification
-Every Payable Token compliant contract **MUST** implement the ERC-1363 interface as well as the ERC-20 and ERC-165 interfaces.
+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.
 
 ```solidity
 pragma solidity ^0.7.0;
@@ -184,23 +198,15 @@ interface ERC1363Spender {
 ``` 
 
 ## Rationale
-There are many proposed uses of Ethereum smart contracts that can accept ERC-20 payments (i.e. to create a token payable crowdsale, selling services for tokens, paying invoices, making subscriptions, use them for a specific utility and many other purposes). 
+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.
-
-This proposal wants to make token payments easier and working without the use of any other listener. It also allows to make a callback after a transfer in a single transaction.
 
 ## Backwards Compatibility
-This proposal is inspired also by ERC-223 and ERC-677 but it uses the ERC-721 approach so it doesn't override the ERC-20 `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the ERC-20 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.  
-
-## Test Cases
-[https://github.com/vittominacori/erc1363-payable-token/tree/master/test](https://github.com/vittominacori/erc1363-payable-token/tree/master/test)
-
-## Implementation
-[https://github.com/vittominacori/erc1363-payable-token/tree/master/contracts/token/ERC1363](https://github.com/vittominacori/erc1363-payable-token/tree/master/contracts/token/ERC1363)
 
 ## Security Considerations
-The `appeoveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard ERC-20 `approve` and `transferFrom` method.
+The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [ERC-20](./eip-20.md) `approve` and `transferFrom` method.
   
-Changing an allowance with the `appeoveAndCall` methods brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering.
+Changing an allowance with the `approveAndCall` methods brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering.
 
 One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards ([EIP-20#issuecomment-263524729](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729)).