Update ERC-1363: Update text to modern recommendations

ERCS/erc-1363.md

@@ -1,8 +1,8 @@
 ---
 eip: 1363
 title: Payable Token
 author: Vittorio Minacori (@vittominacori)
 discussions-to: https://github.com/ethereum/eips/issues/1363
 status: Final
 type: Standards Track
 category: ERC
@@ -10,37 +10,34 @@
 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.
+[ERC-1363](./erc-1363.md) is 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 EIP:
 
-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. 
+ERC-1363 tokens can be used for specific utilities in all cases that require a callback to be executed after a transfer or an approval received.
+ERC-1363 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.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+Smart contracts implementing the ERC-1363 standard **MUST** implement all of the functions in the `ERC1363` interface, as well as the [ERC-20](./erc-20.md) and [ERC-165](./erc-165.md) interfaces.
 
 ```solidity
 pragma solidity ^0.8.0;
@@ -130,7 +127,7 @@
 }
 ```
 
-A contract that wants to accept token payments via `transferAndCall` or `transferFromAndCall` **MUST** implement the following interface:
+A contract that wants to accept ERC-1363 tokens via `transferAndCall` or `transferFromAndCall` **MUST** implement the `ERC1363Receiver` interface:
 
 ```solidity
 /**
@@ -162,7 +159,7 @@
 }
 ``` 
 
-A contract that wants to accept token payments via `approveAndCall` **MUST** implement the following interface:
+A contract that wants to accept ERC-1363 tokens via `approveAndCall` **MUST** implement the `ERC1363Spender` interface:
 
 ```solidity
 /**
@@ -194,17 +191,34 @@
 ``` 
 
 ## 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 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.  
+
+Unlike other ERC-20 extension proposals, ERC-1363 doesn't override the ERC-20 `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining backward compatibility with ERC-20.
 
 ## Security Considerations
-The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [ERC-20](./eip-20.md) `approve` and `transferFrom` method.
-  
+
+The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard ERC-20 `approve` and `transferFrom` method.
 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)).
+One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).