本文へ移動
ORBITRAONE

Orbitra L1・市場サービスレイヤー

Orbitra L1を市場ネイティブにするレイヤー。

ApexMatchは、Aegis、Prism、クリアリング、決済とともに、Orbitra L1の市場サービスレイヤーに存在します。その上にデプロイされたコントラクトではなく、プロトコル自体の一部です——この性質が、Orbitra L1を市場ネイティブなレイヤー1にしています。

説明図: Orbitra L1を六つの層として重ねた図。最上部に体験層、続いて市場サービス、実行、コンセンサス、データ、そして最下部にネットワーク層が並ぶ。トランザクションが実行・ファイナライズされる際に光が層を下へ伝わり、確定した状態として再び上へ戻っていく。
  1. 01体験Orbitra Prime・ウォレット・アプリ・機関向けAPI
  2. 02市場サービスApexMatch・Aegis・Prism・クリアリング・決済
  3. 03実行VectorLanes・決定論的スケジューラー・NexusWASM
  4. 04コンセンサスQSEクォーラム・ファイナリティ証明・バリデーターポリシー
  5. 05データ状態コミットメント・履歴・インデックスストリーム・証明
  6. 06ネットワーク地域別の受信・暗号化された伝送・可用性メッシュ

レイヤー · 市場サービス

Orbitra L1のスタックにおける役割

注文は、Orbitra Prime、機関向けAPI、ウォレット、アプリケーションという体験レイヤーから、既に署名された状態で到着します。ApexMatchはそれらを順序付けし、同じレイヤー内でAegisPrismを参照し、マッチングし、クリアリングの変動を生成します。

その変動は、別の決済システムに渡されるわけではありません。実行レイヤーがVectorLanes上で実行し、QSEがファイナライズする状態遷移になります。そのため、約定とその決済は、突合を待つ二つの記録ではなく、一つの事象になります。

マッチングがネイティブモジュールであるため、NexusWASM上のコントラクトは、型付きの呼び出しを通じてこれに到達します。ネットワーク上のすべてのアプリケーションは、流動性を別々の複製に分断するのではなく、同じオーダーブックを共有します。

説明図: 署名付き注文は、左から右へ六つの段階を進む。入口、公正な順序付け、Aegisのリスクゲート、価格・時間優先のマッチング、ネットデルタへのクリアリング、QSE証明によるファイナライズである。署名付きの証拠の記録が各段階を記録する。
  1. 01入口署名付き注文
  2. 02順序付け公正な順序
  3. 03リスクAegisゲート
  4. 04マッチング価格・時間優先
  5. 05クリアリングネットデルタ
  6. 06ファイナライズQSE証明
決定論的
同じ入力から、同じ約定、同じ状態が得られる。
アトミック
取引と担保の更新が同時に行われる。
可観測
すべての段階が署名付きの証拠を発行する。
合成可能
アプリはネイティブな市場プリミティブを呼び出せる。

ApexMatchがネットワークに提供するもの

  • 01

    プロトコルサービスとしてのオーダーブック

    中央集中型オーダーブック、RFQ、ブロック取引のワークフローが、同じプリミティブを通じてOrbitra Primeとネットワークアプリケーションに提供されます。

  • 02

    同じレイヤーにあるリスク管理

    Aegisの取引前リスク評価がマッチングと並んで実行されるため、上限に違反する注文は、オーダーブックに到達する前に拒否されます。

  • 03

    手の届く範囲にある参照データ

    Prismの市場状態が、レイヤーの外に出ることなく、各市場の価格帯と一時停止の条件を設定します。

  • 04

    状態遷移としての決済

    クリアリングの変動は、取引所と台帳の間でのバッチ突合を経ることなく、実行とファイナリティへ直接流れ込みます。