【EIP/ERC Vol.5】〜EthereumにおけるCompliance規格について〜
2018年に入りSecurity Tokenへの注目が増したことでBlockchainにおけるComplianceの議論が活発に行われるようになりました。一概にTokenと言ってもその性質はそれぞれ異なり、サービス内での利用価値に限定されたTokenをUtility Token、証券としての価値を持つTokenをSecurity Tokenといった２つに分類することができます。こうしたTokenの分類は2018年3月にアメリカ証券取引委員会（SEC）によるCrypto市場への規制に関する声明が出されたことがはじまりといえます。（この声明は証券に該当するTokenを扱う取引所はSECへ登録が必要となる主旨の声明で、こうした規制の対象となるTokenをSecurity Tokenと分類されるようになりました）この声明以降、Security Tokenに特化したマーケットプレイスが次々と立ち上がり、株式・不動産・絵画・ワインと言ったこれまでCrypto市場で扱われてこなかった分野のToken化が加速するきっかけとなりました。こうした新たな市場の確立とあわせて既存のEIP/ERCではカバーしきれないSecurity TokenならではのCompliance（Token発行者・購入のKYC/AML/CFTなどのidentity管理から、ロックアップ期間/投資家の数などの証券性の担保するToken設計に至るまで）に関する提案が現在活発に行われています。
目次
- Security TokenにおけるCompliance
- ERC1400/ERC1411
ERC1410、ERC1594、ERC-1643、ERC-1644 - ERC20拡張規格
Polymathによる「ST-20」
Harborによる「R-token」
Securitizeによる「DS protocol」 - Security Tokenの事例
Security TokenにおけるCompliance
Security Tokenは証券としての性質上、これまでの株式・債券・手形といった有価証券と同等の規制が適用されると米国証券取引委員会（SEC）から声明がありました。これによりアメリカでは取引所を始め発行体に対して事前の届け出と厳しいコンプライアンス要件が求められることとなり、購入希望者へはKYC確認と投資資格の有無といった事前の審査が求められることとなりました。また、Token化することでボーダレスなPtoP取引を可能とするSecurity Tokenに対する諸外国の規制の動きも強まりはじめ、シンガポールの金融機関であるシンガポール金融管理局（MAS)からもSEC同様の声明が出されました。
アメリカの声明：
米国証券取引委員会（SEC）への登録届出を行い、証券発行に関わるあらゆる情報の提供と厳しいCompliance要件（KYC確認・AML対策・中央監視体制・プライバシー保護）を満たす必要があります。
シンガポールの声明：
シンガポール金融管理局（MAS)の許認可が必要となり、発行体は目論見書の提出とMASが定めるCompliance要件を満たす必要があります。
これは同時に発行体・保有者審査だけでなく、Security Tokenそのものにも様々な仕様が求められ、現在ERC上では下記実装について様々な議論が交わされています。
- 発行枚数管理：全体発行数・追加発行数・個別保有数
- ドキュメント：目論見書の添付/更新
- 取引制限：居住制限・ロックアップ期間・保有上限・送信上限
- 保有者確認：ブラックリスト/ホワイトリスト管理
- センターコントロール：発行体によ不正取引の取消・Token転送
本稿ではERC規格の中でも特に注目度の高いERC1400/EIP1411とその関連規格を中心に見ていきたいと思います。
【主要規格】
- ERC1400：https://github.com/ethereum/EIPs/issues/1400
- EIP1410：https://github.com/ethereum/EIPs/issues/1410
- EIP1411：https://github.com/ethereum/EIPs/issues/1411
- EIP1446：https://github.com/ethereum/EIPs/pull/1462
- EIP1594：https://github.com/ethereum/EIPs/issues/1594
- EIP1643：https://github.com/ethereum/EIPs/issues/1643
- EIP1644：https://github.com/ethereum/EIPs/issues/1644
【主要プロジェクト】
- Polymath：https://polymath.network/
- Harbor：https://harbor.com/
- Securitize：https://www.securitize.io/
- Swarm Fund：https://swarm.fund/ja/
- tZERO：https://www.tzero.com/
- OpenFinance Network：https://openfinance.io/
ERC1400/EIP1411
PolymathのエンジニアであるStephane Gosselin、Pablo Ruiz、Adam Dossa、ERC20の提案者であるFabian Vogelstellerによって、Security TokenのComplianceに関する規格を定義したERC1400が提案されました。Security Tokenのプラットフォームを開発しているPolymathは、元々ERC20を拡張するカタチでST20（詳細は後述）をSecurity Tokenの独自の規格として開発していましたが、Security Token規格の標準化を求めてERC1400の提案を行ったものと思われます。
現在は、ERC1400からissueを変えてEIP1411で議論が行われています。Security Tokenの文書管理、エラー通知、オペレーターアクセス制限、発行/償還管理、Token保有者残高の管理など、Security Tokenに必要な機能に関しては、ERC1410、ERC1594、ERC-1643、ERC-1644といった個別の規格が定義されており、EIP1411ではこれらの機能を統合したSecurity Tokenの全体像が定義されています。
ERC1410：メタデータの識別について
- チェーン内またはチェーン外のメタデータと関連付けTokenを管理
※メタデータ：送信元・送信先の情報、ロックアップタイムスタンプ、転送されたTokneの量
ERC1594：Tokenの転送制限について
- 譲渡されるTokenのメタデータ（ロックアップ期間の対象かどうか）
- Tokenの送信者および受信者の身元（KYCプロセスを経たかどうか）
- Token規約で定めた保有制限（投資家毎のToken保有数の上限）
※転送エラー時の理由を明確にする為、多様なエラー結果を用意するよう定めています。
ERC-1643：文書管理について
- Tokenに関するドキュメントの設定/削除および検索（提供文書・凡例詳細など）
ERC-1644：Tokenコントロールについて
- 発行者によってToken転送のコントール（不正取引の取り消し、秘密鍵の紛失時の解決、裁判所の命令に応じるなど）
これらの規格に準ずることでSecurity Tokenとしての妥当性がTokenそのものに担保することができます。そして規格内ではSecurity Token開発にあたっての留意点が示されています。
留意点：
- Tokenの譲渡が成功または失敗した場合、その理由を処理要求するインターフェースとならければなりません。
- 法的措置や資金回収のために強制的にToken譲渡することができなければなりません。
- 発行と償還のための標準的なイベントを備えなければなりません。
- 特別な株主権限やTokenの譲渡制限のあるデータなどを、Token所有者の残高にメタデータを添付できなければなりません。
- オフチェーンデータ、オンチェーンデータ、およびToken譲渡時のパラメータに応じてメタデータを変更できなければなりません。
- 署名されたデータをチェーン上で検証するために転送トランザクションに渡す必要があるかもしれません。
- 代理可能な管轄区域にわたる資産クラスの範囲を制限すべきではありません。
- ERC20とERC777との互換性があります。
※詳細については下記をリンクを参照ください。
ERC20拡張規格
各Security TokenプラットフォームからERC20の拡張規格での解決策として下記取り組みが発表されています。
Polymathによる「ST-20」
ERC20の拡張により下記内容を可能とする規格です。
- 送信者/受信者のホワイトリスト化
- 一定額を超える、または下回る送金の制限
- 送信先の転送制限
- 特定アドレスのブラックリスト化
Harborによる「R-token」
Regulator Serviceという機能を用いてTokenを受ける資格のある投資家のブロックチェーンアドレスのリストを保持し、リストに載っていない人へのToken転送を防ぐ仕様です。また、投資家リストのアップグレードが可能です。
Securitizeによる「DS protocol」
サービスプロバイダーがこのDS protocolを用いることで簡単にSecurity Tokenのシステムを導入することができるprotocolです。
Security Tokenの事例
Haborの上で最初のSecurity TokenがリリースしたというTopicがありました。これはThe Hub at ColumbiaというSouth Carolina大学の学生向けのプール付き高層ビルがREIT Tokenとして販売されるという内容です。参加者は小口化された不動産をTokenとして保有することができるといったSecurity Tokenの事例になります。
ここまで、EIP/ERCをカテゴリ毎に主要規格とプロジェクトをあげて解説をしてきました。次稿から新たなシリーズとしてBlockchainにおけるUXについて、事例を交えながら理解を深めていきたいと思います。
Reference
- https://medium.com/r/?url=https%3A%2F%2Fgithub.com%2Fethereum%2FEIPs%2Fissues%2F1411
- https://blog.polymath.network/overview-of-the-st-20-interface-and-polymath-core-86bf64c8929
- https://medium.com/securitize/introducing-ds-digital-securities-protocol-securitizes-digital-ownership-architecture-for-4bcb6a9c4a16
