以太坊平台相关的STO协议2

作者: yangzming | 来源:发表于2019-03-01 11:24 被阅读0次

1.7 ERC-1404 简单受限制Token标准

标题：简单受限制Token标准(Simple Restricted Token Standard)
需要的其他标准: None
状态: Draft
官方地址

1.7.1 概述

用于发布带有转移限制的Token的简单且可互操作的标准。以下内容借鉴了顶级发行者、律师事务所、美国相关监管机构和交易所的意见。

1.7.2 摘要

当前的ERC Token标准为社区提供了一个平台，在这个平台上开发一个分布式的经济模型，专注于为真实世界构建Ethereum应用程序。随着这些应用程序的成熟并面临消费者的采用，它们开始与公司治理需求以及法规进行交互。它们不仅必须能够满足企业和监管要求，还必须能够与支撑其关联业务的技术平台进行集成。

以下是一个简单且可扩展的标准，旨在减轻钱包、交易所和发行者的集成负担。

1.7.3 动机

Token发行者需要一种方法来限制ERC-20 Token的转让，以符合证券法和其他合同义务。当前的实现没有解决这些需求。

一些示例:

强制令牌锁定期
执行通过AML/KYC检查
私人房地产投资信托
特拉华州普通公司法股份

此外，Token发行者之间采用的标准有可能演变成自动化遵从性的动态和可互操作的环境。

下面的设计为Token发行者提供了更大的自由/可升级性，同时减少了开发人员和交易所的集成负担。

此外，我们认为应该提供一种模式，在恢复Token转移时，通过该模式可以返回人类可读的消息。Token的转移为何被还原的透明性与转移限制本身的成功实施同等重要。

一个被广泛采用的用于检测Token转移中的限制和消息传递错误的标准将极大地方便未来的交易所、钱包和发行方。

1.7.4 说明

ERC-1404标准建立在ERC-20接口的基础上，增加了两个功能:

contract ERC1404 is ERC20 {
  function detectTransferRestriction (address from, address to, uint256 value) public view returns (uint8);
  function messageForTransferRestriction (uint8 restrictionCode) public view returns (string);
}

detectTransferRestriction和messageForTransferRestriction的逻辑由发行者决定。

唯一的要求是必须在Token的transfer和transferFrom方法中对detectTransferRestriction进行求值判断。

如果在这些转移方法中，detectTransferRestriction返回的值不是0，则应该还原交易。

1.7.5 原理

该标准在ERC-20标准之上提出了两个函数和一个事件。让我们讨论每种方法的基本原理。

detectTransferRestriction - 在此函数中，发行者强制执行其Token转移的限制逻辑。这方面的一些示例可能包括，检查Token接收人是否在白名单中，检查发送方的Token是否在锁定期间冻结，等等。由于实现由发行者决定，因此此函数仅用于标准化应该在何处启动此类逻辑的执行。此外，第三方可以公开调用此函数来检查转移的预期结果。因为这个函数返回的是uint8类型，而不是布尔值或直接返回，所以它允许函数调用者知道传输失败的原因，并将其报告给相关的对手方。
messageForTransferRestriction - 这个函数实际上是message的访问器，它是一种人类可读的解释，解释了交易为什么受到限制。通过标准化消息查找，我们使用户界面构建器能够有效地向用户报告错误。

1.7.6 实现示例

实现示例:

1.8 ERC-1450 用于发行和交易符合SEC规定的证券的兼容安全Token

标题：用于发行和交易符合SEC规定的证券的兼容安全Token
需要的其他标准: ERC-20
状态: Draft
官方地址

1.8.1 概述

ERC-1450是一个与ERC-20兼容的Token，它允许发行代表证券的Token，这些证券必须遵守一项或多项证券法法规：法规众筹、法规D和法规A。

目前还没有一种象征性的标准能够明确地促进证券法律和相关法规的符合性。ERC-20标准不支持融资门户、经纪商、RTA和投资者的受监管角色，也不支持银行保密法/美国爱国者法KYC和AML要求。其他改进(尤其是EIP-1404(简单限制Token标准))试图解决KYC和AML的监管要求。这种方法很新颖，因为RTA完全负责执行KYC和AML，并且应该完全负责transferFrom, mint和burnFrom。

1.8.2 摘要

ERC-1450有助于根据证券法法规CF, D和A的规定记录所售证券的所有权和转让。证券的发行和交易受证券交易委员会(SEC)和美国各州具体的蓝天法律法规的约束。

ERC-1450管理发行和交易期间的证券所有权。发行方是唯一应该创建ERC-1450并分配RTA的角色。RTA是唯一允许执行ERC-1450的mint、burnFrom和transferFrom函数的角色。ERC-1450的transfer函数不允许任何角色执行。

1.8.3 需求

ERC-1450扩展ERC-20。ERC-1450要求只有发行者可以创建一个表示只有RTA管理的安全性的Token。实例化ERC-1450需要Owned和IssuerControlled修饰符，并且只有发行者应该为兼容的Token执行ERC-1450构造函数。ERC-1450扩展了通用Ownable修饰符来描述一个特定的所有者子集，这个子集通过Owned和IssuerControlled修饰符以及功能修饰符onlyOwner和onlyIssuerTransferAgent来自动化和分散遵从性。Owned的合约修饰符实例化函数的onlyOwner修饰符。IssuerControlled的修饰符实例化函数的onlyIssuerTransferAgent修饰符。

ERC-1450必须防止任何人执行transfer、allowance和approve功能和/或实现这些功能总是失败。ERC-1450更新transferFrom、mint和burnFrom函数。transferFrom、mint和burnFrom只能由RTA执行，且受onlyIssuerTransferAgent修饰符的限制。另外，ERC-1450定义了transferOwnership、setTransferAgent、setPhysicalAddressOfOperation, isTransferAgent等函数。只有发行者可以调用transferOwnership、setTransferAgent、setPhysicalAddressOfOperation函数。任何人都可以调用isTransferAgent函数。

1.8.3.1 发行方和RTA

出于遵从性的原因，ERC-1450构造函数必须指定发行者(所有者)、RTA (transferAgent)、安全性的名称和安全性的符号。

Issuer Owned

ERC-1450必须在其构造函数中指定所有者，应用Owned的修饰符，并实例化onlyOwner修饰符，以使特定函数只允许发行者的所有者地址执行它们。

ERC-1450还定义了transferOwnership函数，将发行者的所有权转移到新所有者的地址，只能由所有者调用。transferOwnership触发OwnershipTransferred事件。

Issuer Controlled

IssuerControlled通过拥有合约来维护发行者对其证券的所有权，并使发行者能够设置和更新发行者证券的RTA。ERC-1450的构造函数必须具有一个IssuerControlled的修饰符，其发行者在其ERC-1450构造函数中指定。IssuerControlled实例化ERC-1450的onlyIssuerTransferAgent修饰符，以使特定函数(setPhysicalAddressOfOperation和setTransferAgent)只允许发行方执行这些函数。

1.8.3.2 注册转移代理控制(Register Transfer Agent Controlled)

ERC-1450定义了setTransferAgent函数(用于更改RTA)和setPhysicalAddressOfOperation函数(用于更改发行者的地址)，并且必须使用onlyOwner修饰符将执行限制到发行者的所有者。setTransferAgent必须发出TransferAgentUpdated事件。setPhysicalAddressOfOperation必须发出PhysicalAddressOfOperationUpdated事件。

ERC-1450必须在其构造函数中指定transferAgent，并实例化onlyIssuerTransferAgent修饰符，以使特定的函数(transferFrom、mint和burnFrom)只允许发行者的transferAgent地址来执行它们。ERC-1450还定义了公共函数isTransferAgent来查找和标识发行者的RTA。

1.8.3.2 证券

ERC-1450通过应用onlyIssuerTransferAgent来更新transferFrom、mint和burnFrom功能，以支持证券的发行、再发行和交易。

1.8.3.3 证券交易委员会规定

SEC对允许执行特定操作的特定角色有非常严格的要求。具体地说，只有RTA可以铸造和转让证券。

实现者必须维护记录和跟踪投资者姓名、物理地址、Ethereum地址和安全所有权金额的链下服务和数据库。实施者和SEC必须能够根据需要访问投资者的私人信息。发行者和RTA必须能够生成所有投资者的当前列表，包括任何给定时刻的每个证券的名称、地址和证券所有权级别。发行人和RTA必须能够以各种监管理由向投资者重新发行证券。

私人投资者的信息绝对不能在公开的区块链上公开。

1.8.3.4 管理投资者信息

必须特别小心及注意，以确保投资者的个人身分资料不会外泄或向公众披露。

1.8.3.5 发行者失去对其地址或私钥的访问权

如果发行者无法访问其证券的现有实例的地址，则无追索权。发行者必须特别注意并努力保护和安全地存储其地址和相关的私钥。发行者可以将所有权重新分配给另一个发行者，但不能在发行者丢失其私钥的情况下。

如果发行者无法访问，发行者的证券必须使用链外服务重新构建。发行者必须创建(并保护)一个新地址。RTA可以读取现有的发行者证券，RTA可以根据新的ERC-1450智能合约相应地生成投资者证券。

1.8.3.6 RTA丢失地址或私钥

如果RTA失去访问权限，RTA可以创建一个新的Ethereum地址，而发行者可以执行setTransferAgent函数来重新分配RTA。

1.8.3.7 处理投资者(证券所有者)失去对其地址或私钥的访问权

投资者可能会因为一些原因“丢失”他们的凭证:他们只是“丢失”了他们的凭证，他们被黑客攻击或欺诈的受害者，他们遭遇了证券相关的欺诈，或者发生了生命事件(如死亡)。由于RTA管理发行人的证券，RTA可以授权证券的所有权相关变更(只要经过适当的公证和验证)。

如果投资者(或投资者的继承人)失去了他们的资格证书，投资者必须通过公证程序将情况通知RTA并提供新的投资者地址。从那里，RTA可以将“丢失的”证券铸币到新的投资者地址，然后从旧的投资者地址中烧毁(因为RTA知道所有投资者的地址)。

1.8.4 接口

/**
 * ERC-1450 is an ERC-20 compatible token that facilitates compliance with one or more of Securities Act Regulations CF, D and A. 
 *
 * Implementations of the ERC-1450 standard must define the following optional ERC-20
 *     fields:
 * 
 * name - The name of the security
 * symbol - The symbol of the security
 * 
 * Implementations of the ERC-1450 standard must specify the following constructor
 *   arguments:
 * 
 * _owner - the address of the owner
 * _transferAgent - the address of the transfer agent
 * _name - the name of the security
 * _symbol - the symbol of the security
 *  
 *  Implementations of the ERC-1450 standard must implement the following contract
 *      modifiers:
 * 
 * Owned - Only the address of the security’s issuer is permitted to execute the
 *     token’s constructor. This modifier also sets up the onlyOwner function modifier.
 * IssuerControlled - This modifier sets up the onlyIssuerTransferAgent function modifier.
 * 
 * Implementations of the ERC-1450 standard must implement the following function
 *      modifiers:
 * 
 * onlyOwner - Only the address of the security’s issuer is permitted to execute the
 *     functions transferOwnership, setTransferAgent, and setPhysicalAddressOfOperation.
 * onlyIssuerTransferAgent - Only the address of the issuer’s Registered Transfer
 *     Agent is permitted to execute the functions transferFrom, mint, and burnFrom.
 * 
 * Implementations of the ERC-1450 standard must implement the following required ERC-20
 *     event to always fail:
 * 
 * Approval - Should never be called as the functions that emit this event must be
 *     implemented to always fail. 
 * 
 * Implementations of the ERC-1450 standard must implement the following required
 *     ERC-20 functions to always fail:
 * 
 * transfer - Not a legal, regulated call for transferring securities because
 *     the token holder initiates the token transfer. The function must be implemented to
 *     always fail.
 * allowance - Not a legal, regulated call for transferring securities because
 *     the token holder may not allow third parties to initiate token transfers. The
 *     function must be implemented to always fail.
 * approve - Not a legal, regulated call for transferring securities because
 *     the token holder may not allow third parties to initiate token transfers. The
 *     function must be implemented to always fail.
 * 
 * Implementations of the ERC-1450 standard must implement the following optional
 *     ERC-20 function:
 * decimals - Must return '0' because securities are indivisible entities.
 * 
 * Implementations of the ERC-1450 standard must implement the following functions:
 * 
 * mint - Only the address of the issuer's Registered Transfer Agent may create new
 *     securities.
 * burnFrom - Only the address of the issuer’s Registered Transfer Agent may burn or 
 *     destroy securities.
 */

Contract ERC-1450 is Owned, IssuerControlled {

  /**
   * The constructor must implement a modifier (Owned) that creates the onlyOwner modifier
   * to allow only the address of the issuer (the owner) to execute the transferOwnership,
   * setTransferAgent, and setPhysicalAddressOfOperation functions. The construct must also
   * implement a modifier (TransferAgentControlled) that creates the onlyIssuerTransferAgent
   * modifier to allow only the address of the issuer’s Registered Transfer Agent to execute
   * the functions transferFrom, mint, and burnFrom).
   */
    constructor(address _owner, address _transferAgent, string _name, string _symbol)
          Owned(_issuer) TransferAgentControlled(_transferAgent) public;

    /**
     * Specify that only the owner (issuer) may execute a function.
     *
     * onlyOwner requires the msg.sender to be the owner’s address.
     */
    modifier onlyOwner();

    /**
     * Specify that only the issuer’s transferAgent may execute a function.
     *
     * onlyIssuerTransferAgent requires the msg.sender to be the transferAgent’s address.
     */
    modifier onlyIssuerTransferAgent();

    /**
     * Transfer ownership of a security from one issuer to another issuer.
     *
     * transferOwnership must implement the onlyOwner modifier to only allow the
     *     address of the issuer’s owner to transfer ownership.
     * transferOwnership requires the _newOwner address to be the address of the new
     *     issuer.
     */
    function transferOwnership(address _newOwner) public onlyOwner;

    /**
     * Triggered after transferOwnership is executed.
     */
    event OwnershipTransferred()

    /**
     * Sets the transfer agent for the security.
     *
     * setTransferAgent must implement the onlyOwner modifier to only allow the
     *     address of the issuer’s specify the security’s transfer agent.
     * setTransferAgent requires the _newTransferAgent address to be the address of the
     *     new transfer agent.
     */
    function setTransferAgent(address _newTransferAgent) public onlyOwner;

    /**
     * Triggered after setTransferAgent is executed.
     */
    event TransferAgentUpdated(address indexed previousTransferAgent, address indexed
        newTransferAgent);

    /**
     * Sets the issuers physical address of operation.
     *
     * setPhysicalAddressOfOperation must implement the onlyOwner modifier to only allow
     *     the address of the issuer’s owner to transfer ownership.
     * setPhysicalAddressOfOperation requires the _newPhysicalAddressOfOperation address
     *     to be the new address of the issuer.
     */
    function setPhysicalAddressOfOperation(string _newPhysicalAddressOfOperation) public
        onlyOwner;

    /**
     * Triggered after setPhysicalAddressOfOperation is executed.
     */
    event PhysicalAddressOfOperationUpdated(string previousPhysicalAddressOfOperation,
        string newPhysicalAddressOfOperation);

    /**
     * Look up the security’s transfer agent.
     *
     * isTransferAgent is a public function.
     * isTransferAgent requires the _lookup address to determine if that address
     *   is the security’s transfer agent.
     */
    function isTransferAgent(address _lookup) public view returns (bool);

    /**
     * transfer is not a legal, regulated call and must be implemented to always fail.
     */
    transfer(address to, uint tokens) public returns (bool success);

    /**
     * Approval does not have to be implemented. This event should never be triggered as
     * the functions that emit this even are not legal, regulated calls.
     */
    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);

    /**
     * allowance is not a legal, regulated call and must be implemented to always fail.
     */
    allowance(address tokenOwner, address spender) public constant returns (uint remaining);

    /**
     * approve is not a legal, regulated call and must be implemented to always fail.
     */
    approve(address spender, uint tokens) public returns (bool success);

    /**
     * Transfer securities.
     *
     * transferFrom must implement the onlyIssuerTransferAgent modifier to only allow the
     *     address of the issuer’s Registered Transfer Agent to transfer `ERC-1450`s.
     * transferFrom requires the _from address to have _value tokens.
     * transferFrom requires that the _to address must not be 0 because securities must
     *     not destroyed in this manner.
     */
    function transferFrom(address _from, address _to, uint256 _value) public
        onlyIssuerTransferAgent returns (bool);

    /**
     * Create new securities.
     *
     * mint must implement the onlyIssuerTransferAgent modifier to only allow the address
     *     of the issuer’s Registered Transfer Agent to mint `ERC-1450` tokens.
     * mint requires that the _to address must not be 0 because securities must
     *     not destroyed in this manner.
     * mint must add _value tokens to the _to address and increase the totalSupply by
     *     _value.
     * mint must emit the Transfer event.
     */
    function mint(address _to, uint256 _value) public onlyIssuerTransferAgent returns
        (bool);

    /**
     * Burn or destroy securities.
     *
     * burnFrom must implement the onlyIssuerTransferAgent modifier to only allow the
     *     address of the issuer’s Registered Transfer Agent to burn `ERC-1450`s.
     * burnFrom requires the _from address to have _value tokens.
     * burnFrom must subtract _value tokens from the _from address and decrease the
     *     totalSupply by _value.
     * burnFrom must emit the Transfer event.
     */
    function burnFrom(address _who, uint256 _value) public onlyIssuerTransferAgent returns
        (bool);
}

1.8.5 原理

目前还没有象征性的标准来促进对SEC法规的遵守。最接近的令牌是ERC-884(特拉华州公司法(DGCL)兼容的股票Token)，它指出SEC的要求超出了范围。EIP-1404(简单的限制Token标准)还不足以满足SEC关于向投资者重新发行证券的要求。

1.8.6 向后兼容性

ERC-1450通过以下规定与ERC-20 Token保持兼容性:

function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
必须实现为始终失败，因为allowance不是一种合法的、受监管的安全要求。
function transfer(address to, uint tokens) public returns (bool success);
当Token持有者发起转移，必须实现总是失败，因为转移不是合法的、受监管的安全调用。
function approve(address spender, uint tokens) public returns (bool success);
因为approve不是一种合法的、受监管的安全要求，就必须实现为总是失败的
function transferFrom(address from, address to, uint tokens) public returns (bool success);
必须实现为只有发行者的RTA才能执行此操作
event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
不需要实现。永远不应该调用Approval，因为发出此事件的函数必须实现为总是失败

1.8.7 实现示例

示例:

1.9 ERC-1462 基础ST标准(Base Security Token)

标题：基础ST标准
需要的其他标准: ERC-20、ERC-1066
状态: Draft
官方地址

1.9.1 概述

ERC-20标准Token的扩展，提供证券法规的遵从性和法律的可执行性。

1.9.2 摘要

这个EIP定义了默认Token标准(如ERC-20)的最小添加集，允许符合国内和国际法律要求。这些要求包括KYC(了解您的客户)和AML(反洗钱)法规，以及锁定帐户Token并由于法律纠纷限制其转账的能力。还可以附加额外的法律文档，以便在Token和链外法律实体之间建立双重绑定关系。

这个标准的范围被尽可能地缩小，以避免限制这个基本安全Token的潜在用例。本标准中未定义的任何附加功能和限制都可以在每个项目的基础上强制执行。

1.9.3 动机

最近提出了几种安全令牌标准。例如ERC-1400/ERC-1411和ERC-1450。我们对它们每一个都有关注，主要是因为每一个EIP的范围都包含许多特定于项目或特定于市场的细节。由于许多EIP来自于各自的支持公司，因此它们捕获了许多对于一般情况来说过多的小众需求。

例如，ERC-1411使用对ERC-1410的依赖，但它不属于“安全Token”范围。此外，它对ERC-777的依赖将在ERC-777最后定稿前很长一段时间内阻碍其采用，但该EIP中尚未描述现有ERC-20工作流的集成指南。另一种简化ERC-1404基本标准的尝试缺少了一些重要的方面，特别是它没有提供足够的粒度来区分不同的ERC-20转移函数(如transfer和transferFrom)。它也没有提供将合法文档绑定到已发行令牌的方法。

我们在EIP中提出的是一个简单且非常模块化的解决方案，用于为尽可能广泛的应用程序创建一个基本的安全令牌，以便其他发行方可以使用它进行构建。发行者应该能够使用下面建议的功能和实现向Token添加更多的限制和策略，但是在使用这个ERC时，它们不能以任何方式受到限制。

1.9.4 说明

ERC20特性如下：

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);
}

该标准将扩展ERC-20的特性如下：

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);
}

转移检查功能

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

根据ERC-1066，每个函数必须从Ethereum状态代码公共集(ESC)返回一个状态代码。这些代码的本地化不在本建议的范围内，可以通过在应用层上采用ERC-1444选择性地解决。如果检查函数允许该操作，则返回的状态代码必须是0x11 (allowed)，或者是具有等效但更精确含义的特定于问题的代码。如果检查函数不允许该操作，则状态必须是0x10(不允许)，或者是具有等效但更精确含义的特定于问题的代码。在出现内部错误时，函数必须从通用代码表或特定于问题的等效程序返回最相关的代码，例如:0xF0(脱链故障)。

对于ERC-20基础Token

必须用检查相应的checkTransferAllowed返回状态代码的逻辑覆盖转移函数。
必须用检查相应的checkTransferFromAllowed返回状态代码的逻辑覆盖transferFrom函数。
必须用检查相应的checkTransferFromAllowed返回状态代码的逻辑覆盖approve函数。
必须覆盖mint和burn等其他函数，如果它们存在于Token实现中，则应该相应地检查checkMintAllowed和checkBurnAllowed状态代码。

对于ERC-777基础Token

要求send函数必须用检查相应返回状态码的逻辑覆盖:
如果是代表Token所有者进行的，则checkTransferAllowed返回状态码;
如果转移是代表一个操作者进行的(即委托转移)，checkTransferFromAllowed返回状态代码。
必须用检查相应的checkBurnAllowed返回状态代码的逻辑覆盖burn函数。
如果令牌实现中存在其他功能，例如mint，则必须重写这些功能，例如安全Token是可铸造的。mint函数必须调用checkMintAllowed并检查它返回的状态码。

对于两种情况，

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

在checker函数中，逻辑允许使用链上可用的任何特性:使用白名单/黑名单执行对注册表合约的调用，使用在同一合约上定义的内置检查逻辑，甚至通过oracle运行链外查询。

文档功能

我们还介绍了两个应该用于文档管理的新功能。函数attachDocument添加指向链外文档的引用，该文档具有指定的名称、URI和内容hash。在这个标准中没有指定哈希算法，但是产生的哈希长度不能超过32字节。函数lookupDocument通过其名称获取引用的文档。

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

1.9.5 原理

这个EIP的目标是基于ERC-20和基于ERC-777的Token，尽管由于ERC-20被广泛采用，所以它的重点是ERC-20。然而，这个扩展也被设计成与即将发布的ERC-777标准兼容。

所有检查函数都使用前缀check来命名，因为它们返回的是检查状态代码，而不是布尔值，因为这对于调试和跟踪过程非常重要。发行者有责任实现适当处理返回代码的逻辑。有些处理程序只会抛出错误，而其他处理程序则会记录信息，以便将来进行流程挖掘。在ERC-1066中可以看到状态码的更多原理。

我们需要两个不同的转移验证函数:checkTransferAllowed和checkTransferFromAllowed，因为相应的transfer和transferFrom通常在不同的上下文中调用。一些Token标准(如ERC-1450)明确禁止使用transfer，而只允许使用transferFrom。也可能有不同的复杂情况，在这种情况下，应该区别对待transfer和transferFrom。ERC-777依赖于自己的send来转移Token，因此根据调用上下文在检查器函数之间切换是合理的。我们决定忽略checkApprove函数，因为它将在与checkTransferFromAllowed完全相同的上下文中使用。在许多情况下，它不仅需要规范证券转让，而且还需要限制烧钱和造币厂操作，并为此增加了额外的检查功能。

我们提出文档的功能是创建双重绑定和链下法律文档的必备工具,一个很好的例子是Neufund’s Employee Incentive Options Plan法律框架,实现了完整的法律强制性:智能合约印刷ESOP条款和条件文档,这本身就是智能合同。即使在没有法律要求引用安全Token中的文档的情况下，这也正在成为一种广泛采用的做法。但是它们几乎总是必需的，这是附加各种类型的有用文档的好方法。

1.9.6 实现示例