Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update ERC-1363: Move motivation and rationale to eip1 recommendation #74

Closed
wants to merge 8 commits into from
Closed

Update ERC-1363: Move motivation and rationale to eip1 recommendation #74

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
9fc9d90
Update preamble and removed the not necessary simple summary section
vittominacori Oct 31, 2023
1638856
Refactor abstract section
vittominacori Oct 31, 2023
957d504
Moves the rationale from motivation into the rationale section
vittominacori Oct 31, 2023
f0148b4
Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…
vittominacori Nov 18, 2023
ee34117
Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…
vittominacori Nov 26, 2023
8d3e5d9
Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…
vittominacori Dec 7, 2023
a7caa9d
Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…
vittominacori Dec 22, 2023
20ee1ff
Merge branch 'master' of https://github.com/ethereum/ERCs into fix/mo…
vittominacori Dec 29, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 31 additions & 21 deletions ERCS/erc-1363.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,43 +1,38 @@
---
eip: 1363
title: Payable Token
description: Fungible token extension that supports executing callbacks on receiver contracts.
author: Vittorio Minacori (@vittominacori)
discussions-to: https://github.com/ethereum/eips/issues/1363
discussions-to: https://ethereum-magicians.org/t/erc-1363-payable-token/16225
status: Final
type: Standards Track
category: ERC
created: 2018-08-30
requires: 20, 165
---

## Simple Summary
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
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.
This proposal defines an extension interface for [ERC-20](./erc-20.md) tokens that supports executing code on a recipient contract after transfers, or code on a spender contract after approvals, in a single transaction.

## Motivation
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.
The following standard allows for the implementation of a standard API for tokens interaction with smart contracts after `transfer`, `transferFrom` or `approve`.
This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party, and then make a callback on the receiver or spender 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.
The following are functions and callbacks introduced by this ERC:

There are many proposed uses of Ethereum smart contracts that can accept [ERC-20](./eip-20.md) payments.
* `transferAndCall` and `transferFromAndCall` will call an `onTransferReceived` on a `ERC1363Receiver` contract.
* `approveAndCall` will call an `onApprovalReceived` on a `ERC1363Spender` contract.

Examples could be
* to create a token payable crowdsale
* selling services for tokens
* paying invoices
* making subscriptions
## Motivation

For these reasons it was named as **"Payable Token"**.
There is no way to execute code on a receiver/spender contract after an ERC-20 `transfer`, `transferFrom` or `approve` so, to perform an action, it is required to send another transaction.
This introduces complexity in UI development and friction on adoption as users must wait for the first transaction to be executed and then submit the second one. They must also pay GAS twice.

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 aims to make tokens capable of performing actions more easily and working without the use of any off-chain listener.
It allows to make a callback on a receiver/spender contract, after a transfer or an approval, in a single transaction.

This proposal has been inspired by the [ERC-721](./eip-721.md) `onERC721Received` and `ERC721TokenReceiver` behaviours.
Tokens defined by this ERC can be used for specific utilities in all cases that require a callback to be executed after a transfer or an approval received.
This ERC is also useful for avoiding token loss or token locking in contracts by verifying the recipient contract's ability to handle tokens.

## Specification
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.
Expand Down Expand Up @@ -192,17 +187,32 @@
```

## Rationale
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.

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

Examples could be:

* creating a token payable crowdsale
* selling services for tokens
* paying invoices
* making subscriptions

For these reasons it was originally named **"Payable Token"**.

The choice to use `transferAndCall`, `transferFromAndCall` and `approveAndCall` derives from the [ERC-20](./erc-20.md) naming.
They want to highlight that they have the same behaviors of `transfer`, `transferFrom` and `approve` with the addition of a callback on receiver or spender contracts.

`ERC1363Receiver` and `ERC1363Spender` were inspired by the [ERC-721](./erc-721.md) `ERC721TokenReceiver` behavior.

## Backwards Compatibility
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.

Check failure on line 208 in ERCS/erc-1363.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
   --> ERCS/erc-1363.md
    |
208 | 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.  
    |
    = help: see https://ethereum.github.io/eipw/markdown-rel-links/

Check failure on line 208 in ERCS/erc-1363.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
   --> ERCS/erc-1363.md
    |
208 | 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 `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 `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)).

Check failure on line 215 in ERCS/erc-1363.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

non-relative link or image 

error[markdown-rel-links]: non-relative link or image
   --> ERCS/erc-1363.md
    |
215 | 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](../LICENSE.md).
Loading