fix: clarify what erc1363 does with eoa

EIPS/eip-1363.md

@@ -11,17 +11,17 @@ 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`.
+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` in a single transaction.
 
 ## Abstract
-Standard functions a token contract and contracts working with tokens can implement to make a token Payable.
+Standard functions a token contract and contracts working with this token can implement to make a callback on receiver or spender.
 
 `transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract.  
 
 `approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract.
 
 ## 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.
+There is no way to execute code after an [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.
 
 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.
 
@@ -33,7 +33,7 @@ Examples could be
 * paying invoices
 * making subscriptions
 
-For these reasons it was named as **"Payable Token"**.
+For these reasons it was originally 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.
 
@@ -128,7 +128,7 @@ interface ERC165 {
 }
 ```
 
-A contract that wants to accept token payments via `transferAndCall` or `transferFromAndCall` **MUST** implement the following interface:
+A contract that wants to accept ERC1363 tokens via `transferAndCall` or `transferFromAndCall` **MUST** implement the following interface:
 
 ```solidity
 /**
@@ -160,7 +160,7 @@ interface ERC1363Receiver {
 }
 ``` 
 
-A contract that wants to accept token payments via `approveAndCall` **MUST** implement the following interface:
+A contract that wants to accept ERC1363 tokens via `approveAndCall` **MUST** implement the following interface:
 
 ```solidity
 /**
@@ -191,11 +191,13 @@ interface ERC1363Spender {
 }
 ``` 
 
+Note that `transferAndCall`, `transferFromAndCall` and `approveAndCall` MUST revert if called on an EOA as it can't return the [ERC-1363](./eip-1363.md) expected value.
+
 ## 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.
+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 contracts.
 
 ## 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.  
+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 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.  
 
 ## 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.