ソートリーダー
セキュリティトークンプロトコルにおける相互運用性の必要性 – Thought Leaders
Securities.io を Google の優先ソースに追加
トークンの簡単な歴史
ビットコインがブロックチェーン技術を世界に初めて紹介してから10年以上が経過しました。その間に、分散型台帳の潜在的なユースケースは急速に拡大し、デジタル通貨からサプライチェーン、アイデンティティ管理に至るまで多岐にわたります。根底にあるのは、ユーザーがピアツーピアでデジタル資産を保有・転送できるという共通構造です。言い換えれば、中央の信頼できる権限がなくてもデジタル資産の取引や追跡が可能になったということです。
この領域の進化は自然に「トークン」の発明へとつながりました。トークンとはブロックチェーン上の所有可能で転送可能なデジタル資産です。トークンは大きく二つに分類されます：ネイティブなデジタル資産を表すものと、実世界の基礎資産を表すものです。この新しいパラダイムを活用し、Ethereumだけでも数十万種のトークンが作成され、執筆時点での合計時価総額は150億ドルを超えています。
トークンの最も有望な応用の一つは、実世界の証券をオンチェーンで表現することです。これにより、商業用不動産のような従来は流動性が低い資産を分割化し、ピアツーピアで転送できるようになります。このプロセスは「トークン化」と呼ばれ、既存の資本市場における多くの課題を緩和できる可能性から、既存の金融機関と新興スタートアップの双方で大きな関心を集めています。
規制遵守
ブロックチェーンは技術的には所有権の転送を容易にしますが、セキュリティトークンは従来の証券と同様に法令や規制の対象です。セキュリティトークンが規制に適合していることを確保することは、トークン化の可能性を実現する上で不可欠であり、これまでの採用の壁となってきました。下のチャートが示すように、規制の不確実性はブロックチェーン採用における最大の障壁と広く認識されています。
ブロックチェーン領域では多数のプロジェクトが登場し、セキュリティトークンの規制・取引・管理を簡素化・標準化しようとするプロトコルを設計しています。Ethereumだけでも、Securitize、Harbor、Polymath などが標準化に取り組むプロジェクトとして公開されています。しかし、現在のプロトコル設計に変更が加えられなければ、投資家や取引所はトークン化証券の売買時に大きな摩擦を経験し続けます。なぜでしょうか？ それは「相互運用性」の欠如です。
相互運用性は重要です
相互運用性はトークン化の最も重要な利点の一つです。共通のソフトウェア標準を共有することで、資本市場アプリケーションや製品のエコシステム全体が相互に統合できるようになります。しかし、アプリケーションや製品レベルで相互運用性を実現するには、まずトークン自体のレベルで始める必要があります。セキュリティトークン領域では、相互運用性は取引所と投資家という二つの主要な関係者にとって不可欠です。
取引所としては、投資家が購入資格を持つあらゆるセキュリティトークを承認できるようにしたいと考えます――トークンを発行した企業が誰であっても構いません。つまり、各セキュリティトークごとに個別の統合を行うのではなく、すべてのトークンに対して統一されたシンプルで汎用的な統合が必要です。
投資家としては、オンボーディングプロセスをできるだけシンプルで摩擦なくしたいと考えます。現在、投資家が複数のプラットフォームで株式を購入しようとすると、何度も個人情報を提供しなければならない「顧客確認（KYC）」プロセスが発生します。ブロックチェーンはこの情報をオンチェーンに不変的に保存し、すべてのセキュリティトークが参照できるようにすることで、同じ情報を繰り返し提供する必要をなくす可能性があります。初回登録後は、補足的または更新された情報だけが求められるようになるでしょう。ただし、このプロセスが実現するのは、セキュリティトーク間の相互運用性が標準に組み込まれている場合に限ります。
プロトコル
Ethereum の主要なセキュリティトークプロトコルは、Securitize、Harbor、Polymath の3社が公開しています。これらはすべて Ethereum の ERC-20 トークン標準上に構築され、さらに取引時にコンプライアンスを強制する拡張が加えられています。具体的には、取引が行われるたびに第2のコントラクトに対して合法性を照会します。
プロトコルごとに名称は異なりますが、第2のコントラクトを使用する点は共通で、目的は同じです――コンプライアンスに違反する取引を防止することです。この第2の「Regulator」コントラクトは、オフチェーンで認可されたサービス（例：取引所やトークン発行者）がユーザーの KYC や認定情報を更新することで最新の状態が保たれます。
これら3つのコンポーネントは、セキュリティトークを規制するために必要な要素すべてを備えているように見えます（最も単純な形では実際にそうです）。しかし、相互運用性はコンポーネントの実装方法に依存します。残念ながら、現在のプロトコルは以下の2つの重要領域で相互運用性が欠如しており、これが技術の採用を遅らせる摩擦となっています：
- 認可された当事者は、ユーザー情報をオンチェーンでどのように更新するか？
Harbor
Harbor はホワイトペーパーで、当面はユーザー情報をオンチェーンで更新できる唯一の当事者は自社だけになると宣言しています。この役割の集中化により、取引所は Regulator が参照するデータを更新できず、新たなトークン受取人を承認できません。その結果、Harbor プラットフォーム外でトークンを容易に取引できなくなります。
Securitize
Securitize はすでに複数の当事者が認可できるシステムを実装しており、投資家は複数の場所でコンプライアンス情報を登録でき、Securitize 自体を通さずに済みます。オンチェーンデータは認可された当事者が直接更新し、すべての Securitize トークンが閲覧可能です。さらに、投資家が情報を何度も提供しなければならない負担を減らすため、Securitize はオフチェーンに保存された投資家のプライベート情報へ認可された当事者がアクセスできる API を設計し、個人がコンプライアンスを満たしているか、追加情報が必要かを容易に判断できるようにしています。
Polymath
Polymath はプラットフォーム全体でさまざまなタスクを実行するために必要なネイティブユーティリティトークン POLY を持っています。個人が KYC を行うには、まず POLY トークンを購入する必要がありますが、POLY と法定通貨の直接的な流動市場はありません。そのため、まず法定通貨で Ethereum の「ether（ETH）」などの暗号通貨を購入し、これを POLY に交換します。取得した POLY は Polymath の KYC マーケットプレイスで入札に使用され、KYC プロバイダーが入札を承認すれば、個人の KYC 検査に対して POLY で支払われます。このプロセスは Polymath プラットフォームへのオンボーディング摩擦を大きくし、必要以上に複雑です。
- このユーザー情報はオンチェーンでどのように保存・参照されるか？
Harbor
ホワイトペーパーと GitHub 上のスマートコントラクトを確認すると、技術的には多くの Harbor トークンが共通の Regulator コントラクトと共通のユーザーデータソースを共有できることが分かります。ただし、トークンごとに規制が異なるため実現は難しいでしょう。Ethereum 上で実際に稼働中の Harbor トークンが少ないため、すべてのトークンが共通 Regulator を使用する意図なのか、各トークンが独自の Regulator を持つのかは明確ではありません。
Securitize
Securitize のプロトコルは、Regulator コントラクトがユーザー情報を格納する第3のスマートコントラクトを照会するよう設計されています。これにより、各トークンは独自の Regulator に固有の規制をエンコードしつつ、第3のコントラクトで共通のユーザーデータソースを共有できます。その結果、ある Securitize トークンで KYC を行うと、情報は保存され、将来のトークン購入時にすぐに利用可能となります。
Polymath
ホワイトペーパーには、Polymath がオンチェーンにコンプライアンスデータの中央ソースを持ち、各 Regulator がそれと連携するか、各トークンがローカルな情報源を持つかは明示されていません。ただし、サンプルコントラクトを見る限り、各トークンはローカル情報源を使用しており、トークン間で共有されていません。この構成は利点もありますが、データの冗長性や不整合のリスクを伴います。
例を挙げます――Bob は Polymath のセキュリティトーク ABC と DEF の両方に投資家として承認されています。この情報はそれぞれのトークンの Regulator コントラクトに送信されます。1か月後、Bob がさらに DEF トークンを購入しようとしたところ、認定が失われていることが判明します。この情報は DEF の Regulator に送られ、Bob の投資家ステータスが非認定に更新されます。オンチェーン上では情報が矛盾します――ABC は Bob が認定投資家とみなす一方、DEF はそうではありません。中央情報源があれば、このような不整合は防げたはずです。
プロトコルの相互運用性
前述の通り、セキュリティトークの発行・取引に関わる主な関係者は取引所と投資家の二者です。両者は異なるセキュリティトークとやり取りする際にスムーズな体験を求めています。したがって、プロトコルをそのまま使用した場合、取引所とユーザーがどのような影響を受けるかを見てみましょう。
Exchanges
取引所としては、転送目的でこれらのプロトコルを統合するのは簡単です――すべてのトークンが ERC-20 標準を利用しており、転送、承認、残高確認のインターフェースが統一されています。しかし、各プロトコルのコンプライアンス部分を統合するのははるかに複雑です。現在、信頼できる当事者が Harbor のプロトコルで認可されることはできず、ユーザーは Harbor に直接 KYC を行う必要があります。Securitize のプロトコルと統合するには、信頼できる当事者が Securitize から認可を受け、オフチェーン API を通じて投資家の KYC データにアクセスし、オンチェーンデータストアに保存された情報を更新できるようにしなければなりません。
Polymath のプロトコルとの統合は最も複雑です。信頼できる当事者は Polymath の KYC マーケットプレイスに KYC プロバイダーとして登録し、KYC サービス提供の対価として POLY トークンで入札を受け取る必要があります。投資家に KYC サービスを提供する際、各証券の Regulator に保存された重複したオンチェーンデータが不整合にならないように管理する仕組みを構築しなければなりません。
さらに、プロトコルごとにインターフェースが異なるだけでなく、エラーレポートの提供方法も異なります。インターフェースを構築する際には、発生したエラーをユーザーが理解できる形に変換できることが重要です。たとえば、ユーザーがトークンを購入できない場合、考えられる理由は多岐にわたります――保有期間がまだ満了していない、許容できる保有者数の上限を超えている、などです。これらのメッセージをユーザーに伝えるには、取引所は各プロトコルごとに異なるエラーレポート手法と統合しなければなりません。
Investors
現在のプロトコル設計では、投資家のオンボーディング方法がそれぞれ異なるため、投資家は複数のプラットフォームで何度も個人情報を提供しなければならず、手間が増大します。これは、Harbor が他の当事者を認可していないこと、Polymath が投資家に POLY トークンで入札させることが原因です。このようなコンプライアンス手法の摩擦は、投資家が本来購入したい証券の取得意欲を削ぐ可能性があります。
このプロトコル由来の摩擦は、取引所が各プロトコルを統合する方法次第である程度緩和できるかもしれません。たとえば、投資家が Polymath トークンを購入するために取引所で KYC を行った場合、取引所が認可されていれば同時に Securitize のデータストアも更新できるでしょう。これにより、将来必要になる可能性のある情報がオンチェーンに保存されます。しかし、現在のプロトコル設計に変更が加えられなければ、証券の登録・購入プロセスは依然として敷居が高いままです。
解決策
この問題への解決策は必ずしも複雑である必要はありません。実際、Ethereum 上で既に稼働しているトークンを変更せずに導入できる解決策があります。取引所と投資家の双方にとって摩擦を最小限に抑え、複数のコンプライアンスデータソースによるデータ不整合を防ぐ理想的な解決策は、Securitize の集中型オンチェーンデータストアに似た形になるでしょう。ただし、このような仕組みは業界全体で採用される必要があります。
オンチェーン上に中央情報源を持つことで、データ不整合のリスクは排除され、投資家は一度のコンプライアンス検証で複数の証券を購入できるようになります。この中央コントラクトは、すべてのセキュリティトークに対して転送がコンプライアンスに適合しているかを検証し、適合すれば転送を続行し、そうでなければロールバックします。すべての認可取引所が利用できるオフチェーン API により、投資家のコンプライアンス情報を取引所に伝達でき、投資家が情報提供を求められる回数が減少します。これらの要素は、取引所が行う統合作業の負担も大幅に軽減します。
このような新システムの導入は確かにいくつかの課題を伴います。たとえば、各取引所がどのように認可されるかという設計上の問題です――取引所を信頼できると判断するのは誰か、合意形成のプロセスをどのように設計するか、といった点です。これらを解決するには時間と慎重な設計が必要です。
結論
証券のトークン化は、規制コンプライアンスの複雑さが原因で、まだ開発・採用の初期段階にあります。プロトコルの公開により多くの規制が取引実行時に自動的に適用され、コンプライアンスが簡素化されたものの、シームレスなプロセスになるまでにはまだ道のりがあります。オンチェーン・オフチェーン双方で投資家情報の保存・更新方法についてプロトコル間で合意が得られない限り、関係者全員が直面する登録・投資プロセスの摩擦は残り続けるでしょう。
