简单总结

令牌的标准接口。

 抽象的

以下标准允许在智能合约中为代币实施标准 API。该标准提供了转移代币的基本功能，并允许批准代币，以便其他链上第三方使用它们。

 动机

标准接口允许以太坊上的任何代币被其他应用程序重用：从钱包到去中心化交易所。

 规格

 令牌

 方法

注意事项：

• 以下规范使用 Solidity 0.4.17（或更高版本）的语法
• 调用者必须false从returns (bool success). 调用者不能假设false永远不会返回！

 姓名

返回令牌的名称 - 例如"MyToken"。

可选 - 此方法可用于提高可用性，但接口和其他合同不得期望这些值存在。

function name() public view returns (string)

 象征

返回令牌的符号。例如“HIX”。

可选 - 此方法可用于提高可用性，但接口和其他合同不得期望这些值存在。

function symbol() public view returns (string)

 小数点

返回令牌使用的小数位数 - 例如8，表示将令牌数量除以100000000得到其用户表示。

可选 - 此方法可用于提高可用性，但接口和其他合同不得期望这些值存在。

function decimals() public view returns (uint8)

 总供给

返回总代币供应量。

function totalSupply() public view returns (uint256)

 余额

返回地址为另一个帐户的帐户余额_owner。

function balanceOf(address _owner) public view returns (uint256 balance)

 转移

将_value一定数量的代币转移到 address _to，并且必须触发该Transfer事件。throw如果消息调用者的账户余额没有足够的代币来消费，则该函数应该。

注意0 值的传输必须被视为正常传输并触发Transfer事件。

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

 从转移

将_value一定数量的代币从 address转移_from到 address _to，并且必须触发Transfer事件。

该transferFrom方法用于提款工作流程，允许合约代表您转移代币。例如，这可用于允许合约代表您转移代币和/或以子货币收取费用。throw除非_from帐户通过某种机制故意授权消息的发送者，否则该函数应该。

注意0 值的传输必须被视为正常传输并触发Transfer事件。

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

 批准

允许_spender多次从您的账户中提款，最多取_value金额。如果再次调用此函数，它会用 覆盖当前限额_value。

注：为了防止攻击向量像一个在这里描述和讨论在这里，客户应该确保建立在这样一种方式，他们首先要设置限额的用户界面0将它设置为另一个值相同花钱之前。虽然合同本身不应该强制执行它，以允许与之前部署的合同向后兼容

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

 津贴

返回_spender仍允许从 中提取的金额_owner。

function allowance(address _owner, address _spender) public view returns (uint256 remaining)

 活动

 转移

必须在代币转移时触发，包括零值转移。

创建新代币的代币合约应该触发 Transfer 事件，_from地址设置为0x0创建代币时。

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

 赞同

必须在对 的任何成功调用时触发approve(address _spender, uint256 _value)。

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

 执行

以太坊网络上已经部署了大量符合 ERC20 的代币。不同的团队编写了不同的实现，它们有不同的权衡：从节省 gas 到提高安全性。

 示例实现可在

• OpenZeppelin 实现
• ConsenSys 实施

 历史

与本标准相关的历史链接：

• Vitalik Buterin 的原始提案：https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs/499c882f3ec123537fc2fccd57eaa29e6032fe4a
• Reddit 讨论：https://www.reddit.com/r/ethereum/comments/3n8fkn/lets_talk_about_the_coin_standard/
• 原始问题 #20：https://github.com/ethereum/EIPs/issues/20

 版权

通过CC0放弃版权和相关权。

引文

请引用本文档为：

Fabian Vogelsteller，Vitalik Buterin，“EIP-20：代币标准”，以太坊改进提案，没有。20，2015 年 11 月。 [在线连载]。可用：https://eips.ethereum.org/EIPS/eip-20。

EIP-20: Token Standard 

 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

NOTES:

• The following specifications use syntax from Solidity 0.4.17 (or above)
• 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.

function name() public view returns (string)

 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.

function symbol() public view returns (string)

 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.

function decimals() public view returns (uint8)

 totalSupply

Returns the total token supply.

function totalSupply() public view returns (uint256)

 balanceOf

Returns the account balance of another account with address _owner.

function balanceOf(address _owner) public view returns (uint256 balance)

 transfer

Transfers _value amount of tokens to address _to, and MUST fire the Transfer event. The function SHOULD throw if the message caller’s account balance does not have enough tokens to spend.

Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transfer(address _to, uint256 _value) public 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.

function transferFrom(address _from, address _to, uint256 _value) public 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 and discussed here, 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 compatibility with contracts deployed before

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

 allowance

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

function allowance(address _owner, address _spender) public view returns (uint256 remaining)

 Events

 Transfer

MUST trigger when tokens are transferred, including zero value transfers.

A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.

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

 Approval

MUST trigger on any successful call to approve(address _spender, uint256 _value).

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

• OpenZeppelin implementation
• ConsenSys implementation

 History

Historical links related to this standard:

• Original proposal from Vitalik Buterin: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs/499c882f3ec123537fc2fccd57eaa29e6032fe4a
• Reddit discussion: https://www.reddit.com/r/ethereum/comments/3n8fkn/lets_talk_about_the_coin_standard/
• Original Issue #20: https://github.com/ethereum/EIPs/issues/20

 Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Fabian Vogelsteller, Vitalik Buterin, "EIP-20: Token Standard," Ethereum Improvement Proposals, no. 20, November 2015. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-20.