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.

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

ERC20 Token Standard #610

Merged
merged 13 commits into from
Sep 11, 2017
129 changes: 129 additions & 0 deletions EIPS/eip-token-standard.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
This is the suggested template for new EIPs.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this preamble also be included?


Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`.

## Preamble

EIP: <to be assigned> (I Suggest 20)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EIP: 20

Title: <EIP title>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title: ERC-20 Token Standard

Author: Fabian Vogelsteller <fabian@ethereum.org>, Vitalik Buterin <vitalik.buterin@ethereum.org>
Type: Informational
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type: Standard
Category: ERC

Category ERC
Copy link
Member

@ethers ethers Apr 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Category" line can be removed

Status: Draft
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accepted

Created: 2015-11-19


## Simple Summary

Token standard interface.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe revise a bit? "A standard interface for tokens." ?



## Abstract

The following standard allows for people to implement a token standard API withing their smart contracts.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: within

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would also revise this abstract:

"The following standard allows for the implementation of a standard API for tokens within their smart contracts: it primarily provides basic functionality to transfer tokens and allow them to be approved to be spent by another on-chain third party."


This standard provides basic functionality for sending and approving tokens to be spend by a third party.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grammar: use "spent" instead of spend



## Motivation

Following the same standard interface allows those tokens to be used in many wallets and exchanges.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another potential revision:

"A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges."



## Specification

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119 https://www.ietf.org/rfc/rfc2119.txt.

## Token
### Methods

**NOTE**: An important point is that callers should handle `false` from `returns (bool success)`. Callers should not assume that `false` is never returned!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: Callers should handle false from returns (bool success). Callers should not assume that false is never returned!


#### totalSupply

``` js
function totalSupply() constant returns (uint256 totalSupply)
```

Get the total token supply
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use Returns rather than Get for consistency.

Returns the total token supply.



#### balanceOf

``` js
function balanceOf(address _owner) constant returns (uint256 balance)
```

Get the account balance of another account with address `_owner`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returns the account balance of another account with address _owner.



#### transfer

``` js
function transfer(address _to, uint256 _value) returns (bool success)
```

Send `_value` amount of tokens to address `_to`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use "transfer" vs "Send"?



#### transferFrom

``` js
function transferFrom(address _from, address _to, uint256 _value) returns (bool success)
```

Send `_value` amount of tokens from address `_from` to address `_to`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transfers _value amount of tokens from address _from to address _to.


The `transferFrom` method is used for a withdraw workflow, allowing contracts to send tokens on your behalf, for example to "deposit" to a contract address and/or to charge fees in sub-currencies; the command should fail unless the `_from` account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approval:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few minor corrections. Removed the last line as it didn't fit in with the rest of the content.

The transferFrom method is used for a withdraw workflow, allowing contracts to send tokens on your behalf, for example to "deposit" to a contract address and/or charge fees in sub-currencies. The command should fail unless the _from account has deliberately authorized the sender of the message via some mechanism.



#### approve

``` js
function approve(address _spender, uint256 _value) returns (bool success)
```

Allow _spender to withdraw from your account, multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed formatting and a few minor changes.

Allows _spender to withdraw from your account, multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.

NOTE:To prevent attack vectors like the one described here make sure to set the allowance to 0 before setting it to another value for the same spender.

To prevent attack vectors like described here: https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"like the one described here:"

make sure to set the allowance to 0 before setting it to another value for the same spender.


#### allowance

``` js
function allowance(address _owner, address _spender) constant returns (uint256 remaining)
```

Returns the amount which `_spender` is still allowed to withdraw from `_owner`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add period.

Returns the amount which _spender is still allowed to withdraw from _owner.



### Events


#### Transfer

``` js
event Transfer(address indexed _from, address indexed _to, uint256 _value)
```

Triggered when tokens are transferred.


#### Approval

``` js
event Approval(address indexed _owner, address indexed _spender, uint256 _value)
```

Triggered whenever `approve(address _spender, uint256 _value)` is called.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change whenever to when.

Triggered when approve(address _spender, uint256 _value) is called.



## Implementation

Different implementations are available at
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably change this to say: "There are already plenty of ERC20-compliant tokens deployed on the Ethereum network and is the most widely used standard. Different implementations have been written by various teams that have different trade-offs: from gas saving to improved security. Example implementations include:"

- https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol
- https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/contracts/StandardToken.sol

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/Giveth/minime/blob/master/contracts/MiniMeToken.sol
(Please note that the contract is now under contracts subdirectory)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:-D!!!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also like to see the MiniMeToken added to this list. Maintaining historical balance data is key for a number of token use cases.

Implentation adding the force 0 before calling approve again:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling: implementation

- https://github.com/Giveth/minime/blob/master/MiniMeToken.sol

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).