本文へスキップ
Starone

ソリューション

オンチェーンとオフチェーンの記録を一致させ続けるトークン化インフラ

私たちは、現実資産をトークンとして表現するための技術を設計・構築します。資産の記録、許可型トークンのコントラクト、カストディ、投資家オンボーディング、そしてオンチェーンの保有者名簿をオフチェーンの事実に結びつける照合が対象です。

課題の全体像

現実資産をトークン化するとは、ファンドの持分、債券、不動産に対する権益、売掛債権など、オフチェーンに存在するものへの請求権を、ブロックチェーン上のトークンとして表現することです。トークンそのものは容易な部分です。資産は、物理的かつ法的な世界に存在し続けます。評価され、収益の支払いが生じ、カストディアンによって保管され、保有を認められる者はコントラクトの外にあるルールで定められます。インフラは、トークンとその現実を常に一致させ続けなければなりません。

このためトークン化プラットフォームは、大部分がオフチェーンのシステムであり、そこにオンチェーンの名簿が付く構成になります。エンジニアリングの大半を占めるのは、資産データの管理、投資家の本人確認と適格性、トークンを保有・移転できる者を制限する統制、分配と償還の処理、そして発行体、アドミニストレーター、監査人が数字を信頼できるようにする照合とレポーティングです。スマートコントラクトは、その中の小さいながらも重要なコンポーネントです。

このページはエンジニアリングのみを説明するものです。Staroneは、トークン化された資産やストラクチャーのリターン、価値、適法性、規制上の地位について一切の主張を行わず、この領域のライセンスも保有していません。オファリングの法的なストラクチャリング、トークンが付与する権利、各法域における規制上の取り扱いは、お客様とその法律顧問の領域です。私たちが構築するのは、お客様側が定めたルールを強制し、その証跡を残すように設計されたシステムです。

なぜ難しいのか

エンジニアリング上の課題

01

資産から乖離するトークン

オンチェーンの供給量や保有者名簿が、発行済み口数と保有者に関するオフチェーンの記録と一致しなければ、トークンはもはや、それが表すとされるものを表していません。乖離は、ミントの失敗、片側だけに行われた手作業の訂正、一貫性なく適用されたコーポレートアクションから生じます。これは監査で発見されるのではなく、機械的に検知されなければなりません。

02

誤った場所で強制される移転制限

フロントエンドやオフチェーンのサービスだけで検査される制限は、コントラクトを直接呼び出せば誰でも回避できます。適格性のルールは、すべての移転においてトークンコントラクトが強制しなければなりません。また、投資家のステータスの変化に応じて、トークンを再デプロイすることなく更新できる必要があります。

03

ウォレットアドレスに紐づく投資家の本人情報

コントラクトに見えるのはアドレスであり、ルールが対象とするのは確認済みの個人や法人です。この2つを結びつけるには、オンボーディングのプロセス、安全なレジストリ、そして鍵の紛失、ウォレットの変更、確認の有効期限切れへの対応が必要です。その過程で、個人データをパブリックチェーンに書き込んではなりません。

04

大規模なコーポレートアクション

分配、償還、分割、満期は、厳密な基準時点における保有者名簿に基づいて計算し、すべての保有者に正確に1回だけ適用しなければなりません。その間も移転は続きます。スナップショットが1ブロックずれたり、バッチが途中で失敗したりすると、巻き戻すことの難しい支払いが生じます。

05

アップグレード可能なコントラクトと管理権限

ルールは変わり、バグは見つかるため、コントラクトには通常、アップグレードまたは管理の経路が必要です。その経路は、システムの中で最も慎重な扱いを要する統制でもあります。それを握る者は、残高や挙動を変更できるからです。この経路には、複数当事者による承認、時間的な遅延、透明性のあるログ記録が必要です。

06

オフチェーンデータへの依存

評価額、入金確認、カストディの証明はオフチェーンで生まれ、コントラクトや投資家に向けて公開されます。誤った値や古い値は、価格の算定、発行、償還に波及します。そのデータの出所、署名、更新頻度には、コントラクトそのものと同じ厳格さが求められます。

構築の進め方

アーキテクチャ

プラットフォームは、資産、投資家、資金に関するオフチェーンの記録システム(システム・オブ・レコード)と、保有者名簿として機能する許可型トークンのコントラクトを組み合わせ、オーケストレーション層と継続的な照合によって両者を結びつけます。

  1. 01

    資産レジストリ・データサービス

    各資産は、識別子、条件、裏付けとなる文書、評価履歴、ライフサイクル上の状態を含む構造化されたレコードとして登録します。文書はオフチェーンに保存し、その暗号学的ハッシュをオンチェーンに記録するため、内容を公開することなく完全性を検証できます。資産レコードの変更は承認ワークフローを経て行い、バージョン管理します。

  2. 02

    許可型トークンのコントラクト

    トークンは、EVMネットワークにおけるERC-3643やERC-1400、あるいは他のネットワークでそれらに相当するものなど、許可型資産向けの確立された標準規格に基づいて実装します。コントラクトはすべての移転でコンプライアンスモジュールを参照し、設定されたルールに違反するものを拒否します。ミント、バーン、凍結、強制移転、一時停止の各機能は、お客様の法的ストラクチャーが必要とする場合に設け、それぞれロールベースのアクセス制御の背後に置きます。

  3. 03

    IDレジストリとコンプライアンスルール

    オンチェーンのレジストリが、ウォレットアドレスを、確認済みの投資家の本人情報および法域や投資家区分といった属性に対応づけます。保存するのは参照情報とクレームであり、個人データは含めません。コンプライアンスルールは、許可リスト、法域ごとの制限、保有者数の上限、ロックアップ期間を扱うモジュール式のコントラクトです。ルールは、お客様とその法律顧問が指定する条件を反映するように資産ごとに設定し、トークンを置き換えることなく更新できます。

  4. 04

    投資家オンボーディングサービス

    オフチェーンのワークフローが、投資家情報を収集し、本人確認とスクリーニングのプロバイダーと連携し、お客様のポリシーに基づいて下された適格性の判断を記録します。承認されると、投資家のウォレットをIDレジストリに登録します。再確認、ウォレットの差し替え、登録の取り消しにも対応し、個人データは、アクセス制御と保存期間のルールが適用される暗号化されたストアに保持します。

  5. 05

    カストディと鍵管理

    発行体と管理者の鍵は、HSM(ハードウェアセキュリティモジュール)で保持するか、MPC(マルチパーティ計算)で分割し、複数承認者によるポリシーで統制します。投資家の保有分は、設計に応じて、セルフカストディとすることも、連携するカストディアンを通じて保管することもできます。コントラクトの管理とアップグレードは、タイムロック付きのマルチシグ構成の背後に置くため、変更は効力が生じる前に確認できます。

  6. 06

    発行・償還・コーポレートアクションのエンジン

    オーケストレーションサービスが、ライフサイクル上の操作を耐久性のあるワークフローとして実行します。申込みは、トークンをミントする前に着金した資金と突合します。償還ではトークンをバーンし、支払指図を起動します。分配では、エンジンが定められたブロックで保有者のスナップショットを取得し、各保有者の受取額を計算し、失敗後に再開できる冪等なバッチで支払いを実行します。

  7. 07

    照合とレポーティング

    インデクサーがすべてのトークンイベントを読み取ってオンチェーンの保有者名簿を再構築し、それをスケジュールに従って、オフチェーンの名簿ならびに資金とカストディの記録と比較します。差異があれば、担当者を割り当てた例外として起票します。レポーティングでは、発行体、アドミニストレーター、監査人に向けて、保有者名簿、取引履歴、残高明細を作成し、いずれもオンチェーンのイベントと元の記録まで遡ることができます。

現実資産(RWA)トークン化のフロー

オフチェーン

  1. 01

    資産オンボーディング

    法的ストラクチャーと関連文書

  2. 02

    投資家KYC

    本人確認と適格性の確認

  3. 03

    資産レジストリ

    所有権と権利の記録

  4. 04

    照合(リコンサイル)

    レジストリとチェーン状態を突合

  5. 05

    レポーティング

    明細、監査、開示

オンチェーン

  1. 01

    トークン発行

    登録済み資産に対してミント

  2. 02

    許可リスト

    確認済みウォレットのみ保有可能

  3. 03

    移転制御

    コントラクト内でルールを強制

  4. 04

    決済

    支払いと引き換えのアトミックな移転

  5. 05

    ライフサイクルイベント

    分配、償還、バーン

オフチェーンのレジストリが資産と保有者の法的な記録を保持し、オンチェーンのトークンは強制力のある移転ルールのもとでそれを反映します。照合(リコンサイル)によって両者の一致を保ち、その結果をレポーティングに反映します。

プロジェクトの成果物

  • 資産データモデルと登録ワークフロー
  • テストスイートを備えた許可型トークンとコンプライアンスのコントラクト
  • IDレジストリと投資家オンボーディングの連携
  • カストディ設計とコントラクト管理の統制
  • 発行、償還、分配のワークフロー
  • オンチェーンインデクサーと三者間照合
  • 発行体・アドミニストレーター向けレポーティングと監査対応資料

着手する前に

早い段階で決めておくべきこと

パブリックチェーンか、許可型チェーンか、プライベートチェーンか
パブリックネットワークは、ウォレットとインフラの幅広い対応、そして独立した検証可能性を備えており、移転の制御はトークンのレベルで強制します。許可型またはプライベートのネットワークは、参加者、手数料、データの可視性を制御できる一方、相互運用性は限られます。この選択は、誰がその資産を保有・検証できなければならないか、求められるプライバシー、そして関係する規制当局の期待によって決まります。規制当局の期待については、お客様とその法律顧問が確認すべき事項です。
どのトークン標準規格を使うか
独自のコントラクトよりも、確立された許可型トークンの標準規格を優先して使います。標準規格には、監査済みのリファレンス実装と、カストディアンやツール群との互換性が伴います。選定にあたっては、オンチェーンのIDクレーム、異なるシェアクラス向けに区分された残高、文書管理のいずれが必要か、また想定するカストディアンと取引の場が何に対応しているかを基準にします。
正となる名簿をどこに置くか
チェーンを確定的な保有記録としてオフチェーンのシステムがそれをミラーするか、オフチェーンの名簿を確定的なものとしてトークンがそれを反映するかのいずれかです。これは法的な判断であり、不一致や鍵の紛失をどう解決するかについて、エンジニアリング上の直接的な帰結を伴います。プラットフォームは、お客様の法的ストラクチャーが定める立場を実装し、どちらの場合でも継続的に照合しなければなりません。
管理者による統制をどこまで組み込むか
凍結、強制移転、リカバリーといった機能は、裁判所の命令や鍵の紛失に対応するために、規制対象の資産では必要とされることが多くあります。同時に、どの機能も、誤用されればリスクになります。法的ストラクチャーが求めるものだけを組み込み、それぞれを複数当事者による承認の背後に置き、すべての使用をオンチェーンに記録します。

FAQ

よくあるご質問

ある資産をトークン化できるかどうかについて、Staroneは助言しますか。

いいえ。ある資産をトークン化できるかどうか、どのようにトークン化するか、トークンがどのような権利を伴うか、どの規制が適用されるかは、お客様とその法律顧問が扱う法的な問題です。Staroneは、お客様側が定めたストラクチャーを実装するためのインフラを設計・構築する立場であり、適法性、規制上の地位、投資としての是非について一切言及しません。

投資家の個人データはブロックチェーンに保存されますか。

保存すべきではありません。設計上、個人データは暗号化されたオフチェーンのストアに保持し、オンチェーンに置くのはウォレットアドレス、本人情報への参照、適格性のクレームだけです。これにより、コントラクトは投資家が誰であるかを露出させることなくルールを強制でき、個人データは、適用されるデータ保護のルールに基づいて訂正または削除できます。

投資家がウォレットにアクセスできなくなった場合はどうなりますか。

法的ストラクチャーがそれを定めている場合、トークンコントラクトにはリカバリー機能を持たせます。この機能は、投資家の本人確認をあらためて行った後、保有分を新たな確認済みアドレスに移します。この操作には複数当事者による承認が必要であり、オンチェーンに記録されます。手続きとその前提条件は、お客様が定めます。

スマートコントラクトは監査を受けていますか。

コントラクトは、確立された標準規格とライブラリの上に構築し、ユニットテスト、結合テスト、ファズテスト、不変条件テストで検証します。価値を表すコントラクトをデプロイする前、および重要な変更を加えた後には、独立した外部のセキュリティ監査を受けることを推奨します。監査の手配は、デリバリー計画に含めます。

本番環境で動くシステムが必要な方へ

構築しようとしているものをお聞かせください。エンジニアが内容を拝見し、2営業日以内にご返信します。