From 63e2c41262152e01b402d104df4d36b95a092bb3 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Wed, 28 Oct 2020 06:23:54 +0100 Subject: [PATCH] ERC-1363: Move to Final (#3027) --- EIPS/eip-1363.md | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index b459d5b8..007b7db1 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -3,8 +3,7 @@ eip: 1363 title: ERC-1363 Payable Token author: Vittorio Minacori (@vittominacori) discussions-to: https://github.com/ethereum/eips/issues/1363 -status: Last Call -review-period-end: 2020-09-30 +status: Final type: Standards Track category: ERC created: 2020-01-31 @@ -12,21 +11,36 @@ requires: 20, 165 --- ## Simple Summary -Defines a token interface for ERC-20 tokens that supports executing recipient code on `transfer` or spender code on `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`. ## Abstract -The following describes standard functions a token contract and contracts working with specified token can implement to make a Token Payable. +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. ## Motivation -This proposal allows to implement an ERC-20 compatible token that can be used for payments. +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. -It defines `transferAndCall` and `transferFromAndCall` functions that will call an `onTransferReceived` on a `ERC1363Receiver` contract. -It defines `approveAndCall` functions that will call an `onApprovalReceived` on a `ERC1363Spender` 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. -This proposal is inspired by the ERC-721 `onERC721Received` and `ERC721TokenReceiver` behaviours. +There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments. + +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. ## Specification -Every Payable Token compliant contract **MUST** implement the ERC-1363 interface as well as the ERC-20 and ERC-165 interfaces. +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. ```solidity pragma solidity ^0.7.0; @@ -184,23 +198,15 @@ interface ERC1363Spender { ``` ## Rationale -There are many proposed uses of Ethereum smart contracts that can accept ERC-20 payments (i.e. to create a token payable crowdsale, selling services for tokens, paying invoices, making subscriptions, use them for a specific utility and many other purposes). - -This proposal wants to make token payments easier and working without the use of any other listener. It also allows to make a callback after a transfer in a single transaction. +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. ## Backwards Compatibility -This proposal is inspired also by ERC-223 and ERC-677 but it uses the ERC-721 approach so it doesn't override the ERC-20 `transfer` and `transferFrom` methods and defines the interfaces IDs to be implemented maintaining the ERC-20 backwards compatibility. - -## Test Cases -[https://github.com/vittominacori/erc1363-payable-token/tree/master/test](https://github.com/vittominacori/erc1363-payable-token/tree/master/test) - -## Implementation -[https://github.com/vittominacori/erc1363-payable-token/tree/master/contracts/token/ERC1363](https://github.com/vittominacori/erc1363-payable-token/tree/master/contracts/token/ERC1363) +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. ## Security Considerations -The `appeoveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard ERC-20 `approve` and `transferFrom` method. +The `approveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard [ERC-20](./eip-20.md) `approve` and `transferFrom` method. -Changing an allowance with the `appeoveAndCall` methods brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. +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)).