此文旨在详细解释以太坊代币的各项标准，如果大家认为有新的或者错误的代币标准需要添加以及修改，请随时提出。同时，也希望大家能对这些代币标准提出更好的描述方法以及指出它们之间的关系，因为很多代币的解释其实都是从相关的提议说明中摘取出来的。

在提出任何建议或者需求之前，请大家填写列表元素模板。如果不同意列表中的信息，大家也可以提出异议。我个人建议可以把目的非常接近的提议整合起来，以便于更加清晰地理解它们。为了保持透明度，没人会对内容做出审核，只要信息满足的提案都会涵盖进去，其中不安全或者平庸的提案会进行关闭处理，然后会从列表中移除。如果最后有足够多的人支持移除某个提案，那么它就会从列表移除。

ERC-20：标准的可替代性代币（EIP-20）
可替代型代币（同质代币）的标准 API，包括转账和余额跟踪的功能。

ERC-223: 保护投资者以防意外的合约转账 (ERC-223)

ERC20 代币标准很可能会造成终端用户的资金丢失，主要的问题在于无法处理通过 ERC20 代币的转账函数执行的 ERC20 收入交易。ERC-233 定义了一个标准函数，代币合约以及使用特定代币的合约能够用以防止意外发送代币到（不支持该标准的）合约中，同时也让代币的转账就像以太坊转账一样。

相关的标准：

ERC-667

ERC-777

ERC-995

ERC-667: transferAndCall 代币标准 (ERC-667)

transferAndCall 和 transfer(address,uint256,bytes) 的功能类似，但是前者却可以让操作者不会因为疏忽把代币锁定在非ERC223兼容的合约。它和 ERC223 的 transfer(address,uint256,bytes) 函数不同之处仅仅在于名称，但是这个区别也可以让大家很容易地分清楚 ERC223 代币和 ERC20 + ERC667 混合代币。

非常相关的标准：

ERC-223

ERC-777

ERC-995

ERC-721：非同质代币标准 (EIP-721)

虽然可替代的代币可以继续分解，但是非同质代币（NFTs）却是不可以的。NFTs 可以作为产权，并且进行交易，同时也能委托给第三方中介/钱包/拍卖商（“操作人员”）。NFTs 也能代表数字资产或者实物资产的所有权。

ERC-777：基于操作者的代币标准 (ERC-777)

和授权第三方代表用户进行交易不同，ERC-777 提议使用用户和操作者之间的布尔匹配（Boolean Mapping）模式。这就会简化编程语言和授权过程，同时也减少了 Gas 的消耗。777 标准也包含数据传递的功能。

非常相关的标准：

ERC-223

ERC-667

ERC-995

相关的标准：

EIP-20

ERC-809 : 非同质代币的租赁标准(ERC-809)

竞用品：如果有人在使用某样东西，其他人就不可能同时使用，那么就称这个东西为竞用品（校对注：经济学概念，或译为“竞争品”，与“public good”相对。对后者而言，多人可同时使用同一物品而不会互相干扰）。例如，正在开车这个事件是竞争使用的，但是看日落则是大家都可以同时做到的。

非同质物品：如果不能某样东西不能互相进行交换，我们就称这个东西是非同质的。例如，某人的汽车是非同质的，但是 Ether 是可替代的。

ERC-809 标准可以让用户使用一系列指令来出租他们的非同质化代币（NTFs），因此，用户从单个的钱包界面就可以看到过去和现在的租赁协议。

ERC-827 : transferFromAndCall & approveAndCall (ERC-827)

该标准不安全，故移除。

ERC-864：NFTs 共有产权 (ERC-864)

这项标准提议旨在 NFT 合约中分享 NTF 的所有权。

相关的标准：

EIP-721

特别相关的标准：

ERC-981

ERC-865 : TransferPreSigned (ERC-865)

这项标准定义了代币合约可以使用的一种标准函数，用户可用于委托第三方帮忙转账。这个第三方会支付 Gas，然后以代币的形式向交易发起方收取费用。

相关的标准：

EIP-20

特别相关的标准：

ERC-965

ERC-874: 加权的不可替代代币 (ERC-874)

不是所有的 NFT 都是同等条件下创造的，但是又没有东西可以分辨 NFT。加权的方法可以让去中心化自治组织（DAO）或者其他外部机构了解到独特资产拥有的价值。

相关的标准

EIP-721

ERC-888: 多维代币标准 (ERC-888)

多维代币体系的模型，其使用标识符代表余额和数据。

相关的标准：

EIP-20

EIP-721

非常相关的标准：

ERC-994

ERC-998

ERC-1155

ERC-1178

ERC-1203

ERC-918: 可挖矿的代币标准(EIP-918)

标准化工作量证明算法的挖矿代币标准。

相关的标准

EIP-20

ERC-965 : sendByCheque (ERC-965)

这个标准旨在让提前签署的信息可以批准第三方来执行代币转账，并且初始转账者无需首先进行链上转账。转账者只需要签署信息，那么第三方就会通过签名来调用 sendByCheque() 。

相关的标准：

EIP-20

非常相关的标准：

ERC-865

ERC-981: 部分拥有权标准 (ERC-981)

这个标准描述了发行代币的全新以太坊接口，其代币资产的拥有者会有固定的代币在市场上进行交易，并且代表了 100% 的拥有权。然后他们可以选择将代币进行分解，从而提高数字资产的可互换性。

相关的标准：

EIP-721

非常相关的标准：

ERC-864

ERC-994: 委托性非同质代币标准 (ERC-994)

委托性非同质代币（DNFTs）是对 ERC721 标准的延伸，该标准可以用来在以太坊注册土地和实物产权。NFTs 是类似树一样的联盟型结构（和 DNS 类似），其中 NFTs 可以委托并且在某个空间内对其进行分解。和数字资产（例如以太猫）不同 ，实物资产不仅需要数据库中有个准确的身份，同时还需要现实管辖权范围内的法律效力。土地注册机构作为根 DNFT 就可以建立 DNFT 空间，进而辐射一片广阔的领域，而且，可以将根区域的细分区域委托给现有的产权持有者，以此更新土地登记。

相关标准：

EIP-721

相关标准：

ERC-888

ERC-998

ERC-1155

ERC-1178

ERC-1203

ERC-995: 转账调用前后(ERC-995)

除了 ERC20 的功能，这个标准提供了增强型的代币转账功能。它在转账前后都对转账和授权进行调用，无论接收地址是不是一个合约。

非常相关的标准：

ERC-223

ERC-667

ERC-777

ERC-998: 可合成非同质代币的标准 (ERC-998)

ERC-998 作为标准化扩展，是为了所有非同质代币都能够持有其他非同质 ERC-721 代币或者标准同质化 ERC-20 代币。转移合成代币意味着转移其中的整个层次结构。例如，以太猫中会有打斗和喂食的部分；喂食部分也许就会包含同质化的“食物”代币。

相关的标准：

EIP-20

EIP-721

非常相关的标准：

ERC-888

ERC-994

ERC-1155

ERC-1178

ERC-1203

ERC-1003: 安全合约转账扩展(ERC-1003)

该标准不安全，故移除。

ERC-1067: 可升级代币合约的标准 (ERC-1067)

这个标准描述了更加分布式的代币合约架构，其中带有可以升级的协议，并且可以在协议部署后增加新的功能。

相关的标准：

EIP-20

ERC-1132: 代币锁定能力的标准 (ERC-1132)

这个标准提供了代币在合约内多种用途的时间锁仓功能，而且还不需要转移代币。这个标准也可以获得锁定和非锁定代币（可以转账的代币）的余额。

相关的标准：

EIP-20

ERC-1155: 多代币的标准 (ERC-1155)

追踪多个代币余额和所有权的合约，从而可以提高批量转账的效率。

相关的标准：

EIP-20

EIP-721

非常相关的标准：

ERC-888

ERC-994

ERC-998

ERC-1178

ERC-1203

ERC-1178: 多级别代币的标准 (ERC-1178)

为多个级别（Multiple Class）代币的合约提供标准接口。

非常相关的标准：

ERC-888

ERC-994

ERC-998

ERC-1155

ERC-1203

ERC-1190：非同质版税代币的标准 (ERC-1190)

可以向创造者 以及/或者 所有者支付版税的非同质代币标准接口。

相关的标准：

EIP-721

ERC-1203：多层级代币的标准（ERC-20扩展） (ERC-1203)

多层级代币合约的标准接口，同时也是ERC-20兼容。

非常相关的标准：

ERC-888

ERC-994

ERC-998

ERC-1155

ERC-1178

ERC-1238：不可转账代币的标准 (ERC-1238)

代表“徽章”的不可转账代币。

更多资源

最小化代币（Minime Token） (https://github.com/Giveth/minime)

带有更多功能的 ERC-20 代币：比较容易克隆代币，获得余额转账历史以及代币控制。

瑜伽代币(https://github.com/Giveth/yogatoken)

带有ERC-233功能的最小化代币。

原文链接:https://github.com/PhABC/ethereum-token-standards-list

作者:PhABC

翻译&校对:Eric Wang & 阿剑

本文转自以太坊爱好者，原文链接：https://ethfans.org/posts/ethereum-token-standards-list-1

以太坊的以太币和所有代币用的是一样的地址。

比如查询0x986ccf5234d9cfbb25246f1a5bfa51f4ccfcb308这个地址的余额，

可以在查看币种处选择不同的代币

不管是余额还是交易都会有代币标识，区块都是用的以太坊的。一个以太坊的区块可以包含很多不同种类代币的交易

交易量为0eth的都是代币的交易。

基于以太坊智能合约发行以太坊代币

---

---

编写智能合约

pragma solidity ^0.4.16;

interface tokenRecipient { function receiveApproval(address _from, uint256 _value, address _token, bytes _extraData) external; }

contract WPHCoin {
    // Public variables of the token
    string public name;
    string public symbol;
    uint8 public decimals = 18;
    // 18 decimals is the strongly suggested default, avoid changing it
    uint256 public totalSupply;

    // This creates an array with all balances
    mapping (address => uint256) public balanceOf;
    mapping (address => mapping (address => uint256)) public allowance;

    // This generates a public event on the blockchain that will notify clients
    event Transfer(address indexed from, address indexed to, uint256 value);
    
    // This generates a public event on the blockchain that will notify clients
    event Approval(address indexed _owner, address indexed _spender, uint256 _value);

    // This notifies clients about the amount burnt
    event Burn(address indexed from, uint256 value);

    /**
     * Constructor function
     *
     * Initializes contract with initial supply tokens to the creator of the contract
     */
    function TokenERC20(
        uint256 initialSupply,
        string tokenName,
        string tokenSymbol
    ) public {
        totalSupply = 5000000000000000000000;  
        balanceOf[msg.sender] = totalSupply; 
        name = "WPHCoin";
        symbol = "WPH";
    }

    /**
     * Internal transfer, only can be called by this contract
     */
    function _transfer(address _from, address _to, uint _value) internal {
        // Prevent transfer to 0x0 address. Use burn() instead
        require(_to != 0x0);
        // Check if the sender has enough
        require(balanceOf[_from] >= _value);
        // Check for overflows
        require(balanceOf[_to] + _value >= balanceOf[_to]);
        // Save this for an assertion in the future
        uint previousBalances = balanceOf[_from] + balanceOf[_to];
        // Subtract from the sender
        balanceOf[_from] -= _value;
        // Add the same to the recipient
        balanceOf[_to] += _value;
        emit Transfer(_from, _to, _value);
        // Asserts are used to use static analysis to find bugs in your code. They should never fail
        assert(balanceOf[_from] + balanceOf[_to] == previousBalances);
    }

    /**
     * Transfer tokens
     *
     * Send `_value` tokens to `_to` from your account
     *
     * @param _to The address of the recipient
     * @param _value the amount to send
     */
    function transfer(address _to, uint256 _value) public returns (bool success) {
        _transfer(msg.sender, _to, _value);
        return true;
    }

    /**
     * Transfer tokens from other address
     *
     * Send `_value` tokens to `_to` on behalf of `_from`
     *
     * @param _from The address of the sender
     * @param _to The address of the recipient
     * @param _value the amount to send
     */
    function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) {
        require(_value <= allowance[_from][msg.sender]);     // Check allowance
        allowance[_from][msg.sender] -= _value;
        _transfer(_from, _to, _value);
        return true;
    }

    /**
     * Set allowance for other address
     *
     * Allows `_spender` to spend no more than `_value` tokens on your behalf
     *
     * @param _spender The address authorized to spend
     * @param _value the max amount they can spend
     */
    function approve(address _spender, uint256 _value) public
        returns (bool success) {
        allowance[msg.sender][_spender] = _value;
        emit Approval(msg.sender, _spender, _value);
        return true;
    }

    /**
     * Set allowance for other address and notify
     *
     * Allows `_spender` to spend no more than `_value` tokens on your behalf, and then ping the contract about it
     *
     * @param _spender The address authorized to spend
     * @param _value the max amount they can spend
     * @param _extraData some extra information to send to the approved contract
     */
    function approveAndCall(address _spender, uint256 _value, bytes _extraData)
        public
        returns (bool success) {
        tokenRecipient spender = tokenRecipient(_spender);
        if (approve(_spender, _value)) {
            spender.receiveApproval(msg.sender, _value, this, _extraData);
            return true;
        }
    }

    /**
     * Destroy tokens
     *
     * Remove `_value` tokens from the system irreversibly
     *
     * @param _value the amount of money to burn
     */
    function burn(uint256 _value) public returns (bool success) {
        require(balanceOf[msg.sender] >= _value);   // Check if the sender has enough
        balanceOf[msg.sender] -= _value;            // Subtract from the sender
        totalSupply -= _value;                      // Updates totalSupply
        emit Burn(msg.sender, _value);
        return true;
    }

    /**
     * Destroy tokens from other account
     *
     * Remove `_value` tokens from the system irreversibly on behalf of `_from`.
     *
     * @param _from the address of the sender
     * @param _value the amount of money to burn
     */
    function burnFrom(address _from, uint256 _value) public returns (bool success) {
        require(balanceOf[_from] >= _value);                // Check if the targeted balance is enough
        require(_value <= allowance[_from][msg.sender]);    // Check allowance
        balanceOf[_from] -= _value;                         // Subtract from the targeted balance
        allowance[_from][msg.sender] -= _value;             // Subtract from the sender's allowance
        totalSupply -= _value;                              // Update totalSupply
        emit Burn(_from, _value);
        return true;
    }
}

name ： 代币名称
symbol： 代币符号
decimals： 代币小数点位数，代币的最小单位， 18表示我们可以拥有 .0000000000000000001单位个代币。
totalSupply: 发行代币总量。

---

---

编译智能合约

前往 以太坊官方智能合约编码器
新编码器地址：https://remix.ethereum.org
旧编码器地址：https://ethereum.github.io/browser-solidity

新编码器编码方法：

• 将编写好的智能合约放入sol文件中。

• 按照下图顺序点击编译

其中第二步Compiler的版本选择0.4.25+commit.8f1就不会报错。

老编码器编码方法：

• 选好版本

• 提交

• 付钱
  
  

---

---

验证智能合约

以太区块链网站

提交信息验证成功后，记录ABI值

---

---

将代币加入钱包

前往 MyEtherWallet钱包网页

---

---

转出代币

右下角

---

---