ERC-1363 Payable Token

[vittominacori]

ERC-1363 Payable Token

Simple Summary

Defines a token interface for EIP-20 tokens that supports executing recipient contract code after transfer or transferFrom, or spender contract code after approve in a single transaction.

Abstract

The following are the transfer, transferFrom, approve and callback functions standardized in this EIP:

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 any code on a receiver or spender contract after an EIP-20 transfer, transferFrom or approve so, to make an action, it is required to send another transaction.
This introduces complexity on UI development and friction on adoption because users must wait for the first transaction to be executed and then send the second one. They must also pay GAS twice.

This proposal aims to make tokens capable of performing actions more easily and working without the use of any other listener.
It allows to make a callback on a receiver or spender contract, after a transfer or an approval, in a single transaction.

There are many proposed uses of Ethereum smart contracts that can accept EIP-20 callbacks.

Examples could be

• to create a token payable crowdsale
• selling services for tokens
• paying invoices
• making subscriptions

For these reasons it was originally named "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 EIP-721 onERC721Received and ERC721TokenReceiver behaviours.

Specification

Implementing contracts MUST implement the EIP-1363 interface as well as the EIP-20 and EIP-165 interfaces.

pragma solidity ^0.8.0;

interface ERC1363 is ERC20, ERC165 {
  /*
   * Note: the ERC-165 identifier for this interface is 0xb0202a11.
   * 0xb0202a11 ===
   *   bytes4(keccak256('transferAndCall(address,uint256)')) ^
   *   bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^
   *   bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^
   *   bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^
   *   bytes4(keccak256('approveAndCall(address,uint256)')) ^
   *   bytes4(keccak256('approveAndCall(address,uint256,bytes)'))
   */

  /**
   * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver
   * @param to address The address which you want to transfer to
   * @param amount uint256 The amount of tokens to be transferred
   * @return true unless throwing
   */
  function transferAndCall(address to, uint256 amount) external returns (bool);

  /**
   * @notice Transfer tokens from `msg.sender` to another address and then call `onTransferReceived` on receiver
   * @param to address The address which you want to transfer to
   * @param amount uint256 The amount of tokens to be transferred
   * @param data bytes Additional data with no specified format, sent in call to `to`
   * @return true unless throwing
   */
  function transferAndCall(address to, uint256 amount, bytes memory data) external returns (bool);

  /**
   * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver
   * @param sender address The address which you want to send tokens from
   * @param to address The address which you want to transfer to
   * @param amount uint256 The amount of tokens to be transferred
   * @return true unless throwing
   */
  function transferFromAndCall(address sender, address to, uint256 amount) external returns (bool);


  /**
   * @notice Transfer tokens from one address to another and then call `onTransferReceived` on receiver
   * @param sender address The address which you want to send tokens from
   * @param to address The address which you want to transfer to
   * @param amount uint256 The amount of tokens to be transferred
   * @param data bytes Additional data with no specified format, sent in call to `to`
   * @return true unless throwing
   */
  function transferFromAndCall(address sender, address to, uint256 amount, bytes memory data) external returns (bool);

  /**
   * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender
   * and then call `onApprovalReceived` on spender.
   * @param spender address The address which will spend the funds
   * @param amount uint256 The amount of tokens to be spent
   */
  function approveAndCall(address spender, uint256 amount) external returns (bool);

  /**
   * @notice Approve the passed address to spend the specified amount of tokens on behalf of msg.sender
   * and then call `onApprovalReceived` on spender.
   * @param spender address The address which will spend the funds
   * @param amount uint256 The amount of tokens to be spent
   * @param data bytes Additional data with no specified format, sent in call to `spender`
   */
  function approveAndCall(address spender, uint256 amount, bytes memory data) external returns (bool);
}

interface ERC20 {
  function totalSupply() external view returns (uint256);
  function balanceOf(address account) external view returns (uint256);
  function transfer(address recipient, uint256 amount) external returns (bool);
  function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
  function allowance(address owner, address spender) external view returns (uint256);
  function approve(address spender, uint256 amount) external returns (bool);
  event Transfer(address indexed from, address indexed to, uint256 value);
  event Approval(address indexed owner, address indexed spender, uint256 value);
}

interface ERC165 {
  function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

A contract that wants to accept ERC1363 tokens via transferAndCall or transferFromAndCall MUST implement the following interface:

/**
 * @title ERC1363Receiver interface
 * @dev Interface for any contract that wants to support `transferAndCall` or `transferFromAndCall`
 *  from ERC1363 token contracts.
 */
interface ERC1363Receiver {
  /*
   * Note: the ERC-165 identifier for this interface is 0x88a7ca5c.
   * 0x88a7ca5c === bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))
   */

  /**
   * @notice Handle the receipt of ERC1363 tokens
   * @dev Any ERC1363 smart contract calls this function on the recipient
   * after a `transfer` or a `transferFrom`. This function MAY throw to revert and reject the
   * transfer. Return of other than the magic value MUST result in the
   * transaction being reverted.
   * Note: the token contract address is always the message sender.
   * @param spender address The address which called `transferAndCall` or `transferFromAndCall` function
   * @param sender address The address which are token transferred from
   * @param amount uint256 The amount of tokens transferred
   * @param data bytes Additional data with no specified format
   * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`
   *  unless throwing
   */
  function onTransferReceived(address spender, address sender, uint256 amount, bytes memory data) external returns (bytes4);
}

A contract that wants to accept ERC1363 tokens via approveAndCall MUST implement the following interface:

/**
 * @title ERC1363Spender interface
 * @dev Interface for any contract that wants to support `approveAndCall`
 *  from ERC1363 token contracts.
 */
interface ERC1363Spender {
  /*
   * Note: the ERC-165 identifier for this interface is 0x7b04a2d0.
   * 0x7b04a2d0 === bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))
   */

  /**
   * @notice Handle the approval of ERC1363 tokens
   * @dev Any ERC1363 smart contract calls this function on the recipient
   * after an `approve`. This function MAY throw to revert and reject the
   * approval. Return of other than the magic value MUST result in the
   * transaction being reverted.
   * Note: the token contract address is always the message sender.
   * @param sender address The address which called `approveAndCall` function
   * @param amount uint256 The amount of tokens to be spent
   * @param data bytes Additional data with no specified format
   * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`
   *  unless throwing
   */
  function onApprovalReceived(address sender, uint256 amount, bytes memory data) external returns (bytes4);
}

Note that transferAndCall and transferFromAndCall MUST revert if the recipient is an EOA address, because EOA recipients do not implement the required ERC1363Receiver interface.

Note that approveAndCall MUST revert if the spender is an EOA address, because EOA spenders do not implement the required ERC1363Spender interface.

Rationale

The choice to use transferAndCall, transferFromAndCall and approveAndCall derives from the EIP-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 contracts.

Backwards Compatibility

This proposal has been inspired also by many previous informal standards.
Unlike these proposals, EIP-1363 doesn't override the EIP-20 transfer and transferFrom methods and defines the interfaces IDs to be implemented maintaining backward compatibility with EIP-20.

Security Considerations

The approveAndCall and transferFromAndCall methods can be affected by the same issue of the standard EIP-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).

Test Cases

The repository with the reference implementation contains all the tests.

Implementation

The GitHub repository vittominacori/erc1363-payable-token contains the reference implementation.
The reference implementation is also available via npm and can be installed with npm install erc-payable-token.

[HarryR]

As #223 has been closed after a lot of discussion I'm linking to it from here as I believe ERC-1363 is a good replacement for ERC-223.