ERC-1363: Payable Token

Metadata

Status: FinalStandards Track: ERCCreated: 2018-08-30

Authors

Vittorio Minacori (@vittominacori)

Requires

EIP-20, EIP-165

Links

GitHub page Discussion on Ethereum Magicians

Simple Summary

Defines a token interface for ERC-20 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.

Motivation

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

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 onERC721Received and ERC721TokenReceiver behaviours.

Specification

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:

Rationale

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.

Backwards Compatibility

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.

Security Considerations

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).