Pharos エコシステムセキュリティガイド：RWA 資産統合の全リンクリスク管理

本稿は、Pharosエコシステムの開発者向けに、より実践的で深みのあるRWA統合の参考資料を提供することを目的としています。ビジネスロジックとリスク管理アーキテクチャの観点から、現実世界資産（RWA）がオンチェーン化される際に直面する複雑な課題とその対応策を再現しようと試みます。

はじめに

Pharosエコシステムは、伝統的な金融資産とWeb3世界を結ぶインフラとなることを目指しています。ネイティブな暗号資産とは異なり、現実世界資産（RWA）はオフチェーンの実体権益とオンチェーンの取引属性の両方を兼ね備えています。この二重属性は、そのセキュリティ境界がスマートコントラクトのレベルに留まらず、資産の権利確定、データ同期、コンプライアンス規制の隅々まで拡張されなければならないことを決定づけています。

主要なRWAプロジェクトの深い分析[1]に基づき、アーキテクチャパターン、コアリスクゾーン、統合戦略の3つの次元から、Pharos開発者が堅牢なRWAアプリケーションを構築するための重要な道筋を整理します。

一、なぜPharosはRWAに適しているのか？

Pharosはインターネット規模を目指すLayer 1です。RWA開発者にとっては、基盤となるコンセンサスの詳細を深く理解する必要はなく、資産決済と複雑な計算という2つの核心的な内容の解決に集中すればよいのです。

1.並列実行とサブ秒単位の確定性 (Block-STM) 従来のEVMはトランザクションを逐次処理するため、大口のRWA配当支払いやリバランス時に詰まりやすいです。PharosはBlock-STM並列実行エンジンを導入し、サブ秒単位のファイナリティを実現しています。

• これは、オフチェーンの資金入金とオンチェーン決済がほぼ同時に完了できることを意味し、「T+1」による為替変動とスリッページリスクを排除します。

2.Dual-VMアーキテクチャ (EVM + WASM) PharosはネイティブでEVMとWASMの二重実行環境をサポートしています。

• EVM層：接続を担当します。既存のSolidity製レンディングプロトコルやDEXコードをそのままデプロイでき、RWA資産を受け入れます。
• WASM層：計算を担当します。RWAは複雑な利子税務、階層的なリスク管理、コンプライアンスホワイトリストロジックを伴い、EVMで実行するとGasコストが非常に高く非効率です。このような計算集約型ロジックをWASMモジュールに移行することで、高性能で低コストのオンチェーンリスク管理を実現できます。

https://docs.pharosnetwork.xyz

二、 RWAの2つの運営ロジック

Pharos上のRWAプロトコルを設計する前に、開発者は2つの主流の資産流動パターンとその資金回路を明確にする必要があります：

1.オンチェーンからオフチェーンへのモード

これは現在最も一般的なモードであり、本質的にはオンチェーンでの資金調達、オフチェーンでの資産運用です。投資家がオンチェーンでステーブルコイン（例：USDC）をステーキング → プロジェクト側が集約後、法定通貨（USD）に交換 → オフチェーンの高流動性資産（例：米国債）に投資 → 得られた利息収益がオンチェーンに戻り、トークン保有者に分配されます。

事例： Matrixdockの$STBT。適格投資家が$STBT（短期米国債に1:1でペッグ）をミント → 資金はプロジェクト側が国債購入に使用し、オンチェーン保有者は約4.8%の年率収益を得ます。

2.資産のオンチェーン化モード

このモードは、特定資産の証券化と細分化に重点を置いています。 プロジェクト側が特定のオフチェーン資産（例：不動産）をロックし評価 → 対応するシェアのERC-20トークンを発行 → 投資家がステーブルコインで購入 → プロジェクト側がオフチェーン資産の維持管理と運営を担当 → 生み出されたキャッシュフロー（例：家賃収入）を定期的にオンチェーンで配当。

事例： RealTの不動産トークン化。例えばデトロイトの価値6.59万ドルの不動産を1300個のトークンに分割し、投資家がトークンを購入することでその不動産の家賃収入に対する分配権を得ます。

三、 リスクマップとPharos統合戦略

RWAの致命的なリスクは、多くの場合コード内ではなく、オフチェーンとオンチェーンの接続部分にあります。既存のRWAプロジェクトは、本人確認、資産のペッギング、データの透明性において顕著な構造的欠陥を抱えています。開発者がPharos上でアプリケーションを構築する際は、以下のグレイ・ライノ（確実に来るが見過ごされがちな大規模リスク）に重点的に対処すべきです。

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

1.貫通型の本人確認コンプライアンス

プロジェクトはコンプライアンスを謳いながら、実際には形骸化していることがあります。統計によると、効果的なKYCを実施しているプロジェクトは半数以下であり、有名プロジェクト（例：RealT）でもビデオ認証の段階で写真一枚で簡単に騙せた事例がありました。一部のプロジェクトは白書でAMLを強調していても、実際の操作ではウォレットを接続するだけで取引可能で、資金源の追跡は全く不可能です。

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Pharos開発上の提案：

• Webフロントエンドだけで本人確認を行うのはやめましょう。スマートコントラクト層にホワイトリストメカニズムを統合し、DID（分散型アイデンティティ）またはオフチェーンKYC認証を通過したアドレスのみがmint関数やtransfer関数を呼び出せるようにする必要があります。$STBTを例にとると、ERC-20のtransfer関数とtransferFrom関数を書き換え、認証済みのホワイトリストからのみ呼び出し可能にします。

https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code

• 高額資産取引については、2FA（二要素認証）メカニズムを導入し、秘密鍵漏洩による資産盗難を防止します。研究によると、現時点でこれを実現しているプロジェクトはごくわずかです。

2.ステーブルコインへの依存とサーキットブレーカー

ステーブルコインはRWAの血液であり、約90%のプロジェクトが決済にステーブルコインに依存しています。しかし、開発者はしばしばステーブルコイン自体のデペッグリスクを見落としています。例えば、SVB事件によるUSDCのデペッグやUSDeなどのデペッグリスク[2]です。デペッグが発生した場合、プロジェクトは危機に対処するための専用のリスク準備金を持っているでしょうか？

https://x.com/ethena_labs/status/1976773136294224071

Pharos開発上の提案：

• オラクルは価格フィードだけでなく、リスク管理のトリガーとしても活用すべきです。決済通貨として使用されているステーブルコイン（例：USDC/USDT）の価格がペッグ値から閾値（例：5%）以上乖離したことを監視した場合、コントラクトは自動的にミントと償還を一時停止し、プロトコルがアービトラージ攻撃を受けるのを防ぎます。
• 資金プールを設計する際は、複数のステーブルコイン、さらにはバスケット通貨のサポートを検討し、単一資産のシステミックリスクの影響を低減します。同時に、ステーブルコインの選択においては、メカニズムが複雑なアルゴリズム型ステーブルコインは極力避けます。この種のステーブルコインは最もデペッグしやすいからです。

3.データブリッジと真正性検証RWA最大のブラックボックスは、オンチェーン資産が本当にオフチェーンの実物に対応しているかどうかです。多くのプロジェクトのいわゆる情報開示は、WebページにPDFファイルをいくつか掲載するだけであり、ループ再生の録画映像をリアルタイム監視カメラと偽装するような荒唐無稽な事例さえありました。OpenEdenの純資産価値（NAV）レポートもかつて1ヶ月遅れで公開されたことがあります。

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Pharos開発上の提案：

• Chainlinkなどのオラクルネットワークを活用し、オフチェーンのカストディ銀行や監査機関のAPIに直接接続します。Pharos開発者は、プロジェクト側の月次または四半期レポートに依存するのではなく、資産純価値（NAV）の分単位でのオンチェーン化を実現することを目指すべきです。
• プロジェクトの評価乖離リスクは時折発生します。開発時には複数ソースのオラクルによる価格フィードを導入し、可能な限りオンチェーン価格がオフチェーン市場を真に反映するようにします。

4.法的エンティティの分離と透明性

オフチェーン資産のデフォルト（債務不履行）はRWAが無視できないリスクであり、例えばGoldfinchは590万ドルの与信デフォルトに遭遇しました[4]。リスクを隔離する鍵はSPV（特別目的会社）にありますが、SPV構造を使用していると公に声明を出しているプロジェクトはごくわずかであり、その多くは具体的な登録法人名を開示していません。Goldfinchの危機を例にとると、$GFIトークンが20%下落する直接の原因となり、投資家は訳も分からず深刻な損害を被りました。

Pharos開発上の提案：

• プロジェクトのメタデータまたは説明文書において、資産を保有するSPVの法的名称および登録地の開示を義務付けます。
• 各資産プールが独立したSPVに対応することを保証します。Pharosのコントラクト設計においては、異なる資産プールの資金は論理的に完全に分離され、単一資産のデフォルトがプロトコル全体の流動性枯渇を引き起こさないようにする必要があります。

5.偽りの繁栄の後の流動性枯渇

流動性は、RWAプロジェクトにおいて最も偽装しやすいが、最も崩壊しやすい部分です[2]。多くのRWAプロジェクトは、上場初期の板の厚さをマーケットメーカーへの補助金に大きく依存しています。マーケットメーカープロトコルの期間満了または補助金停止後、セカンダリーマーケットの流動性はしばしば断崖式に低下し、買い注文が瞬時に消えてしまいます。 さらに、オフチェーン資産評価の低頻度性（通常は月次または四半期のNAV）とオンチェーン取引の高頻度性（秒単位のブロック生成）には、本質的な時間のミスマッチが存在します。オンチェーンで大口の売りが出た場合、AMMプールはリアルタイムの公正価値ガイダンスを欠いているため、迅速に価格を補填できず、価格が純資産価値から大きく乖離し、流動性のブラックホールを形成します。以下の$USDRの例では、取り付け騒ぎが発生し、トークン価格が数時間で1ド