From 9fc9d90ea2517f3eef2c8341d4d096706e0b71a4 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 31 Oct 2023 09:47:44 +0100 Subject: [PATCH 1/3] Update preamble and removed the not necessary simple summary section --- ERCS/erc-1363.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index d4984c3799..e392d9e24f 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -1,8 +1,9 @@ --- eip: 1363 title: Payable Token +description: Fungible token extension that supports executing callbacks on receiver contracts. author: Vittorio Minacori (@vittominacori) -discussions-to: https://github.com/ethereum/eips/issues/1363 +discussions-to: https://ethereum-magicians.org/t/erc-1363-payable-token/16225 status: Final type: Standards Track category: ERC @@ -10,9 +11,6 @@ created: 2020-01-31 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. From 16388568e43fe6160ba9645192eb6c721b523c41 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 31 Oct 2023 09:49:34 +0100 Subject: [PATCH 2/3] Refactor abstract section --- ERCS/erc-1363.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index e392d9e24f..88b130bb89 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -12,11 +12,16 @@ requires: 20, 165 --- ## 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. +This proposal defines 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. -`approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract. +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. + +The following are functions and callbacks introduced by this ERC: + +* `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. From 957d5044f929f40827fc585e61a014d9423404bc Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Tue, 31 Oct 2023 09:51:12 +0100 Subject: [PATCH 3/3] Moves the rationale from motivation into the rationale section --- ERCS/erc-1363.md | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/ERCS/erc-1363.md b/ERCS/erc-1363.md index 88b130bb89..d15ff25737 100644 --- a/ERCS/erc-1363.md +++ b/ERCS/erc-1363.md @@ -24,23 +24,15 @@ The following are functions and callbacks introduced by this ERC: * `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. -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 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. -There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments. +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. -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. +Tokens defined by this ERC can be used for specific utilities in all cases that require a callback to be executed after a transfer or an approval received. +This ERC 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. @@ -195,7 +187,22 @@ 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](./erc-20.md) 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.