3.6 ERC1400(ERC1410.ERC1411)

状态：

草稿(Draft)

提交记录：

1)ERC 1410: Partially Fungible Token Standard:

https://github.com/ethereum/EIPs/issues/1410

2)ERC 1400: Security Token Standard #1411

https://github.com/ethereum/EIPs/issues/1411

标准说明

推荐样例：

https://blog.neufund.org/good-protocols-how-to-properly-standardize-security-tokens-95ff83c81c4a

标准说明

无论是 ERC20 还是 ERC777.每个单位的 Token 都是相同的，并无附加属性，属于 fungible token(同质化代币/可互换 Token)。ERC721标准的 Token，每个 Token 均有不同的ID，不同ID可以有不同的解释，属于 no-fungible token(非同质化 Token，不可互换 Token)。

ERC1410标准的 Token 属于Partially-Fungible Token (部分可互换 Token )，将 ERC20/ERC777 中不存在解释属性的余额，附加额外的信息，从而划分成不同的部分，就可以做一些操作上的限制(例如：某些操作只限定于指定 tranche 的 Token，某些操作优先消耗指定tranche的 Token)。

ERC1400 则是继承 ERC1410 标准，增加了证券相关业务会使用到的函数：证券增发，相关法律文件存储等。

先前一些证券型 Token 的合约大多是在 ERC20 标准的基础上，通过维护一个或多个以太坊地址集合，对这部分地址做出了划分：是否通过kyc，是否处于锁定期等，来进行转账上的限制。这些都是在地址层面做出不同的解释。而 ERC1400 对 Token 本身做了不同解释，以适用于更复杂的证券相关业务场景。

关于ERC20.以及其它ERC成员的关系，可见下图：

函数接口说明

/// @title ERC-1410 Partially Fungible Token Standard

/// @dev See https://github.com/SecurityTokenStandard/EIP-Spec

interface IERC1410 is IERC777 {

// Token Information

function balanceOfByTranche(bytes32 _tranche, address _tokenHolder) external view returns (uint256);

function tranchesOf(address _tokenHolder) external view returns (bytes32[]);

// Token Transfers

function sendByTranche(bytes32 _tranche, address _to, uint256 _amount, bytes _data) external returns (bytes32);

function sendByTranches(bytes32[] _tranches, address _to, uint256[] _amounts, bytes _data) external returns (bytes32[]);

function operatorSendByTranche(bytes32 _tranche, address _from, address _to, uint256 _amount, bytes _data, bytes _operatorData) external returns (bytes32);

function operatorSendByTranches(bytes32[] _tranches, address _from, address _to, uint256[] _amounts, bytes _data, bytes _operatorData) external returns (bytes32[]);

// Default Tranche Management

function getDefaultTranches(address _tokenHolder) external view returns (bytes32[]);

function setDefaultTranche(bytes32[] _tranches) external;

// Operators

function defaultOperatorsByTranche(bytes32 _tranche) external view returns (address[]);

function authorizeOperatorByTranche(bytes32 _tranche, address _operator) external;

function revokeOperatorByTranche(bytes32 _tranche, address _operator) external;

function isOperatorForTranche(bytes32 _tranche, address _operator, address _tokenHolder) external view returns (bool);

// Transfer Events

event SentByTranche(

bytes32 indexed fromTranche,

address operator,

address indexed from,

address indexed to,

uint256 amount,

bytes data,

bytes operatorData

);

event ChangedTranche(

bytes32 indexed fromTranche,

bytes32 indexed toTranche,

uint256 amount,

);

// Operator Events

event AuthorizedOperator(address indexed operator, address indexed tokenHolder);

event RevokedOperator(address indexed operator, address indexed tokenHolder);

event AuthorizedOperatorByTranche(bytes32 indexed tranche, address indexed operator, address indexed tokenHolder);

event RevokedOperatorByTranche(bytes32 indexed tranche, address indexed operator, address indexed tokenHolder);

}

/// @title IERCST Security Token Standard (EIP 1400)

/// @dev See https://github.com/SecurityTokenStandard/EIP-Spec

interface IERCST is IERCPFT {

// Document Management

function getDocument(bytes32 _name) external view returns (string, bytes32);

function setDocument(bytes32 _name, string _uri, bytes32 _documentHash) external;

// Controller Operation

function isControllable() external view returns (bool);

// Token Issuance

function isIssuable() external view returns (bool);

function issueByTranche(bytes32 _tranche, address _tokenHolder, uint256 _amount, bytes _data) external;

event IssuedByTranche(bytes32 indexed tranche, address indexed operator, address indexed to, uint256 amount, bytes data, bytes operatorData);

// Token Redemption

function redeemByTranche(bytes32 _tranche, uint256 _amount, bytes _data) external;

function operatorRedeemByTranche(bytes32 _tranche, address _tokenHolder, uint256 _amount, bytes _operatorData) external;

event RedeemedByTranche(bytes32 indexed tranche, address indexed operator, address indexed from, uint256 amount, bytes operatorData);

// Transfer Validity

function canSend(address _from, address _to, bytes32 _tranche, uint256 _amount, bytes _data) external view returns (byte, bytes32. bytes32);

}

4、ERC721系列

4.1 ERC721

状态：

定稿(Final)

提交记录：

https://github.com/ethereum/EIPs/issues/721

标准说明：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

推荐样例：

1)https:///OpenZeppelin/openzeppelin-solidity/tree/master/contracts/token/ERC721

ERC-721与ERC-20和ERC-223都大不相同。 它描述了一个不可互换的通证，官方简要解释是Non-Fungible Tokens，简写为NFTs，多翻译为非同质代币。 这意味着每个通证是完全不同的，并且每个通证对不同的用户都有不同的价值。 理解这种通证的一个方法就是回忆CryptoKittes。 每一个数字猫都是独立的，其价值取决于其稀缺性和用户的购买欲。

ERC-721令牌可用于任何交易所，但通证价值是“每个通证的唯一性和稀缺性所决定的结果”。标准中规定的接口函数包括name、symbol、totalSupply、balanceOf、ownerOf、approve、takeOwnership 、 transfer 、tokenOfOwnerByIndex和tokenMetadata 。 它还定义了两个事件： Transfer和Approval 。 Gerald Nash的 这篇文章很好地解释了可互换性的概念。

函数接口说明：

balanceOf(address _owner):

返回由_owner 持有的NFTs的数量。

ownerOf(uint256 _tokenId):

返回tokenId代币持有者的地址。

exists(uint256 _tokenId)：

tokenId代币是否存在，返回BOOL值;

approve(address _to, uint256 _tokenId):

授予地址_to具有_tokenId的控制权，方法成功后需触发Approval 事件。

getApproved(uint256 _tokenId)：

获得_tokenId授权的地址;

setApprovalForAll(address _operator, bool _approved):

授予地址_operator具有所有NFTs的控制权，成功后需触发ApprovalForAll事件。

isApprovedForAll(address _owner, address _operator)：

用来查询授权。

transferFrom(address _from, address _to, uint256 _tokenId)

不建议使用本函数，建议使用safeTransferFrom函数。

safeTransferFrom(address _from, address _to, uint256 _tokenId):

把_tokenId代币从_from账户安全转移到_to账户，安全是指如果目标地址为合约地址，则执行onERC721Received进行资产转移，否则的话交易会回滚;如果目标地址为外部账号地址，则正常转移。

更深度分析的文章参考《【基于ERC721的区块链游戏】迷恋猫从玩耍到开发》。

4.2 ERC875

状态：

还处于pull request下(issue)

提交记录：

https://github.com/ethereum/EIPs/issues/875

标准说明：

推荐样例：

https://github.com/alpha-wallet/ERC875-Example

AlphaWallet自主开发了ERC875协议族。该协议不仅会让数字资产变得具有收藏价值，同时也能帮助现实世界中不可拆分替代、具有物权唯一性的资产上链，这就能为线下服务的链上操作提供了可能性。

虽然另一种协议ERC721也能实现token的不可置换性，但其存在需要交易双方支付gas费用、无法简单实现原子化交易等一些不易于用户使用的问题。

ERC875内置了两个密码学协议， 一方面能够简单实现原子化交易(atomic swap)——直接搭建去中心化市场、降低普通用户使用门槛，卖家无需持有以太币，买家支付一次gas即能完成;另外一方面可以简单打包处理大量交易。

拿基于ERC721的加密猫来说，换用ERC875协议的话，能够实现。用户在商家网站法币购猫，通过MagicLink免费把猫导入用户的钱包，之后用户还可以在不需要持有以太币的情况下，通过MagicLink把猫售出或者免费转让，全部过程都是无中心的原子化交易。另外商家可以一次批发100只猫给分销商。

接口函数或者变量说明

totalTickets:

inventory:

ticketIndex:

expiryTimeStamp:

owner:

admin:

transferFee:

numOfTransfers:

name:

symbol:

decimals:

Token(uint256[] numberOfTokens, string evName,uint expiry, string eventSymbol, address adminAddr):

构建函数，样例如example: [1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15], “MJ comeback”, 1603152000. “MJC”, “0x007bEe82BDd9e866b2bd114780a47f2261C684E3″]

getDecimals():

返回代币的小数点后位数值;

trade(uint256 expiry,uint256[] tokenIndices,uint8 v,bytes32 r,bytes32 s):

交易函数，例如：0. [3. 4], 27. “0x2C011885E2D8FF02F813A4CB83EC51E1BFD5A7848B3B3400AE746FB08ADCFBFB”, “0x21E80BAD65535DA1D692B4CEE3E740CD3282CCDC0174D4CF1E2F70483A6F4EB2″

encodeMessage(bytes12 prefix, uint value,uint expiry, uint256[] tokenIndices):

name():

返回代币名称;

symbol():

返回代币表示;

getAmountTransferred():

返回已传输的数量;

isContractExpired()：

合约是否过期;

balanceOf(address _owner)：

返回账户余额;

myBalance()：

transfer(address _to, uint256[] tokenIndices)：

资产转账;

transferFrom(address _from, address _to, uint256[] tokenIndices)：

endContract()：

结束合约;

getContractAddress()：

获取合约地址;

4.3 ERC998

状态：

草稿(Draft)

提交记录：

https://github.com/ethereum/EIPs/issues/998

标准说明：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-998.md

推荐样例：

https://github.com/mattlockyer/composables-998

不同的ERC代币可以被兼容的ERC-998代币既代表一组相似资产(ERC-20代币)，一种独特资产的分类(ERC-721代币)，或者内嵌于单比交易的混合体。

这个协议是以不可以替代代币为基础的全新复杂型数字资产。一个ERC-998代币可以作为一个数字资产投资组合。

中心资产和辅助资产的结合

第一个使用案例是可以和不同数字资产和零件结合外加附加增值功能的中心NFT币。增值可以通过个人花费时间和精力，或者购买来实现。

在奢侈品行业里，这些可以作为应用于不同时尚品牌的“外表”和“包装”。 比如说，中心的不可替代货币是外表，可以辅助鞋子和钱包，每一个都代表了他们自己的NFT。这一整个套装都作为一部分组合到ERC-998代币里面。

单一资产的几个组成部分

作为附加债券的一部分，单一的数字资产可以被ERC-998代币群组所代表。因为每一个部分都是由自己的NFT被独特的体现出来的，NFT代币组合可以保证货品的绝对真实性。然而，除非依附于实际商品的形式，每一个NFT都没有自己的价值。这是一个可以附加在类似手表，珠宝这样价值商品上的非常强势的防伪手段。

上图所示为劳力士的三个组件，每个组件都有一个单独的序列号 – 表壳、表面和指针。单独来看，这些部件几乎没有任何价值，但它们一起构成了一个真正的劳力士手表，由一个ERC-998代币所代表。

分组集合

通常被认为是组合的任何东西，例如一副牌，一本历史邮票或罕见的硬币收集等，可以在一个组合型代币下结合在一起。因此，完整的组合可以由单个数字资产表示。

大多数奢侈品牌都有很大众的产品，每年都会使用重新设计的型号，这些产品往往成为收藏品。在奢侈品战略下，消费者购买经典和品牌，这些都是通过多年来产品的演变出来的。作为上图中的示例，该品牌在三年内发布了其第一、二、三代模型，这些模型被分组为一个组合代币。

同时，这也更为品牌加强与老客户的联系。例如，如果用户可以通过Smart-Links这样可组合的代币，显示他们对某个品牌的所有收藏品，那么该品牌将能够通过独家邀请和优惠来奖励这位客户。

4.4 ERC1155

状态：

草稿(Draft)

提交记录：

https://github.com/ethereum/EIPs/issues/1155

标准说明：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md

推荐样例：

https://enjincoin.io/

ERC-1155是一种定义token的新标准，1155是这种方法的编号。1155标准定义了一种解决上述问题的新方法。现在『物品』(可能包含ERC20的token或ERC721的token或两者都有)可以被单一的一个合约(打包处理)来定义了。合约里包含区别token们所需的最小量的数据。合约的状态包含了每个token ID的配置信息和管理收集的所有行为。ERC-1155的灵活性更强，它使得开发者可以自行选择是批量生成某一种特定的token，还是构建不可被复制的惟一元数据。

ERC-1155支持原子交换，“原子交换”是指不通过中介物而将一种token换成为另外一种token。

ERC-1155的最大进步就是可以融合不同token(可能是“可替换”的代币与“不可替换”的代币的混合体)进行“打包处理”。

函数接口说明：

name(uint256 _itemId)：

symbol(uint256 _itemId)：