-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
ERC20 Token Standard #610
Changes from all commits
80fa7db
4f98798
d540a40
c96876e
2af51d6
b5902d3
a447ded
ed1c87a
efa1fc7
dd7e548
94bc431
e0cc8c2
3a45fb1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,184 @@ | ||
## Preamble | ||
|
||
EIP: 20 | ||
Title: ERC-20 Token Standard | ||
Author: Fabian Vogelsteller <fabian@ethereum.org>, Vitalik Buterin <vitalik.buterin@ethereum.org> | ||
Type: Standard | ||
Category: ERC | ||
Status: Accepted | ||
Created: 2015-11-19 | ||
|
||
|
||
## Simple Summary | ||
|
||
A standard interface for tokens. | ||
|
||
|
||
## Abstract | ||
|
||
The following standard allows for the implementation of a standard API for tokens within smart contracts. | ||
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. | ||
|
||
|
||
## Motivation | ||
|
||
A standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges. | ||
|
||
|
||
## Specification | ||
|
||
## Token | ||
### Methods | ||
|
||
**NOTE**: Callers MUST handle `false` from `returns (bool success)`. Callers MUST NOT assume that `false` is never returned! | ||
|
||
|
||
#### name | ||
|
||
Returns the name of the token - e.g. `"MyToken"`. | ||
|
||
OPTIONAL - This method can be used to improve usability, | ||
but interfaces and other contracts MUST NOT expect these values to be present. | ||
|
||
|
||
``` js | ||
function name() constant returns (string name) | ||
``` | ||
|
||
|
||
#### symbol | ||
|
||
Returns the symbol of the token. E.g. "HIX". | ||
|
||
OPTIONAL - This method can be used to improve usability, | ||
but interfaces and other contracts MUST NOT expect these values to be present. | ||
|
||
``` js | ||
function symbol() constant returns (string symbol) | ||
``` | ||
|
||
|
||
|
||
#### decimals | ||
|
||
Returns the number of decimals the token uses - e.g. `8`, means to divide the token amount by `100000000` to get its user representation. | ||
|
||
OPTIONAL - This method can be used to improve usability, | ||
but interfaces and other contracts MUST NOT expect these values to be present. | ||
|
||
``` js | ||
function decimals() constant returns (uint8 decimals) | ||
``` | ||
|
||
|
||
#### totalSupply | ||
|
||
Returns the total token supply. | ||
|
||
``` js | ||
function totalSupply() constant returns (uint256 totalSupply) | ||
``` | ||
|
||
|
||
|
||
#### balanceOf | ||
|
||
Returns the account balance of another account with address `_owner`. | ||
|
||
``` js | ||
function balanceOf(address _owner) constant returns (uint256 balance) | ||
``` | ||
|
||
|
||
|
||
#### transfer | ||
|
||
Transfers `_value` amount of tokens to address `_to`, and MUST fire the `Transfer` event. | ||
The function SHOULD `throw` if the `_from` account balance does not have enough tokens to spend. | ||
|
||
A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created. | ||
|
||
*Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. | ||
|
||
``` js | ||
function transfer(address _to, uint256 _value) returns (bool success) | ||
``` | ||
|
||
|
||
|
||
#### transferFrom | ||
|
||
Transfers `_value` amount of tokens from address `_from` to address `_to`, and MUST fire the `Transfer` event. | ||
|
||
The `transferFrom` method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. | ||
This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. | ||
The function SHOULD `throw` unless the `_from` account has deliberately authorized the sender of the message via some mechanism. | ||
|
||
*Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event. | ||
|
||
``` js | ||
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) | ||
``` | ||
|
||
|
||
|
||
#### approve | ||
|
||
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](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/) and discussed [here](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it's a pity that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can change that in another standard, but this one needs to be formalised |
||
clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to `0` before setting it to another value for the same spender. | ||
THOUGH The contract itself shouldn't enforce it, to allow backwards compatilibilty with contracts deployed before | ||
|
||
``` js | ||
function approve(address _spender, uint256 _value) returns (bool success) | ||
``` | ||
|
||
|
||
#### allowance | ||
|
||
Returns the amount which `_spender` is still allowed to withdraw from `_owner`. | ||
|
||
``` js | ||
function allowance(address _owner, address _spender) constant returns (uint256 remaining) | ||
``` | ||
|
||
|
||
|
||
### Events | ||
|
||
|
||
#### Transfer | ||
|
||
MUST trigger when tokens are transferred, including zero value transfers. | ||
|
||
``` js | ||
event Transfer(address indexed _from, address indexed _to, uint256 _value) | ||
``` | ||
|
||
|
||
|
||
#### Approval | ||
|
||
MUST trigger on any successful call to `approve(address _spender, uint256 _value)`. | ||
|
||
``` js | ||
event Approval(address indexed _owner, address indexed _spender, uint256 _value) | ||
``` | ||
|
||
|
||
|
||
## Implementation | ||
|
||
There are already plenty of ERC20-compliant tokens deployed on the Ethereum network. | ||
Different implementations have been written by various teams that have different trade-offs: from gas saving to improved security. | ||
|
||
#### Example implementations are available at | ||
- https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol | ||
- https://github.com/ConsenSys/Tokens/blob/master/Token_Contracts/contracts/StandardToken.sol | ||
|
||
#### Implementation of adding the force to 0 before calling "approve" again: | ||
- https://github.com/Giveth/minime/blob/master/contracts/MiniMeToken.sol | ||
|
||
## Copyright | ||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a recommendation to throw if the sender value is 0, as it's most likely an error. If the token wants to have a explicit burn function it should implement so or it should recommend users to send it to any other invalid address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is fine having explicit burn and mint functions but they should call Transfer events as defined in the standard and monitored on etherscan.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anybody any thoughts on that?
I really want to merge that ASAP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frozeman The token implementations I've seen so far (e.g. OpenZeppelin's, but also many others) seem to make no check that
msg.sender
is not0x00..00
, or0xff..ff
, or some other magic number.Personally, I'd leave this out of the standard's text, instead of adding such provisions retroactively, since it was never widely discussed.
EDIT: That is, instead of adding another possibly contentious point that will keep discussion running ad infinitum, just leave it undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing it is contentious because it's already there and block scanners use it. Whether individual dev teams like it or not, the block scanners need to find the tokens, they find the tokens through transfer events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's changing what the spec requires - eg, introducing backwards incompatibilities or new features - and there's adding advice to implementers, or reflecting defacto standardised behaviour. I think recommending a transfer event on minting falls into the latter category rather than the former.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Arachnid See my argument here: #610 (comment)
TL;DR: Without this being a MUST (which it can't be in this PR), tooling can't leverage it meaningfully without creating bugs elsewhere.
I believe etherscan tries to interpret
transfer from 0
asmint
and it results in some tokens having incorrect token allocation charts which leads to significant user confusion. As a SHOULD, I think it encourages other applications to do what etherscan has done (they would be operating under the assumption that most tokens will follow the SHOULD) when in fact I'm unconvinced that most do. So we end up with people building applications/interfaces that are wrong some non-trivial portion of the time with no clear mechanism for resolving that. If this were left out, the theory is that interfaces would stop trying to build against something that isn't widely adopted and therefore they would be less likely to build features that are permanently in a half broken state.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MicahZoltu has the important point which is clarity, defining the standard, and closing. Maybe even just you three @frozeman @Arachnid and @MicahZoltu since you are the most reputable with investment in this discussion, decide and close. I say we all agree now to go with that decision rather than try to agree on the decision itself. Anyone that disagrees should present a valid argument against deciding and closing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just about the least reputable person I know. I recommend not including me in any list of "reputable persons". 😄
I'm 👍 on merging this with or without the SHOULD. I just wanted to make sure my arguments against it were clear and well understood before those that make the merge decisions do so. If @Arachnid / @frozeman (or whoever make the final merge decision) believe they understand my arguments but still disagree with them then consider the issue resolved (unless further discussion/clarification is desired, in which case I'll happily oblige).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIR, at the initial submission of #20, the creation (minting) of tokens was not taken into consideration. The proposal aimed to standartise an interface for transfer of tokens.
In retrospect, I'd say considerations for creation of tokens should have been kept out of this standard proposal, seeing how it has caused a lot of uncertainty.
My comment above:
... was meant to highlight this fact: creation of tokens shouldn't have been within scope of this standard's text.
It's still not too late to leave a
Minted
event outside the scope of this particular standard.