プッシュ通知

この記事はCoffeeさんに寄稿していただいたものです

URL:https://harbor.com/

Whitepaper:https://harbor.com/rtokenwhitepaper.pdf

概要

証券トークンを発行するプロジェクトです。最初の取り組みとしては、「R-Token」という規格を作ることで、ERC20トークンが、証券の法律に準拠できるようになることを目指します。具体的には、Regulator Serviveというコントラクトに書かれた情報をトークンの交換時に自動的にチェックすることを可能にし、交換を実行もしくは取消をします。

同コントラクト上では、KYC/AML, 税法, 適格機関投資家ステータスなどの情報を満たしているかを確認します。

 

仕組みとトークンモデル

Polymathと異なり、ネイティブトークンは現在存在しません。R-Token(Regulated Token)という新しい規格を作っています。

情報はありませんが、R-Tokenの最初の実装例としてHarbor自身が株式の代わりにトークン化するということが推測されます。ちょうどBancorが自らの技術を実装したスマートトークンをBNTとして作ったのと同じようなことです。

 

それではR-Tokenの仕組みを説明していきます。

大きく分けてこの規格は3つの構成があるため分けて説明をしますが、実際には1つのスマートコントラクトの予定です。

 

  1. R-Token
  2. Regulator Service
  3. Service Registry

1.R-Tokenについて

Harborが開発する規格で作られるトークンはR-Tokenと呼ばれ、ERC20の拡張版(許可を受けたバージョン)と言うことができます。ERC20と互換性を持つため、ERC20を扱う取引所などで扱うことができます。ERC20と異なる点は、送信を行う前に、送っても良い相手かどうかを確認する機能が発動する点です。

 

下の図で説明をします。例えばBobがAliceに対して、20トークンを送りたいとします。するとR-Tokenは自ら、「Regulator Service」という領域へ、情報を確認しにいきます。

その後Regulator Serviceはコードを返し、交換しても問題がない相手であれば、送信が実行されます。

図1. R-Tokenの送信時の挙動

2.Regulator Service

既に上で登場しましたが、ここが情報参照先となります。したがってホワイトリストを持っている必要があります。

KYC(Know Your Customer)・AML(Anti Money Loundering)や税法の情報などがこちらに追加されることになります。

この領域には以下2つの設定がされます。

 

  1. 2つの参加者パーミッション設定
  2. 2つのトークン設定

a)

参加者の送信できるアドレスと、受信できるアドレスが定義されます。これを分けることにより、例えば「証券トークンを受け取る資格がありR-Tokenを受け取ったが、その後に資格を剥奪されてしまった。受信はできないが、持っているR-Tokenを送信することはできる。」などのような柔軟な設定が可能となります。

 

またこのような情報は、オフチェーンにて、KYC/AMLの情報を見て、第三者が書き込むことになります。この役割を「Trade Controller」と名付けていますが、最初はHarbor自身が最初のTrade Controllerとしてホワイトリストに情報を書いていくようです。

 

※ここにおいては、Harbor(Trade Controller)を信頼しないといけないという課題は残ることになります。したがって、分散的にこの役割が実施されるよう実装を計画しているとしています。

 

b)

トークンに2つ設定を行うことができます。1つはロック・アンロックの設定です。これはトークンを移動できるようになるまでの期間を定めることができます。

例えば、Regulation Dという規制においては1年のロック期間が必要となっており、それをトークンに設定することが可能となります。

 

トークン設定のもう1つは、トークン分割をするかしないかという設定です。(例えば1トークンを0.5トークン×2つに分割できるよう許可するかということです。)

 

ここの設定に関しては、第三者ではなく、トークン発行主体が設定することになります。このときHarborがインターフェースを提供する予定となっています。

 

3.Service Registry

上記について、R-Tokenは、Regulator Serviceにかかれているホワイトリスト情報を確認しにいくと説明しましたが、どこのRegulator Serviceを見にいけばよいか場所を示すのが、このService Registryです。

以下の図のようになります。

図2. Service Registryの挙動

 

この役割がいることで、例えば新しいバージョンのRegulator Serviceに更新されたとき、そのアドレスを指すようにすることも可能になります。

図3. Service Registryの挙動 Regulator Service更新時

 

このService Registryが間違ったホワイトリストを案内してしまっては意味をなさないため、複数作成し分散化されるように、開発者向けにインターフェースが提供される予定となっています。

 

チームメンバー/資金調達状況

 

SECに提出されたファイルによると、Polymathは$28.2milionを調達しました

Andreessen Horowitz, Pantera Capitalなどから。

その後2018年2月のシリーズAで$10milion追加調達をし、合計約40億円ほど集めたことになります。

 

チームメンバー

  • Bob Remeika, Co-Founder and Chief Technology Officer
  • Arisa Amano, Co-Founder and Chief Product Officer
  • Ryan Hall, Engineering
  • Jamie Liu, Engineering
  • John Setzer, Engineering
  • Shane Wolf, Engineering
  • Bonnie Shu, Product Compliance
  • Akiko Ito, Design
  • Kevin Young, Marketing/Communications

 

投資家

  • Andreessen Horowitz
  • Pantera Capital
  • Vy Capital
  • Valor Equity Partners
  • Fifth Wall Ventures
  • Craft Ventures
  • SV Angel

 

運営者情報

様々な知見をお持ちの方々に、ハイクォリティな記事を書いていただくメディアサイト

Twitter:@Stir_Lab

 

運営元

 

Twitterでフォローしよう

おすすめの記事