From 64fefe6a640daa897a568c6c4c7dea73c7f9f107 Mon Sep 17 00:00:00 2001 From: Vittorio Minacori Date: Sun, 13 Sep 2020 12:24:11 +0200 Subject: [PATCH] ERC-1363: Move to Last Call (#2617) Defines a token interface for ERC-20 tokens that supports executing recipient code on `transfer` or spender code on `approve`. --- EIPS/eip-1363.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/EIPS/eip-1363.md b/EIPS/eip-1363.md index d75ab6d3..b459d5b8 100644 --- a/EIPS/eip-1363.md +++ b/EIPS/eip-1363.md @@ -3,7 +3,8 @@ eip: 1363 title: ERC-1363 Payable Token author: Vittorio Minacori (@vittominacori) discussions-to: https://github.com/ethereum/eips/issues/1363 -status: Draft +status: Last Call +review-period-end: 2020-09-30 type: Standards Track category: ERC created: 2020-01-31 @@ -11,8 +12,7 @@ requires: 20, 165 --- ## Simple Summary -Description of a **Payable Token** compatible with the ERC-20 definition. -Also description of a Token **Receiver** and/or **Spender** that accepts Payable Token payments. +Defines a token interface for ERC-20 tokens that supports executing recipient code on `transfer` or spender code on `approve`. ## Abstract The following describes standard functions a token contract and contracts working with specified token can implement to make a Token Payable. @@ -26,10 +26,10 @@ It defines `approveAndCall` functions that will call an `onApprovalReceived` on This proposal is inspired by the ERC-721 `onERC721Received` and `ERC721TokenReceiver` behaviours. ## Specification -Every Payable Token compliant contract MUST implement the ERC-1363 interface other than ERC-20 and ERC-165 interfaces. +Every Payable Token compliant contract **MUST** implement the ERC-1363 interface as well as the ERC-20 and ERC-165 interfaces. ```solidity -pragma solidity ^0.6.0; +pragma solidity ^0.7.0; interface ERC1363 /* is ERC20, ERC165 */ { @@ -89,10 +89,6 @@ interface ERC1363 /* is ERC20, ERC165 */ { /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. - * Beware that changing an allowance with this method 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: - * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * @param spender address The address which will spend the funds * @param value uint256 The amount of tokens to be spent */ @@ -101,10 +97,6 @@ interface ERC1363 /* is ERC20, ERC165 */ { /** * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender * and then call `onApprovalReceived` on spender. - * Beware that changing an allowance with this method 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: - * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * @param spender address The address which will spend the funds * @param value uint256 The amount of tokens to be spent * @param data bytes Additional data with no specified format, sent in call to `spender` @@ -128,12 +120,12 @@ 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 token payments via `transferAndCall` or `transferFromAndCall` **MUST** implement the following interface: ```solidity /** * @title ERC1363Receiver interface - * @dev Interface for any contract that wants to support transferAndCall or transferFromAndCall + * @dev Interface for any contract that wants to support `transferAndCall` or `transferFromAndCall` * from ERC1363 token contracts. */ interface ERC1363Receiver { @@ -160,12 +152,12 @@ interface ERC1363Receiver { } ``` -A contract that wants to accept token payments via `approveAndCall` MUST implement the following interface: +A contract that wants to accept token payments via `approveAndCall` **MUST** implement the following interface: ```solidity /** * @title ERC1363Spender interface - * @dev Interface for any contract that wants to support approveAndCall + * @dev Interface for any contract that wants to support `approveAndCall` * from ERC1363 token contracts. */ interface ERC1363Spender { @@ -205,5 +197,12 @@ This proposal is inspired also by ERC-223 and ERC-677 but it uses the ERC-721 ap ## 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) +## Security Considerations +The `appeoveAndCall` and `transferFromAndCall` methods can be affected by the same issue of the standard ERC-20 `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. + +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)). + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).