Defines a token interface for ERC-20 tokens that supports executing recipient code after transfer or transferFrom, or spender code after approve.
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.
There is no way to execute code after a ERC-20 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 payments.
Examples could be
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 onERC721Received and ERC721TokenReceiver behaviours.
Implementing contracts MUST implement the ERC-1363 interface as well as the ERC-20 and ERC-165 interfaces.
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 approveAndCall MUST implement the following interface:
The choice to use transferAndCall, transferFromAndCall and approveAndCall derives from the ERC-20 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.
This proposal has been 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.
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).
Copyright and related rights waived via CC0.