status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

ERC-1363: Move to Last Call (#2617)

Browse Source 
Defines a token interface for ERC-20 tokens that supports executing recipient code on `transfer` or spender code on `approve`.
This commit is contained in:
Vittorio Minacori 2020-09-13 12:24:11 +02:00 committed by GitHub
parent 3750af8059
commit 64fefe6a64
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
EIPS/eip-1363.md
View File

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