证券类通证标准设计的对比   

证券类通证标准设计的对比    

证券类通证标准设计概要

  随着对区块链生态及数字货币市场的监管越发严格,ICO 的狂野时代已经成为了过去时,数字货币的发行很可能受证券法的监管。在这一背景下,为了让企业能通过区块链向投资者提供符合法规监管的金融产品,而又不违反证券法,证券类通证发行(STO)解决方案应运而生。

  与应用类通证(Utility Token)不同的是,证券类通证(Security Token)表示对资产的部分或完全所有权,公司、房地产甚至知识产权的股票,都可以用证券类通证来表示。证券类通证的好处,不仅适用于区块链融资,它还有可能改变传统的纸股范式,从而提高效率以及改善分配。例如,智能合约的很多应用,可以和证券类通证一起使用,以优化公司治理中的投票表决, 提高其透明度。

  然而,如果没有标准,监管机构、开发者、KYC 供应商、投资者、发行商、钱包以及交易所, 就无法在同一个框架中协同工作。目前,市场上已出现了多种 STO 标准尝试:其中有来自

  Polymath 团队的 ST-20,Harbor 团队的R-Token,还有来自社区的提案——ERC1400/ERC1410及 ERC1404 标准等。

 基本情况

  代号标准名称作者阶段创建时间

  ST-20ST-20 StandardPolymath 团队——

  R-

  TokenRegulated Token Standard

  Harbor 团队

  —

  —

  ERC- 1404Simple Restricted Token StandardRon Gierlach, James Poole, Mason Borda, Lawson Baker

  Draft2018-

  07-27

  ERC- 1400Security Token StandardAdam Dossa, Pablo Ruiz, Fabian Vogelsteller, Stephane Gosselin

  Draft2018-

  09-09

  标准的主要内容与差异

  我们从 ST-20,R-Token,ERC1404,ERC1400 标准内容切入,结合业务场景研究设计的目的, 再比较各个标准之间的差异,思索在证券化通证形式标准化的过程中,所面临的难题及取舍。

通证性质

  这几个标准在通证性质上,ERC-1400 与其他三个的差异最大。我们先了解下 FungibleToken 的概念。

  ◼Fungible Token 和 Non-fungible Token

  Fungible Token 称为同质化通证,也可以叫做可互换通证,典型的如同 ERC-20 标准的通证,token 不存在附加的解释,每个单位相同token 价值完全相同,token 持有者可以随意交换,拆分整合。而ERC-721 标准的通证,每个单位的 token 均有不同的 ID,不同 ID 可以有不同的解释,设计上认为每个token 都是不同的,不能随意按单位进行交换,这就是Non-fungible Token(非同质化通证/不可互换通证)。

  ◼ERC-1410 标准与 tranche

  ERC-1400 标准依赖于 ERC-1410 标准,在设计上,将 token 的余额通过一个叫做tranche 的属性,划分成不同的部分。可以对 tranche 做出不同解释,操作上进行不同的限制(例如:某些操作只限指定的 tranche,某些操作优先消耗指定 tranche 下的 token),这有些 Non-fungible Token 的概念,但也存在不同:tranche 相同的token 价值相同,是可以随意置换的。结合了 Fungible Token 和Non-fungible Token 两者, 故称为 Partially-Fungible Token(部分可互换通证)。

  ◼ 分类与场景

  ST-20,R-Token,ERC-1404 都是直接依赖于 ERC-20 标准的,很明显,这三个都属于 Fungible Token。ERC-1400 依赖于 ERC-1410,故属于 Partially-Fungible Token。实际应用场景中,同一家企业发行的证券可能是存在差异的,如限售股/非限售股, 优先股/普通股,原始股/增发股,这些不同性质的证券在分红,票权,流通性上不尽相同,其性质也可能在某个阶段发生转变,不同性质的证券在投资人眼里的价值可能是不同的。

  ERC-1404,ST-20,R-Token 这类同质化通证,要在合约层面体现出证券性质上的差异,只能依据地址进行限制,设置维护各种规则名单(比如:KYC/AML 名单,出入账限制名单,冻结名单,最小保留额等)来做限制。这种设计存在局限性:单一地址在同一时刻无法持有多种性质不同的通证。如果要在合约层面适用于上述复杂的业务,可以通过多个合约管理不同性质的通证,这在完整性上大打折扣,开发的复杂度也会加大。

  再看看 ERC-1400,在合约内部就将持有的 token 划分成不同的 tranche,这样不仅能对地址做限制,还能对 tranche 做限制,诸如配股增发,投票表决,分红除息等复杂功能都可以通过在合约层定义tranche 来实现差异化和差异转变。ERC-1400 的设计也使得开发者,交易所接入的难度加大,所以,根据实际的业务场景选择适合的证券类通证标准才是最佳做法。

  接口设计

  考虑到证券相关的业务场景,证券类通证的合约标准做了对提供转账限制的定义,在执行转账前先进行限制判断,并提供对转账限制判断结果的可读解释,从而在合约层面实现诸如锁仓,KYC/AML 验证,出入账冻结等功能。

  ◼ 转账限制的判断函数

  在这几个证券类通证标准中都声明了一个函数,实现对转账限制的判断逻辑,返回结果的布尔值或是状态码。在执行转账操作时需要先调用判断函数,判断通过则继续执行,失败则返回相应状态码,取消转账,它允许函数的调用者知道转账失败的原因并将其报告给相关方。

  /* ST-20 */

  function verifyTransfer(address _from, address _to, uint256 _amount) public view returns (bool success);

  /* R-Token */

  function check(address _token, address _spender, address _from, address _to, uint256 _amount) public returns (uint8);

  /* ERC-1404 */

  function detectTransferRestriction (address from, address to, uint256 value) public view returns (uint8);

  /* ERC-1400 */

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

  ◼判断结果的解释函数

  用于对转账限制的判断函数返回的状态码做出可读的解释,通过标准化的信息,使相关应用的开发者能有效地向用户报错。

  /* ST-20 标准的设计中,转账限制的判断函数仅返回布尔值,故缺失对状态码的解释函数 */

  /* R-Token */

  function messageForReason(uint8 _reason) public view returns (string);

  /* ERC-1404 */

  function messageForTransferRestriction (uint8 restrictionCode) public view returns (string);

  /* ERC-1400,判断函数 canSend 返回一个遵循ERC-1066 标准的 ESC (Ethereum Status Code, 以太坊状态码),

  还有一个可以用于定义程序指定原因码及额外详细信息(例如,执行发送操作的转账限制无效)的 bytes32 参数。

  所以ERC-1400 还依赖于ERC-1066 标准 */

  ◼ 转账函数

ERC-1404,ST-20,R-Token 继承自 ERC-20,所以转账函数与 ERC-20 中相同—— 和 transferFrom, 实现上进行重写即可(加入对转账限制的判断函数的调用)。

  实现示例:

  /* implement in the instance of R-Token */

  function transfer(address _to, uint256 _value) public returns (bool) { if (_check(msg.sender, _to, _value)) {

  return super.transfer(_to, _value);

  } else {

  return false;

  }

  }

  function transferFrom(address _from, address _to, uint256 _value) public returns (bool) { if (_check(_from, _to, _value)) {

  return super.transferFrom(_from, _to, _value);

  } else {

  return false;

  }

  }

  /* implement in the instance of ERC-1404 */

  modifier notRestricted (address from, address to, uint256 value) {

  uint8 restrictionCode = detectTransferRestriction(from, to, value);

  require(restrictionCode == SUCCESS_CODE, messageForTransferRestriction(restrictionCode));

  _;

  }

  function transfer (address to, uint256 value) public

  notRestricted(msg.sender, to, value) returns (bool success)

  {

  success = super.transfer(to, value);

  }

  function transferFrom (address from, address to, uint256 value) public

  notRestricted(from, to, value) returns (bool success)

  {

  success = super.transferFrom(from, to, value);

  }

  对于ERC-1400 而言,因为有 tranche 的存在,不光是转账,整个合约的接口设计上要做出大的改变。这里只示例 对应的函数定义:

  // 定义在ERC-1410 标准中

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

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

  兼容性

  因为ERC-20 标准在行业里最为通用,这里的兼容性我们主要考虑各个证券类通证标准

  对 ERC-20 的向后兼容.

  RC-1404,ST-20,R-Token 在接口设计上派生于 ERC-20,其合约本身就要对 ERC-20 标

  

准具有的 和 函数进行重写,可以说是向后完全兼容 ERC-20。而ERC-1400 会更麻烦一些,ERC1400 继承自 ERC777 标准,其中的定义的转账函数并不是 ERC-20 标准中的 和 transferFrom,如果要向后兼容 ERC-20 所以必须要额外


  实现ERC-20 标准中具有的函数,且来自两个标准的状态变更函数在实现上最好进行解耦,彼此独立地操作。此外,相应 event 也要做变动。兼容 ERC-20 标准后,便可快速接入交易所,钱包等应用。

  其他差异

  ERC-1404,ST-20,R-Token 在设计上大体相同,唯一明显不同的是 R-Token 将转账限制的判断函数和判断结果的解释函数放在了 合约中,便于升级版本,同时使用合约作为注册器,保存当前最新版本的地址。

  主体合先要访问注册器合约 拿到的地址,再调用最新版本的 中的转账限制的判断函数。整个过程

  ERC-1400 除了因 tranche 的引入而在接口设计上与另外三种标准明显不同之外,因其设计思路上主张尽量在合约层对证券相关的业务提供支持,比如 ERC-1400 考虑到实际的证券流通需要链上和链外的参与者之间更复杂的交互,因此该标准要具有能力进行强制转移,用于法律诉讼,资金追回等。

总结

  文章提到的四个证券化通证标准中,ST-20 和R-Token 分别是 Polymath 和 Harbor 自行设计,主要依靠自身进行推广。如果能打造出证券通证化的成功案例,势必会获得认可。ERC-1404 和 ERC-1400 则是通过 EIP 提议,广泛采纳社区意见,共同制定标准。但目前都处于 Draft 阶段。一项提案从起草提议,到进入最终调用(Last Call)阶段,通常需要经历很长的开发、编辑、实现以及漏洞修复周期。这些提案可能只是证券通证化之路的一个开始,随着行业各方陆续参与,一定出现更多的的标准。

玖壹区块链声明

加微信:469649885区块链培训教程
还可免费获取区块链培训班试学名额

分享:

扫一扫在手机阅读、分享本文

区块链评论

玖壹区块链培训

玖壹区块链培训学院简称(玖壹学院http://www.91xiubbs.com/)提供区块链技术培训资料、区块链开发培训视频教程等下载,不过网上自学区块链技术课程必然存在一些缺陷:遇到问题易卡壳、学习周期漫长、无针对性等。区块链培训机构现场面对面的讲授区块链培训课程可以让您和团队在最短时间内掌握正确、系统、高效的区块链实战技术。