From 7dc4bb7af35880b0a4e075bb5726757c9ff36fd9 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Thu, 16 Jun 2022 23:52:34 +0200 Subject: [PATCH 1/8] fix: clarify what erc1363 does with eoa --- EIPS/eip-1363.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index d4984c37998c9f..14ef7b1517779b 100644 --- a/EIPS/eip-1363.md +++ b/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. From 27508959a32bb8dc1e92c0f5a7be73b60df1522f Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Sun, 19 Jun 2022 21:02:10 +0200 Subject: [PATCH 2/8] fix: accepted suggested changes on ERC => EIP --- EIPS/eip-1363.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index 14ef7b1517779b..fb7de44fe07688 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -11,21 +11,21 @@ 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` in a single transaction. +Defines a token interface for [EIP-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 this token can implement to make a callback on receiver or spender. +The following are the transfer and callback functions standardized in this EIP: `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 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. +There is no way to execute code after an [EIP-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. -There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments. +There are many proposed uses of Ethereum smart contracts that can accept [EIP-20](./eip-20.md) payments. Examples could be * to create a token payable crowdsale @@ -33,14 +33,14 @@ Examples could be * paying invoices * making subscriptions -For these reasons it was originally named as **"Payable Token"**. +For these reasons it was originally named **"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. +This proposal has been inspired by the [EIP-721](./eip-721.md) `onERC721Received` and `ERC721TokenReceiver` behaviours. ## 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. +Implementing contracts **MUST** implement the [EIP-1363](./eip-1363.md) interface as well as the [EIP-20](./eip-20.md) and [EIP-165](./eip-165.md) interfaces. ```solidity pragma solidity ^0.8.0; @@ -191,16 +191,16 @@ 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. +Note that `transferAndCall`, `transferFromAndCall` and `approveAndCall` MUST revert if called on an EOA as it can't return the [EIP-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 contracts. +The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [EIP-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 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 [EIP-20](./eip-20.md) `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the [EIP-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. +The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [EIP-20](./eip-20.md) `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. From 3414035c64ee9f71fa3bf114d6aa3050f9b0750e Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 20 Jun 2022 09:35:10 +0200 Subject: [PATCH 3/8] feta: update note text --- EIPS/eip-1363.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index fb7de44fe07688..2287bf8a1edd2e 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -191,7 +191,8 @@ interface ERC1363Spender { } ``` -Note that `transferAndCall`, `transferFromAndCall` and `approveAndCall` MUST revert if called on an EOA as it can't return the [EIP-1363](./eip-1363.md) expected value. +Note that `transferAndCall`, `transferFromAndCall` MUST revert if the recipient is an EOA address, because EOA recipients do not implement the required ERC1363Receiver interface. +Note that `approveAndCall` MUST revert if the spender is an EOA address, because EOA spenders do not implement the required ERC1363Spender interface. ## Rationale The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [EIP-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. From 5d5ceace346f1b58f5563105ed69014f8bdd3aff Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 20 Jun 2022 09:52:12 +0200 Subject: [PATCH 4/8] feat: updated some params name to be more clear --- EIPS/eip-1363.md | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index 2287bf8a1edd2e..c4597aec0b9e5d 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -45,7 +45,7 @@ Implementing contracts **MUST** implement the [EIP-1363](./eip-1363.md) interfac ```solidity pragma solidity ^0.8.0; -interface ERC1363 /* is ERC20, ERC165 */ { +interface ERC1363 is ERC20, ERC165 { /* * Note: the ERC-165 identifier for this interface is 0xb0202a11. * 0xb0202a11 === @@ -60,56 +60,56 @@ interface ERC1363 /* is ERC20, ERC165 */ { /** * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver * @param to address The address which you want to transfer to - * @param value uint256 The amount of tokens to be transferred + * @param amount uint256 The amount of tokens to be transferred * @return true unless throwing */ - function transferAndCall(address to, uint256 value) external returns (bool); + function transferAndCall(address to, uint256 amount) external returns (bool); /** * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver * @param to address The address which you want to transfer to - * @param value uint256 The amount of tokens to be transferred + * @param amount uint256 The amount of tokens to be transferred * @param data bytes Additional data with no specified format, sent in call to `to` * @return true unless throwing */ - function transferAndCall(address to, uint256 value, bytes memory data) external returns (bool); + function transferAndCall(address to, uint256 amount, bytes memory data) external returns (bool); /** * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver - * @param from address The address which you want to send tokens from + * @param sender address The address which you want to send tokens from * @param to address The address which you want to transfer to - * @param value uint256 The amount of tokens to be transferred + * @param amount uint256 The amount of tokens to be transferred * @return true unless throwing */ - function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + function transferFromAndCall(address sender, address to, uint256 amount) external returns (bool); /** * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver - * @param from address The address which you want to send tokens from + * @param sender address The address which you want to send tokens from * @param to address The address which you want to transfer to - * @param value uint256 The amount of tokens to be transferred + * @param amount uint256 The amount of tokens to be transferred * @param data bytes Additional data with no specified format, sent in call to `to` * @return true unless throwing */ - function transferFromAndCall(address from, address to, uint256 value, bytes memory data) external returns (bool); + function transferFromAndCall(address sender, address to, uint256 amount, bytes memory data) external returns (bool); /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. * @param spender address The address which will spend the funds - * @param value uint256 The amount of tokens to be spent + * @param amount uint256 The amount of tokens to be spent */ - function approveAndCall(address spender, uint256 value) external returns (bool); + function approveAndCall(address spender, uint256 amount) external returns (bool); /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. * @param spender address The address which will spend the funds - * @param value uint256 The amount of tokens to be spent + * @param amount uint256 The amount of tokens to be spent * @param data bytes Additional data with no specified format, sent in call to `spender` */ - function approveAndCall(address spender, uint256 value, bytes memory data) external returns (bool); + function approveAndCall(address spender, uint256 amount, bytes memory data) external returns (bool); } interface ERC20 { @@ -149,14 +149,14 @@ interface ERC1363Receiver { * transfer. Return of other than the magic value MUST result in the * transaction being reverted. * Note: the token contract address is always the message sender. - * @param operator address The address which called `transferAndCall` or `transferFromAndCall` function - * @param from address The address which are token transferred from - * @param value uint256 The amount of tokens transferred + * @param spender address The address which called `transferAndCall` or `transferFromAndCall` function + * @param sender address The address which are token transferred from + * @param amount uint256 The amount of tokens transferred * @param data bytes Additional data with no specified format * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` * unless throwing */ - function onTransferReceived(address operator, address from, uint256 value, bytes memory data) external returns (bytes4); + function onTransferReceived(address spender, address sender, uint256 amount, bytes memory data) external returns (bytes4); } ``` @@ -181,13 +181,13 @@ interface ERC1363Spender { * approval. Return of other than the magic value MUST result in the * transaction being reverted. * Note: the token contract address is always the message sender. - * @param owner address The address which called `approveAndCall` function - * @param value uint256 The amount of tokens to be spent + * @param sender address The address which called `approveAndCall` function + * @param amount uint256 The amount of tokens to be spent * @param data bytes Additional data with no specified format * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` * unless throwing */ - function onApprovalReceived(address owner, uint256 value, bytes memory data) external returns (bytes4); + function onApprovalReceived(address sender, uint256 amount, bytes memory data) external returns (bytes4); } ``` From 04266620a1b21ae31f771da8caedcaec8057ae7b Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 21 Jun 2022 23:03:21 +0200 Subject: [PATCH 5/8] fix: add transferFrom and approve removed by suggestion --- EIPS/eip-1363.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index c4597aec0b9e5d..2496831ecbbef4 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -14,7 +14,7 @@ requires: 20, 165 Defines a token interface for [EIP-20](./eip-20.md) tokens that supports executing recipient code after `transfer` or `transferFrom`, or spender code after `approve` in a single transaction. ## Abstract -The following are the transfer and callback functions standardized in this EIP: +The following are the transfer, transferFrom, approve and callback functions standardized in this EIP: `transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract. From 3c3627831c05a061c87283fdc917bd4f6afd2f4b Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Wed, 22 Jun 2022 15:06:26 +0200 Subject: [PATCH 6/8] feat: update motivation and summary --- EIPS/eip-1363.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index 2496831ecbbef4..8a64ff895472d6 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -11,7 +11,7 @@ requires: 20, 165 --- ## Simple Summary -Defines a token interface for [EIP-20](./eip-20.md) tokens that supports executing recipient code after `transfer` or `transferFrom`, or spender code after `approve` in a single transaction. +Defines a token interface for [EIP-20](./eip-20.md) tokens that supports executing recipient contract code after `transfer` or `transferFrom`, or spender contract code after `approve` in a single transaction. ## Abstract The following are the transfer, transferFrom, approve and callback functions standardized in this EIP: @@ -21,11 +21,13 @@ The following are the transfer, transferFrom, approve and callback functions sta `approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract. ## Motivation -There is no way to execute code after an [EIP-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 any code on a receiver or spender contract after an [EIP-20](./eip-20.md) `transfer`, `transferFrom` or `approve` so, to make an action, it is required to send another transaction. +This introduces complexity on UI development and friction on adoption because users must wait for the first transaction to be executed and then send the second one. -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. +This proposal aims to make tokens capable of performing actions more easily and working without the use of any other listener. +It allows to make a callback on a receiver or spender contract, after a transfer or an approval, in a single transaction. -There are many proposed uses of Ethereum smart contracts that can accept [EIP-20](./eip-20.md) payments. +There are many proposed uses of Ethereum smart contracts that can accept [EIP-20](./eip-20.md) callbacks. Examples could be * to create a token payable crowdsale From d779b6c16b1883c14ea79e1b87af2615d5006883 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 28 Jun 2022 13:21:36 +0200 Subject: [PATCH 7/8] fix: update backwards compatibility --- EIPS/eip-1363.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index 8a64ff895472d6..16c7ccf160a04c 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -200,7 +200,8 @@ Note that `approveAndCall` MUST revert if the spender is an EOA address, because The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [EIP-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 doesn't override the [EIP-20](./eip-20.md) `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the [EIP-20](./eip-20.md) backwards compatibility. +This proposal has been inspired also by many previous informal standards. +Unlike these proposals, [EIP-1363](./eip-1363.md) doesn't override the [EIP-20](./eip-20.md) `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining backward compatibility with [EIP-20](./eip-20.md). ## Security Considerations The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [EIP-20](./eip-20.md) `approve` and `transferFrom` method. From eebe192247e6525a4aeb889c6ea54ad62b41b4d9 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 28 Jun 2022 13:25:08 +0200 Subject: [PATCH 8/8] fix: update motivation --- EIPS/eip-1363.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index 16c7ccf160a04c..6f1ce58c7ae4f5 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -22,7 +22,7 @@ The following are the transfer, transferFrom, approve and callback functions sta ## Motivation There is no way to execute any code on a receiver or spender contract after an [EIP-20](./eip-20.md) `transfer`, `transferFrom` or `approve` so, to make an action, it is required to send another transaction. -This introduces complexity on UI development and friction on adoption because users must wait for the first transaction to be executed and then send the second one. +This introduces complexity on UI development and friction on adoption because users must wait for the first transaction to be executed and then send the second one. They must also pay GAS twice. This proposal aims to make tokens capable of performing actions more easily and working without the use of any other listener. It allows to make a callback on a receiver or spender contract, after a transfer or an approval, in a single transaction.