DeFi市場が単純な資産スワップから高頻度取引やプロフェッショナル向けデリバティブへと進化する中で、オンチェーンマッチングシステムの重要性が高まっています。Phoenixのオンチェーンマッチングプロセスは、注文執行効率だけでなく、市場流動性、リスクコントロール、取引コストにも影響を与えます。
急速に拡大するSolana高頻度取引エコシステムを背景に、Phoenixに代表されるオンチェーンオーダーブックモデルが再び市場の注目を集めています。
PhoenixはCentral Limit Order Book(CLOB)モデルを使用して取引を執行します。ユーザーは買い注文と売り注文を提出し、それらはオンチェーンオーダーブックに入り、価格・時間優先順位に基づいてマッチングされます。
AMMモデルとは異なり、Phoenixは自動価格設定のために流動性プールに依存しません。代わりに、市場価格は実際の注文を通じて形成され、アルゴリズム的な計算式ではなく、買い手と売り手の間の需給を反映します。
Phoenixでは、オーダーブックデータ、注文ステータス、取引履歴はすべてオンチェーンに保存されます。ユーザーは市場デプス、注文価格、取引履歴を公開で閲覧でき、市場の透明性と検証可能性が向上します。
オーダーブック取引はより高頻度なデータ更新と状態同期を必要とするため、Phoenixは強力な基盤ネットワークパフォーマンスを要求します。Solanaの高スループットと低遅延により、オンチェーンでのリアルタイムマッチングシステムをサポートすることが可能です。
ユーザーがPhoenixに注文を提出すると、システムはいくつかのステップを経ます。
まず、ユーザーはウォレットを介して取引リクエストに署名する必要があります。注文情報には、取引方向、価格、数量、レバレッジ比率、注文タイプが含まれます。
次に、Phoenixのリスクエンジンがアカウントの状態をチェックします。チェック項目は以下の通りです。
アカウントがリスク要件を満たした場合のみ、注文はオーダーブックに入ることが許可されます。
ユーザーが指値注文を提出した場合、マッチングを待つためにオーダーブックに配置されます。成行注文の場合は、現在の市場の既存注文に対して即座に約定を試みます。
注文提出プロセス全体はオンチェーンで行われるため、すべての注文ステータスは公開で検証可能です。
Phoenixのマッチングロジックは、価格・時間優先順位の原則に従います。
新しい買い注文が市場に入ると、システムは最も低い価格の売り注文を探してマッチングします。逆に、売り注文が市場に入ると、最も高い価格の買い注文とのマッチングを優先します。
複数の注文が同じ価格の場合、オーダーブックに早く入った注文が先に執行されます。このメカニズムは、伝統的な金融市場のオーダーブックロジックと基本的に同じです。
例えば:
Phoenixのマッチングプロセスは中央集権型サーバーに依存せず、オンチェーンプログラムを通じて注文ステータスの更新と取引確認を行います。これが完全オンチェーンモデルの重要な特徴です。
無期限先物取引にはレバレッジが伴うため、証拠金管理はマッチングプロセスの重要な部分です。
取引が執行された後、Phoenixはユーザーのアカウントで以下の項目を更新します。
システムはアカウントのリスクレベルを継続的に監視します。市場価格の変動により口座資産が減少すると、アカウント維持証拠金レベルがそれに応じて変化します。
アカウントリスクが安全域を超えた場合、Phoenixのリスクエンジンは清算メカニズムを作動させ、プロトコルが不良債権リスクを負うのを防ぎます。
すべてのポジションステータスはオンチェーンに記録されるため、ユーザーはアカウントリスクの変化をリアルタイムで確認できます。
Phoenixはオーダーブックを使用して価格設定を行いますが、市場参照価格を提供するためにオラクルにも依存しています。
オラクル価格は主に以下のために使用されます。
オーダーブック価格のみを使用した場合、流動性不足により市場で短期的な異常変動が発生する可能性があります。そのため、Phoenixはオラクルデータを組み合わせてリスクシステムの安定性を維持します。
オンチェーンデリバティブ市場では、オラクルシステムはリスクコントロールの重要な構成要素です。オラクルの異常は資金調達率、清算ロジック、市場の安定性に影響を与える可能性があるため、Phoenixは信頼できるデータソースに依存する必要があります。
取引がマッチングされた後、システムは執行結果をオンチェーン状態に書き込み、ユーザーのポジションデータを更新します。
オンチェーン決済には以下が含まれます。
Phoenixはノンカストディアル構造を採用しているため、ユーザーの資産は常にオンチェーンアカウントによって管理され、中央集権型プラットフォームが保有することはありません。
このモデルは透明性を向上させますが、すべての取引アクションがブロックチェーンネットワークの確認に依存することを意味します。そのため、基盤ネットワークのパフォーマンスが取引体験に直接影響します。
Solanaの高速確認能力は、Phoenixがオンチェーンオーダーブックを運用できる主要な理由の一つです。
Phoenixと従来のAMMプロトコルの最大の違いは、取引執行方法にあります。
AMMモデルは流動性プールとアルゴリズム価格設定に依存します。ユーザーは事実上プールと取引を行います。対照的に、Phoenixのオーダーブックモデルはユーザー間の直接マッチングを可能にします。
両モデルは取引プロセスにおいて明確な違いを示します。
| 次元 | Phoenix | AMMモデル |
|---|---|---|
| 取引構造 | オーダーブックマッチング | 流動性プール |
| 価格形成 | 買い/売り注文 | アルゴリズム価格設定 |
| スリッページコントロール | 比較的低い | 大口取引で顕著 |
| マーケットメイク方法 | プロフェッショナルなマーケットメイカー | LPが流動性を提供 |
| 高頻度取引サポート | 強い | 比較的限定的 |
| 注文タイプ | 指値注文、成行注文 | 通常は少ない |
オーダーブックモデルは一般的にプロフェッショナルな取引や定量戦略に適しており、AMMは基本的な資産スワップとオープンな流動性提供に最適です。
Solanaのようなハイパフォーマンスネットワークの開発に伴い、より多くのオンチェーンデリバティブプロトコルがオーダーブックアーキテクチャを再探求しています。
Phoenixのオンチェーンマッチングプロセスは、注文執行効率だけでなく、DeFi市場で起こっている構造的な変化を反映しています。
初期のDeFiプロトコルはオープンな参加と許可不要の流動性を重視していましたが、新しい世代のオンチェーンデリバティブプロトコルは以下に焦点を当てています。
Phoenixの完全オンチェーンオーダーブックモデルは、本質的には伝統的な金融市場のオーダーブック構造をブロックチェーン環境に移行する試みです。
このようなプロトコルの発展は、DeFiが単純な資産交換ツールからより複雑なオンチェーン金融インフラへと進化していることを示しています。
Phoenixは、オンチェーン無期限先物取引のために完全オンチェーンオーダーブックアーキテクチャを使用しています。そのマッチングプロセスには、注文提出、リスクチェック、注文マッチング、ポジション更新、オンチェーン決済の複数の段階が含まれます。
従来のAMMモデルと比較して、Phoenixは注文の厚み、価格発見効率、高頻度取引能力を重視しています。Solanaのハイパフォーマンスネットワークを活用して、Phoenixは伝統的な取引所のレベルに迫るマッチングシステムをオンチェーンで運用しています。
DeFi市場がプロフェッショナルな取引シナリオへと拡大するにつれて、オンチェーンオーダーブックモデルが再び注目を集めています。Phoenixのマッチングプロセスは、オンチェーンデリバティブプロトコルの発展方向性を反映するだけでなく、DeFiインフラがより複雑な金融市場構造へと進化していることを示しています。
はい。Phoenixは完全オンチェーンオーダーブックアーキテクチャを採用しており、オーダーブックとマッチングロジックの両方がオンチェーンで動作します。
Phoenixは注文の厚み、低スリッページ、プロフェッショナルな取引体験を優先するため、流動性プールモデルではなくオーダーブックモデルを選択しました。
Phoenixは通常、価格・時間優先順位を使用して注文をマッチングします。
いいえ。Phoenixはノンカストディアルプロトコルであり、ユーザーはウォレットを通じて直接資産を管理します。
オラクルは主に参照価格を提供し、システムのリスクコントロールと清算判断を支援します。
PhoenixはSolanaのハイパフォーマンスネットワーク上で動作し、より低いレイテンシとより速い注文確認速度を提供します。





