エンジニアリングシナリオ
参考例RWAトークン化プラットフォーム
現実資産を許可型トークンとして表現するためのエンジニアリングシナリオです。正本となるオフチェーンのレジストリ、強制力のある移転制御、継続的な照合（リコンサイル）を備えます。
課題
ファンドの持分、債務証券、現物資産の持分といったオフチェーンの資産を、パブリックブロックチェーン上のトークンとして表現したい発行体を想定します。その意図は、資産をすでに規律している法的および規制上の枠組みを維持しながら、発行、移転、サービシングをプログラム可能にすることです。
トークンは表現であり、法的な請求権は別の場所に存在します。オンチェーンの記録とオフチェーンのレジストリが食い違った場合、あるいは保有する適格性のない者にトークンが渡った場合、プラットフォームはその主たる役割を果たせていません。したがって、エンジニアリングの大部分は、2つの記録の整合を保つことと、移転ルールを迂回できないようにすることに費やされます。本シナリオはエンジニアリングのみを説明するものであり、法務、財務、投資に関する助言ではありません。
設計が満たすべき要件
- 確認済みで適格な保有者に属するウォレットだけがトークンを受領または保有でき、この制約はコントラクト自体によって強制されなければなりません。
- オフチェーンのレジストリは所有権の記録であり続け、チェーンの状態と継続的に照合されなければなりません。
- 発行体は、移転の一時停止や紛失したウォレットからのトークン回復といった統制された管理操作を、複数当事者の承認のもとで実行できなければなりません。
- 発行、分配、償還は、オフチェーンの指図からオンチェーンのトランザクションまで、またその逆方向にも追跡できなければなりません。
- 個人データはオフチェーンにとどめ、台帳には必要最小限の参照のみを記録しなければなりません。
- コントラクトのロジックは、トークン残高や保有者アドレスを変えることなく、ガバナンスのもとでアップグレードできなければなりません。
設計
コンポーネント
オフチェーン
- 01
資産オンボーディング
法的ストラクチャーと関連文書
- 02
投資家KYC
本人確認と適格性の確認
- 03
資産レジストリ
所有権と権利の記録
- 04
照合（リコンサイル）
レジストリとチェーン状態を突合
- 05
レポーティング
明細、監査、開示
オンチェーン
- 01
トークン発行
登録済み資産に対してミント
- 02
許可リスト
確認済みウォレットのみ保有可能
- 03
移転制御
コントラクト内でルールを強制
- 04
決済
支払いと引き換えのアトミックな移転
- 05
ライフサイクルイベント
分配、償還、バーン
資産オンボーディングとレジストリ
レジストリは、各資産、その条件、裏づけとなる文書、およびトークンコントラクトとの対応関係を記録します。保有者とそのポジションの名簿も保持し、監査人や管理者が参照するシステムとなります。文書のハッシュをオンチェーンにアンカリングすることで、記録が変更されていないことを裏づけられます。
投資家オンボーディングと適格性
投資家は、連携したKYCプロバイダーを通じて本人確認と適格性チェックを完了し、その結果はオフチェーンに保存されます。確認済みの投資家は、チャレンジに署名して管理権を証明することで、1つ以上のウォレットアドレスを登録します。適格性は失効することも取り消されることもあり、その変更はオンチェーンの許可リストに反映されます。
許可型トークンコントラクト
トークンはERC-20インターフェースに準拠し、ERC-3643のような許可型トークン標準の方式にならって移転制限を追加します。すべての移転はコンプライアンスモジュールを呼び出し、送付者と受領者をアイデンティティレジストリおよび適用されるルールに照らして確認します。一時停止、強制移転、回復といった管理機能を備えており、これらはロールによって制限され、イベントを発行します。
発行およびライフサイクルサービス
このサービスは、承認済みのオフチェーンの指図をオンチェーンのトランザクションに変換します。申し込み時のミント、償還時のバーン、分配の記録です。各指図は識別子を持ち、結果として生じるトランザクションハッシュとともに保存されるため、両者は常に結びつけられます。操作は冪等であるため、リトライされた指図が二重にミントされることはありません。
決済
支払いがトークン化された通貨によってオンチェーンで行われる場合、資産の移転と支払いの移転は、1つのトランザクションでアトミックに実行されます。支払いが銀行の決済網を通じて行われる場合、資産側の移転は、支払いがオフチェーンで確認された後にのみ実行されます。利用できる決済資産は市場によって異なるため、設計は両方をサポートします。
カストディと鍵管理
発行体と管理者の鍵は、HSMまたはMPCベースの署名基盤で保持し、コントラクトの特権ロールはマルチシグアカウントに割り当てます。単独の人物がミント、一時停止、アップグレードを行うことはできません。投資家は、自身のウォレットでもカストディアンのもとでもトークンを保有でき、プラットフォームはどちらも登録済みアドレスとして扱います。
インデックスと照合（リコンサイル）
インデクサーはトークンコントラクトを追跡し、ファイナリティ時点の残高と移転のオンチェーンビューを構築します。照合ジョブはそのビューをレジストリと比較し、差異があれば不一致（ブレイク）として起票します。不一致は次のレポーティングサイクルまでに調査されます。これは、いずれかの記録の誤りを検出するための統制です。
レポーティングと監査
保有者は、照合済みの記録から生成された明細を受け取ります。管理者と監査人は、あらゆるポジションを、それを生み出した指図とトランザクションまでさかのぼって追跡できます。レポーティングの出力は発行体の開示義務を支援するよう構成されますが、その義務を負うのは引き続き発行体とそのアドバイザーです。
トレードオフ
設計判断
| 判断 | 理由 |
|---|---|
| 移転制限はオンチェーンで、トークンコントラクト内で強制 | チェックをアプリケーション側だけで行う制限なしのトークンは、構築が容易で、より多くのウォレットや取引の場と連携できます。しかしそれは、保有者がオンチェーンで任意のアドレスへ直接移転できることも意味します。適格性をコントラクト内で強制すると、トークンが移動できる先は狭まりますが、それこそが目的です。 |
| オフチェーンのレジストリを所有権の記録とする | チェーンを唯一の記録として扱う考え方は概念としては明快ですが、鍵の紛失、裁判所の命令、運用上の誤りに対する是正手段が残りません。レジストリを正本とし、トークンをその同期された表現として位置づけると、照合の負担は加わりますが、こうした資産の所有権が一般的に確定される方法と合致します。 |
| プライベート台帳ではなく、EVM互換のパブリックチェーン | プライベート台帳は参加者と手数料を統制できますが、既存のウォレット、カストディアン、ツール群との相互運用性が制限されます。パブリックなEVMチェーンは、そのエコシステムと成熟した監査ツールを利用できます。その代償はトランザクションが公開されることと手数料が変動することであり、個人データをオフチェーンに置くのはこのためです。 |
| ガバナンスされたプロキシの背後に置く、アップグレード可能なコントラクト | 変更不可能なコントラクトは保有者に最も強い保証を与えますが、ルールや規制が変わっても修正できません。プロキシパターンはアップグレードを経ても残高を保てる一方で、アップグレードに伴うリスクを持ち込みます。このリスクは、マルチシグによる統制、タイムディレイ、新しい実装ごとの独立した監査によって軽減します。 |
| 個人データはすべてオフチェーンで保持 | アイデンティティ属性をオンチェーンに記録すれば一部のチェックは単純になりますが、そのデータは恒久的かつ公開されたものになります。そのため、コントラクトはアドレスと適格性フラグのみを保存し、アドレスと個人との結びつきは、保護も削除もできるオフチェーンシステムにとどめます。 |
意図する成果
- 確認済みで適格な保有者に属するウォレットだけが保有できるトークン
- オンチェーンの記録とオフチェーンのレジストリを継続的に相互確認する仕組み
- 複数の承認者を必要とし、公開された痕跡を残す管理操作
- 指図からトランザクション、明細まで追跡できるポジション
この設計が達成を目指すものです。参考例であり、クライアント案件の実測結果ではありません。
代表的な技術
- Solidity
- Ethereum / EVM
- ERC-20 / ERC-3643
- TypeScript
- Node.js
- Go
- PostgreSQL
- Kafka
- HSM / MPC signing
- Kubernetes
- Terraform