Standards Track: ERC

ERC-3643: T-REX - 受监管交易所的代币

一种机构级证券型代币合约，它提供了用于管理和合规转移证券型代币的接口。

Authors	Joachim Lebrun (@Joachim-Lebrun), Tony Malghem (@TonyMalghem), Kevin Thizy (@Nakasar), Luc Falempin (@lfalempin), Adam Boudjemaa (@Aboudjem)
Created	2021-07-09
Requires	EIP-20, EIP-173

摘要

T-REX 代币是一种机构级证券型代币标准。该标准提供了一系列接口，用于管理和合规转移证券型代币，使用自动化的链上验证器系统，利用链上身份进行资格检查。

该标准定义了以下几个接口：

Token
Identity Registry (身份注册表)
Identity Registry Storage (身份注册表存储)
Compliance (合规性)
Trusted Issuers Registry (可信发行者注册表)
Claim Topics Registry (声明主题注册表)

动机

区块链技术的出现为资产转移带来了效率、可访问性和流动性的新时代。这在加密货币领域尤为明显，用户可以点对点地转移代币所有权，而无需中介。然而，当涉及到代币化证券或证券型代币时，由于需要遵守证券法，情况就更加复杂。这些代币不能像实用型代币那样无需许可；它们必须经过许可才能追踪所有权并确保只有符合条件的投资者才能持有代币。

现有的以太坊协议虽然强大而通用，但并未完全解决证券型代币带来的独特挑战。需要一种标准来支持许可型代币的合规发行和管理，适用于代表各种资产类别，包括小型企业和房地产。

拟议的 ERC-3643 标准正是基于这种需求。它旨在为管理证券型代币的生命周期提供一个全面的框架，从发行到符合条件的投资者之间的转移，同时在每个阶段执行合规规则。该标准还支持额外的功能，如代币暂停和冻结，这些功能可用于管理代币，以应对监管要求或代币或其持有者状态的变化。

此外，该标准旨在与链上身份系统结合使用，允许通过受信任的声明发行者发布的签名证明来验证投资者的身份和凭证。这确保了符合证券型代币交易的法律和监管要求。

总而言之，拟议标准背后的动机是将区块链技术的好处带到证券领域，同时确保遵守现有的证券法。它旨在为证券型代币的发行和管理提供一个稳健、灵活和高效的框架，从而加速资本市场的演进。

规范

拟议的标准具有以下要求：

必须与 ERC-20 兼容。
必须与链上身份系统结合使用
必须能够应用监管机构或代币发行者要求的任何合规规则（关于身份的资格因素或关于代币本身的规则）
必须具有一个标准接口，用于在发送到区块链之前预先检查转移是否会通过或失败
必须具有一个恢复系统，以防止投资者失去对其私钥的访问权限
必须能够根据需要部分或全部冻结投资者钱包中的代币
必须能够暂停代币
必须能够铸造和销毁代币
必须定义代理角色和所有者（代币发行者）角色
必须能够强制从代理钱包进行转移
必须能够批量发布交易（以节省 gas 并使所有交易在同一区块中执行）

虽然此标准向后兼容 ERC-20，并且可以在 ERC-3643 代币上调用所有 ERC-20 函数，但由于 ERC-3643 的许可性质，这些函数的实现方式有所不同。此标准下的每个代币转移都涉及合规性检查，以验证转移以及利益相关者身份的资格。

代理角色接口

该标准定义了一个代理角色，这对于管理对智能合约各种功能的访问至关重要。代理角色的接口如下：

interface IAgentRole {

  // events
  event AgentAdded(address indexed _agent);
  event AgentRemoved(address indexed _agent);
  
  // functions
  // setters
  function addAgent(address _agent) external;
  function removeAgent(address _agent) external;

  // getters
  function isAgent(address _agent) external view returns (bool);
}

IAgentRole 接口允许添加和删除代理，以及检查地址是否为代理。在此标准中，由 ERC-173 定义的所有者角色负责任命和删除代理。在本标准上下文中，任何履行 Token 合约或 Identity Registry 角色的合约都必须与 IAgentRole 接口兼容。

主要功能

####转移

要在 T-REX 上执行转移，您需要满足以下几个条件：

发送者必须持有足够的可用余额（总余额 - 冻结的代币，如果有）
接收者必须在 Identity Registry 上列入白名单并经过验证（持有其链上身份的必要声明）
发送者的钱包不得被冻结
接收者的钱包不得被冻结
代币不得被暂停
转移必须遵守 Compliance 智能合约中定义的所有合规规则（canTransfer 需要返回 TRUE）

以下是 transfer 函数实现的一个示例：

function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) {
        require(!_frozen[_to] && !_frozen[msg.sender], "ERC-3643: Frozen wallet");
        require(_amount <= balanceOf(msg.sender) - (_frozenTokens[msg.sender]), "ERC-3643: Insufficient Balance");
        require( _tokenIdentityRegistry.isVerified(to), "ERC-3643: Invalid identity" ); 
        require( _tokenCompliance.canTransfer(from, to, amount), "ERC-3643: Compliance failure" );
        _transfer(msg.sender, _to, _amount);
        _tokenCompliance.transferred(msg.sender, _to, _amount);
        return true;
    }

transferFrom 函数的工作方式相同，而 mint 函数和 forcedTransfer 函数仅要求接收者在 Identity Registry 上列入白名单并经过验证（它们绕过合规规则）。 burn 函数绕过所有资格检查。

isVerified

isVerified 函数是从 transfer 函数 transfer、transferFrom、mint 和 forcedTransfer 中调用的，用于指示 Identity Registry 检查接收者是否是有效的投资者，即他的钱包地址是否在代币的 Identity Registry 中，以及链接到他的钱包的 Identity 合约是否包含 Claim Topics Registry 中需要的声明（请参阅 Claim Holder），以及这些声明是否由 Trusted Issuers Registry 中要求的授权 Claim Issuer 签名。如果满足所有要求，isVerified 函数将返回 TRUE，否则将返回 FALSE。可以在 Tokeny 的 T-REX 存储库中找到此函数的实现。

canTransfer

canTransfer 函数也是从 transfer 函数中调用的。此函数检查 transfer 是否符合应用于代币的全局合规规则，与仅检查投资者持有和接收代币资格的 isVerified 相对，canTransfer 函数着眼于全局合规规则，例如，检查 transfer 是否符合有固定的最大代币持有者数量需要遵守的情况（每个国家/地区的持有者数量也可能有限），检查转移是否遵守设置每个投资者最大代币数量的规则，… 如果满足所有要求，canTransfer 函数将返回 TRUE，否则将返回 FALSE，并且不允许进行转移。可以在 Tokeny 的 T-REX 存储库中找到此函数的实现。

其他功能

有关 ERC-3643 的其他功能的描述可以在 interfaces 文件夹中找到。可以在 Tokeny 的 T-REX 存储库中找到 ERC-3643 智能合约套件的实现。

Token 接口

ERC-3643 许可型代币建立在标准 ERC-20 结构之上，但具有额外的功能以确保证券型代币交易的合规性。函数 transfer 和 transferFrom 以条件方式实现，仅当交易有效时才允许它们继续转移。许可型代币仅允许转移到经过验证的交易对手方，以避免代币被持有在不合格/未经授权的投资者的钱包/Identity 合约中。 ERC-3643 标准还支持在投资者失去对其钱包私钥的访问权限时恢复证券型代币。出于透明原因，区块链上维护了已恢复代币的历史记录。

ERC-3643 代币实现了一系列附加功能，使所有者或其指定的代理能够管理供应、转移规则、锁定以及证券管理中的任何其他要求。该标准依赖于 ERC-173 来定义合约所有权，所有者负责指定代理。在本标准上下文中，任何履行 Token 合约角色的合约都必须与 IAgentRole 接口兼容。