From 8589324502a2cfb440085aa336d743742805babe Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 29 Apr 2024 16:11:47 +0200 Subject: [PATCH 1/4] Update text to modern recommendation --- ERCS/erc-1363.md | 68 +++++++++++++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 27 deletions(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index 9e0a028a20..04e505ff3a 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -10,37 +10,34 @@ 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 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 @@ 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 ERC-1363 tokens via `transferAndCall` or `transferFromAndCall` **MUST** implement the `ERC1363Receiver` interface: ```solidity /** @@ -162,7 +159,7 @@ interface ERC1363Receiver { } ``` -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 @@ 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 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). From 80c2a7a2a1d7b421a2c41f1ed02db3e724c063b5 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 29 Apr 2024 16:24:31 +0200 Subject: [PATCH 2/4] Fix eip validator error: the first match of the given pattern must be a link --- ERCS/erc-1363.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index 04e505ff3a..5dd562b357 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -12,7 +12,7 @@ requires: 20, 165 ## Abstract -This proposal 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. +[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. 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. From b12c727d3905b880c98a4292114967496e104ccd Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 29 Apr 2024 16:11:47 +0200 Subject: [PATCH 3/4] Update text to modern recommendation --- ERCS/erc-1363.md | 68 +++++++++++++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 27 deletions(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index 9e0a028a20..04e505ff3a 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -10,37 +10,34 @@ 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 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 @@ 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 ERC-1363 tokens via `transferAndCall` or `transferFromAndCall` **MUST** implement the `ERC1363Receiver` interface: ```solidity /** @@ -162,7 +159,7 @@ interface ERC1363Receiver { } ``` -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 @@ 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 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). From 3c1ba1ce0506876722daafaec6a09824a9a9e5ca Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Mon, 29 Apr 2024 16:24:31 +0200 Subject: [PATCH 4/4] Fix eip validator error: the first match of the given pattern must be a link --- ERCS/erc-1363.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index 04e505ff3a..5dd562b357 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -12,7 +12,7 @@ requires: 20, 165 ## Abstract -This proposal 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. +[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. 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.