Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-1462: 基础证券型代币

Authors Maxim Kupriianov <mk@atlant.io>, Julian Svirsky <js@atlant.io>
Created 2018-10-01
Discussion Link https://ethereum-magicians.org/t/erc-1462-base-security-token/1501
Requires EIP-20, EIP-1066

简单总结

对 ERC-20 标准代币的扩展,提供对证券法规的遵守和法律上的可执行性。

摘要

本 EIP 定义了对默认代币标准(如 ERC-20)的最小限度的补充,以符合国内和国际法律要求。这些要求包括 KYC(了解您的客户)和 AML(反洗钱)法规,以及锁定账户的代币并限制因法律纠纷而转移代币的能力。此外,还可以附加额外的法律文件,以便在代币和链下法律实体之间建立双重约束关系。

本标准范围尽可能保持狭窄,以避免限制此基础证券型代币的潜在用例。未在本标准中定义的任何附加功能和限制可以在每个项目的基础上执行。

动机

最近已经提出了几个证券型代币标准。示例包括 ERC-1400,以及 ERC-1450。我们对它们中的每一个都感到担忧,主要是因为这些 EIP 中的每一个的范围都包含许多项目特定或市场特定的细节。由于许多 EIP 来自各自的支持公司,它们捕获了许多对于一般情况来说过多的利基需求。

例如,ERC-1411 依赖于 ERC-1410,但它超出了“证券型代币”的范围。此外,它对 ERC-777 的依赖将阻止在 ERC-777 最终确定之前的一段时间内的采用,但该 EIP 中尚未描述现有 ERC-20 工作流程的集成指南。另一个尝试创建更简单的基础标准 ERC-1404 缺少一些重要的点,特别是它没有提供足够的粒度来区分不同的 ERC-20 转移函数,例如 transfertransferFrom。它也没有提供将法律文件绑定到已发行代币的方法。

我们在本 EIP 中提出的是一个简单且非常模块化的解决方案,用于创建适用于最广泛的应用范围的基础证券型代币,因此它可以被其他发行者用于构建。发行者应该能够使用下面提出的函数和实现向代币添加更多限制和策略,但在使用此 ERC 时不得以任何方式受到限制。

规范

ERC-20 代币提供以下基本功能:

contract ERC20 {
    function totalSupply() public view returns (uint256);
    function balanceOf(address who) public view returns (uint256);
    function transfer(address to, uint256 value) public returns (bool);
    function allowance(address owner, address spender) public view returns (uint256);
    function transferFrom(address from, address to, uint256 value) public returns (bool);
    function approve(address spender, uint256 value) public returns (bool);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    event Transfer(address indexed from, address indexed to, uint256 value);
}

这将扩展如下:

interface BaseSecurityToken /* is ERC-20 */ {
    // Checking functions
    // 检查函数
    function checkTransferAllowed (address from, address to, uint256 value) public view returns (byte);
    function checkTransferFromAllowed (address from, address to, uint256 value) public view returns (byte);
    function checkMintAllowed (address to, uint256 value) public view returns (byte);
    function checkBurnAllowed (address from, uint256 value) public view returns (byte);

    // Documentation functions
    // 文档函数
    function attachDocument(bytes32 _name, string _uri, bytes32 _contentHash) external;
    function lookupDocument(bytes32 _name) external view returns (string, bytes32);
}

转移检查函数

我们引入了四个新函数,这些函数应用于检查对于提供的输入是否允许执行操作。每个函数的实现细节留给代币发行者,发行者有责任添加所有必要的检查,以根据 KYC/AML 策略和为特定代币资产设置的法律要求来验证操作。

根据 ERC-1066,每个函数必须从以太坊通用状态代码 (ESC) 集中返回一个状态代码。这些代码的本地化超出了本提案的范围,并且可以通过在应用程序级别采用 ERC-1444 来有选择地解决。如果检查函数允许该操作,则返回状态代码必须为 0x11 (Allowed) 或具有等效但更精确含义的发行者特定代码。如果检查函数不允许该操作,则状态必须为 0x10 (Disallowed) 或具有等效但更精确含义的发行者特定代码。如果发生内部错误,该函数必须从通用代码表或发行者特定的等效代码中返回最相关的代码,例如:0xF0 (Off-Chain Failure)。

对于基于 ERC-20 的代币,

  • 要求使用检查相应 checkTransferAllowed 返回状态代码的逻辑覆盖转移函数。
  • 要求使用检查相应 checkTransferFromAllowed 返回状态代码的逻辑覆盖 transferFrom 函数。
  • 要求使用检查相应 checkTransferFromAllowed 返回状态代码的逻辑覆盖 approve 函数。
  • 如果 token 实现中存在诸如 mintburn 之类的其他函数,则必须覆盖它们,它们应该相应地检查 checkMintAllowedcheckBurnAllowed 状态代码。

对于基于 ERC-777 的代币,

  • 需要使用检查相应返回状态代码的逻辑覆盖 send 函数:
    • checkTransferAllowed 返回状态代码,如果转移代表代币所有者发生;
    • checkTransferFromAllowed 返回状态代码,如果转移代表操作员发生(即委托转移)。
  • 需要使用检查相应 checkBurnAllowed 返回状态代码的逻辑覆盖 burn 函数。
  • 如果 token 实现中存在诸如 mint 之类的其他函数,则必须覆盖它们,例如,如果证券型代币是可铸造的。mint 函数必须调用 checkMintAllowed 并检查其返回状态代码。

对于这两种情况,

  • 为了保证与 ERC-20 和 ERC-777 钱包的兼容性,如果未被发行者的自定义逻辑覆盖,则每个检查函数都必须返回 0x11 (Allowed)。
  • 根据返回的状态代码,如果不允许该操作或发生错误,则所有被覆盖的检查函数都必须恢复。

在检查器函数内部,允许逻辑使用链上可用的任何功能:调用具有白名单/黑名单的注册表合约,使用在同一合约上定义的内置检查逻辑,甚至通过预言机运行链下查询。

文档函数

我们还引入了两个新函数,这些函数应用于文档管理目的。函数 attachDocument 添加一个指向链下文档的引用,其中包含指定的名称、URI 和内容哈希。此标准中未指定哈希算法,但生成的哈希长度不得超过 32 字节。函数 lookupDocument 通过其名称获取引用的文档。

  • 不需要使用文档函数,它们是可选的,并作为法律框架的一部分提供。
  • 要求如果已使用 attachDocument 函数,则文档引用必须具有唯一的名称,不允许覆盖相同名称下的引用。所有实现都必须检查给定名称下的引用是否已存在。

理由

本 EIP 针对基于 ERC-20 和 ERC-777 的代币,尽管由于 ERC-20 的广泛采用,因此最强调的是 ERC-20。但是,此扩展旨在与即将到来的 ERC-777 标准兼容。

所有检查函数都以 check 为前缀命名,因为它们返回检查状态代码,而不是布尔值,因为这对于促进调试和跟踪过程非常重要。发行者有责任实现适当处理返回代码的逻辑。一些处理程序将简单地引发错误,其他处理程序将记录信息以供将来进行流程挖掘。有关状态代码的更多基本原理,请参见 ERC-1066

我们需要两个不同的转移验证函数:checkTransferAllowedcheckTransferFromAllowed,因为相应的 transfertransferFrom 通常在不同的上下文中调用。诸如 ERC-1450 之类的一些代币标准明确禁止使用 transfer,而仅允许使用 transferFrom。可能还存在不同的复杂情况,其中应区别对待 transfertransferFrom。ERC-777 依靠其自身的 send 来转移代币,因此根据其调用上下文在检查器函数之间进行切换是合理的。我们决定省略 checkApprove 函数,因为它将在与 checkTransferFromAllowed 完全相同的上下文中使用。在许多情况下,不仅需要规范证券转移,还需要限制 burnmint 操作,并且为此添加了其他检查器函数。

我们在此处提出的文档功能是创建与链下法律文档的双重约束的必备工具。在 Neufund 的员工激励期权计划 法律框架中可以很好地看到一个例子,该框架实现了完全的法律可执行性:智能合约引用了印刷的 ESOP 条款和条件文档,该文档本身又引用回智能合约。即使在没有法律要求在证券型代币中引用文档的情况下,这也已成为一种广泛采用的做法。但是,几乎总是需要它们,并且这是附加各种类型的有用文档的好方法。

向后兼容性

本 EIP 完全向后兼容,因为它的实现扩展了 ERC-20 和 ERC-777 代币的功能。

实现

  • https://github.com/AtlantPlatform/BaseSecurityToken

版权

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

Citation

Please cite this document as:

Maxim Kupriianov <mk@atlant.io>, Julian Svirsky <js@atlant.io>, "ERC-1462: 基础证券型代币 [DRAFT]," Ethereum Improvement Proposals, no. 1462, October 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1462.