#grvt GRVT の公式ドキュメントを読んでいて、最も立ち止まってよく見てしまったのは、その Risk Engine のアーキテクチャです。ほとんどのデリバティブ契約のリスクエンジンは、清算ロジックと価格オラクルを組み合わせたものですが、GRVT はそれを3つの層に分けています：Pre-trade Risk Check、Position Monitoring、Settlement Validation。この3層は直列ではなく、それぞれ独立して動作しており、どの層でも問題を検知すると、対応するリスク管理アクションがトリガーされます。

Pre-trade Risk Check は、注文がマッチングされる前に発生します。建玉の注文を出すと、Risk Engine はまず Unified Balance が初期証拠金を十分にカバーできるか、名目価値が口座階層の上限を超えていないか、さらにその取引ペアの現在のポジション集中度が過度ではないかを検証します。どれか一つでも条件を満たさない場合、注文は直接拒否され、マッチングキューには入りません。テストネットで口座の名目価値上限を超える建玉を試したところ、清算まで待たずに、提出段階でシステムが遮断していました。

Position Monitoring はリアルタイムで動作し、各口座の維持証拠金率とレバレッジ倍率を追跡します。GRVT の清算トリガーは単一の価格ラインではなく、マーク価格とオラクル価格を加重した値を組み合わせ、単一点のオラクルの揺らぎによる誤清算を防ぎます。ドキュメントでは、Pyth と Chainlink の二系統の価格フィードを使い、加重中央値を取るとされています。乖離が閾値を超えると価格の相違チェックがトリガーされ、価格が一致するまで関連する取引ペアの清算が一時停止されます。

Settlement Validation は取引の最終的な決済の際に行われ、オンチェーンの状態とオフチェーンのマッチングエンジン記録が一致しているかを検証します。差異が見つかった場合、システムは Reconciliation（照合）プロセスを起動し、差異が解消されるまで関連口座を凍結します。この仕組みはデリバティブ契約では一般的ではなく、主に従来の金融の清算所で見られるものです。

3層の検証の利点は、リスクを複数の入口で遮断できることであり、清算ラインに到達してから処理するのではありません。代償として、各層に遅延と計算コストが追加されます。GRVT のドキュメントでは、Pre-trade Check の目標は 10 ミリ秒以内、Position Monitoring はリアルタイムのストリーミング計算、Settlement Validation は非同期のバッチ処理だと書かれています。
私は個人的には、メインネット稼働後にこれらのSLAが守られるなら、この3層のリスク管理アーキテクチャはデリバティブ契約の文脈ではかなり堅実だと思います。@grvt_io