Orbitra Prime
取引インテリジェンス
ワンクリックのマーケット注文からRFQブロックまで、Orbitra Primeのすべての注文チケットは、ApexMatchのプリミティブへと帰着し、すべての利用者に対して同じ執行証拠が提供されます。
ApexMatchOrbitra L1
決定論的ネイティブマッチングエンジン
取引所カーネルは、プロトコルの内部に存在する。
ApexMatchは、チェーン上にデプロイされたアプリケーションではありません。Orbitra L1のネイティブな市場モジュールです。マッチング、注文取消、ファンディング、証拠金の変動、決済証明が、一つのアトミックな状態遷移を共有します。同じ入力、同じ約定、同じ状態です。
動作の流れ
署名済みの注文を、端から端まで追う
- 01入口署名付き注文
- 02順序付け公正な順序
- 03リスクAegisゲート
- 04マッチング価格・時間優先
- 05クリアリングネットデルタ
- 06ファイナライズQSE証明
- 決定論的
- 同じ入力から、同じ約定、同じ状態が得られる。
- アトミック
- 取引と担保の更新が同時に行われる。
- 可観測
- すべての段階が署名付きの証拠を発行する。
- 合成可能
- アプリはネイティブな市場プリミティブを呼び出せる。
この図は、一つの署名済みの注文が、受付、公正な順序付け、Aegisのリスクゲート、価格・時間優先のマッチング、クリアリングを経て、QSEの証明書によってファイナルとなるまでを追います。各段階は署名付きの証拠を生成し、経路の下にトレースとして表示されます。
解決する課題
マッチングエンジンがプロトコルの内部へ移った理由
多くの取引所は、マッチングを一つのシステムで行い、決済を別のシステムで行っています。注文はアプリケーションが受け付け、非公開のエンジンでマッチングされ、その後カストディや台帳と突合されます。これらのシステム間のやり取り一つひとつが、状態が分岐しうる場所であり、順序が操作されうる場所であり、約定を裏付ける担保が動く前に約定そのものが存在してしまう場所です。
汎用チェーン上にマッチング用のコントラクトをデプロイするオンチェーンの取引所は、別の問題を抱えます。そのチェーンはそもそもオーダーブックのために作られていません。ブロックスペースは無関係な活動と競合し、順序は手数料のオークションによって形づくられ、すべての取引がネットワークとの間で実行時間を奪い合います。
ApexMatchは、この二つの隙間をともに取り除きます。このエンジンは決定論的なプロトコルモジュールであるため、約定、その証拠金への影響、そして決済は、一つの不可分な事象となります——観察可能で、再現可能で、QSEのもとでファイナルです。
処理の順序
六つの段階。一つのアトミックな状態遷移。
手動、アルゴリズム、Cortexエージェントによる発注のいずれであっても、すべての注文はカーネル内で同じ経路をたどります。
- 01
受付
注文は、上限が付随した署名済みのインテントとして、地域別ゲートウェイを通じて到着します。署名は、順序付けの前にバッチ単位で検証されます。
- 02
順序付け
公正な順序付けが、正規の順位を割り当てます。順序は手数料の競り上げではなく、あらかじめ定められたルールに従うため、待ち行列を買い取ることはできません。
- 03
リスク
Aegisの取引前リスク評価が、取引後のポートフォリオ——証拠金、清算距離、ポリシー上の上限——をシミュレートします。上限に違反する注文は、オーダーブックに触れる前に拒否されます。
- 04
マッチング
ApexBook上での価格・時間優先です。自己取引防止、ポストオンリー、リデュースオンリーの各仕様は、カーネル自体によって強制されます。
- 05
クリアリング
約定は、ポジション、担保、手数料、ファンディングという純変動を生み出し、マッチングと同じ状態遷移の内部で計算されます。
- 06
ファイナライズ
VectorLanesがその状態遷移を実行し、QSEのクォーラム証明書がそれをファイナライズします。約定、その証拠金への影響、決済証明がともにファイナルになります。
構造
カーネルの構成要素
ApexMatchは、明示的なインターフェースを持つ小さな決定論的部品から構成されています。それぞれを個別に観察し、テストし、再現できます。
- 01
地域別の受付
市場参加者の近くに配置されたゲートウェイが、署名済みの注文を受け付け、署名をバッチ単位で検証し、受信タイムスタンプとともに転送します。
- 02
シーケンサー
定められた順序付けポリシーを適用し、すべてのバリデーターが同一に再現する正規の入力ストリームを生成します。
- 03
Aegisゲート
アカウントのポートフォリオ・リスクグラフとポリシー群に対して注文を評価する、Aegisへの同期的な呼び出しです。
- 04
ApexBook
価格・時間優先、自己取引防止を備え、RFQとブロック取引のワークフローをネイティブにサポートする中央集中型オーダーブックです。
- 05
クリアリングエンジン
すべての約定について、ポジション、担保、手数料、ファンディングの変動を計算し、同じ状態遷移の中に書き込みます。
- 06
証拠ストリーム
各段階が、レシート、順位、リスク判定、約定、変動という署名付きの記録を生成するため、どの約定も独立して再構築できます。
セキュリティと障害制御
セキュリティと障害制御
マッチングエンジンは、安全に機能停止しなければなりません。ApexMatchは、一つの段階の不具合が、システムの他の部分が認識しない約定を生み出さないように構築されています。
- アトミック性取引とその担保の更新は、共にコミットされるか、まったくコミットされないかのいずれかです。約定がその証拠金への影響を伴わずに存在する時間帯は存在しません。
- 決定論的な再現バリデーターは同じ順序付けされた入力を再現し、同じ状態ルートを生成しなければなりません。不一致は吸収されるのではなく検知されます。
- 取引前の拒否証拠金、レバレッジ、ポリシー上の上限に違反する注文は、事後に清算されるのではなく、Aegisゲートで拒否されます。
- 市場のサーキットブレーカー市場ごとの価格帯、ボラティリティによる一時停止、Prismの信頼度のしきい値が、参照データの信頼性が低下した際にマッチングを停止させます。
- 注文フローの完全性公正な順序付けのルールはプロトコル仕様の一部であるため、順序を買い取ることも、運営者が並べ替えることもできません。
三つのシステムの連携
ApexMatchが三つのシステムをつなぐ仕組み
Orbitra L1
決済と計算
ApexMatchは、Orbitra L1のネイティブな市場サービスモジュールです。VectorLanes上で実行され、その状態遷移はQSEによってファイナライズされます。
Orbitra Realm
アプリと商取引
Orbitra Realmのアプリケーションは、NexusWASMコントラクトから、ネイティブな市場プリミティブを直接呼び出せます。そのため、ウォレット、ゲーム、財務管理ツールは、取引所を自ら構築せずに、本物のオーダーブックを提供できます。
価値
何が変わるか
- トレーダーと利用者
- 透明で再現可能な約定です。自分の注文が待ち行列のどこにあったか、なぜ受け付けられたか、いつファイナルになったかを確認できます。
- 機関
- モデル化、再現、監査が可能な決定論的な振る舞いです。ドロップコピー、TCA、突合処理は、エンジンと同じ証拠ストリームを参照します。
- 開発者
- オーダーブック、RFQ、クリアリングの変動といった、組み合わせ可能な市場プリミティブを、取引所を再実装することなくコントラクトから利用できます。
仕様
仕様
- マッチングモデル
- 中央集中型オーダーブック、価格・時間優先
- 決定論的性質
- 同一の順序付けされた入力は、すべてのバリデーターで同一の約定と状態ルートを生む
- 取引前の制御
- すべての注文に対する同期的なAegis評価
- 決済
- マッチングとアトミックに実行され、QSEのクォーラム証明書のもとでファイナル
- 注文の仕様
- マーケット、リミット、ストップ、ストップリミット、ポストオンリー、リデュースオンリーをネイティブに提供。高度な注文とアルゴリズム注文はこれらのプリミティブを組み合わせて構成
- 保護機能
- 自己取引防止、価格帯、ボラティリティによる一時停止、オラクル信頼度による停止
- 証拠
- すべての注文について、署名付きのレシート、順位、リスク判定、約定、変動
- インターフェース
- ネイティブAPI、FIXゲートウェイ、NexusSDKの市場プリミティブ
用語
用語
- 公正な順序付け
- 各注文に対して、支払った手数料と無関係に正規の順位を割り当てる、プロトコルが定めるルール。
- 価格・時間優先
- より良い価格の注文が先にマッチングされ、価格が同じ場合は先に出された注文が先にマッチングされる原則。
- クリアリングデルタ
- 一件の約定によって生じる、ポジション、担保、手数料、ファンディングの純変動。
- クォーラム証明書
- QSEのもとで状態遷移をファイナルにする、バリデーターの署名を集約した証明書。
- 自己取引防止
- アカウントが自らの未執行の注文と約定してしまうことを防ぐルール。