このページは機械翻訳されています。英語の原文が正式版です。 英語で読む →
メインコンテンツにスキップ

マーケットメイカー保護 (MMP)

マーケットメイカー向けの約定ウィンドウ制限と自動キャンセルの動作について説明します。

ウォレット単位の MMP エンドポイントはすべて EIP-712 認証が必要です。設定の書き込みは、ウォレットの所有者またはそのウォレットの認可済みエージェントが行えます。読み取りは所有者のみ可能で、認可済みエージェントの署名は拒否されます。

MMP は約定を保有するトレーディングアカウントに適用されます。ポートフォリオ証拠金のマネージャーの場合、マネージャーウォレットで署名された読み取りと書き込みは、その Account.sol トレーディングアカウントに解決されます。これは注文発注で使用されるアカウントと同じです。レスポンスでは wallet_address にそのアカウントが返され、MMP の nonce シーケンスもそのアカウントに属します。

書き込み後の読み取り整合性を確保するには、MMP の変更リクエストに X-Hypercall-Fence-Wait: 1 を付けて送信してください。成功したレスポンスには X-Hypercall-Fence が含まれるため、その値を認証付き GET リクエストの X-Hypercall-Fence としてそのまま送り返してください。オプトインの待機ヘッダーを付けない変更リクエストでは、意図的にフェンスは返されません。

概要​

MMP は以下の仕組みで、マーケットメイカーを急激な不利な約定から保護します。

  1. ローリング時間ウィンドウ内の累積約定指標を追跡する
  2. 制限を超過した場合に注文をキャンセルする
  3. 同一のウォレット+原資産について、MMP が有効な他のすべての注文を自動キャンセルする

設定​

MMP 設定の登録​

エンドポイント: POST /mmp-config

リクエスト: SetMmpConfigRequest

{
"wallet": "0x...",
"currency": "BTC",
"interval_ms": 60000,
"frozen_time_ms": 300000,
"qty_limit": "1000000",
"delta_limit": "10.0",
"vega_limit": "5.0",
"nonce": 1,
"signature": "0x..."
}

フィールド:

  • wallet: ウォレットアドレス
  • currency: 原資産の通貨 (例: "BTC"、"ETH")
  • interval_ms: ローリングウィンドウの長さ (ミリ秒)
  • frozen_time_ms: トリガー後の凍結期間 (ミリ秒)
  • qty_limit: 任意の数量制限 (契約単位)。10進数の文字列としてシリアライズされます
  • delta_limit: 任意のデルタ制限。10進数の文字列としてシリアライズされます
  • vega_limit: 任意のベガ制限。10進数の文字列としてシリアライズされます
  • nonce: リプレイ防止用の nonce。認証付き読み取りで返される最新のコミット済み nonce より、ちょうど 1 大きい値である必要があります
  • signature: すべてのリクエストフィールドに対する EIP-712 SetMmpConfig 署名

レスポンス: ApiResponse<MmpConfigData>

MMP 設定の取得​

エンドポイント: GET /mmp-config?wallet=...&currency=...

クエリパラメータ:

  • wallet (必須)
  • currency (任意のフィルター)

必須ヘッダー:

  • X-Hypercall-Expires-At-Ms: ミリ秒単位の Unix 有効期限。現在時刻から 60 秒以内である必要があります
  • X-Hypercall-Signature: wallet、currency (省略時は空文字列)、およびヘッダーの有効期限に対する GetMmpConfig 署名

復元された署名者はウォレットの所有者である必要があります。この読み取りでは認可済みエージェントの署名は受け付けられません。

レスポンス: MmpConfigResponse

{
"success": true,
"data": [
{
"wallet_address": "0x...",
"currency": "BTC",
"interval_ms": 60000,
"frozen_time_ms": 300000,
"qty_limit": "1000000",
"delta_limit": "10.0",
"vega_limit": "5.0",
"enabled": true,
"nonce": 1
}
]
}

MMP 設定の削除​

エンドポイント: DELETE /mmp-config

リクエスト: DeleteMmpConfigRequest

{
"wallet": "0x...",
"currency": "BTC",
"nonce": 1,
"signature": "0x..."
}

レスポンス: ApiResponse<String>。コマンドが成功すると、ウォレット/原資産の数値的なオーソリティ状態が無効化されます。リクエストヘッダー X-Hypercall-Fence-Wait: 1 を付けた場合、レスポンスにはプロジェクションに基づく読み取り用の X-Hypercall-Fence が含まれます。

MMP 状態のリセット​

エンドポイント: POST /mmp-config/reset

リクエスト: ResetMmpRequest

{
"wallet": "0x...",
"currency": "BTC",
"nonce": 1,
"signature": "0x..."
}

レスポンス: ApiResponse<String>。コマンドが成功すると、リプレイ可能なオーソリティ内の MMP 約定ウィンドウと凍結状態がクリアされます。リクエストヘッダー X-Hypercall-Fence-Wait: 1 を付けた場合、レスポンスにはプロジェクションに基づく読み取り用の X-Hypercall-Fence が含まれます。

MMP の動作 (必ず理解してください)​

カウント対象となる約定​

すべての約定は、注文が mmp_enabled=true である各サイドの MMP ウィンドウにカウントされます。その注文が板に置かれていた (メイカー) か、新規に到着した (テイカー) かは問いません。

  • 板に置かれたクオート: 新規注文が、MMP が有効なあなたの板上の注文と約定すると、その約定はあなたのウィンドウに加算されます。これこそが MMP の存在理由です。あなたのクオートに対して約定が集中すると MMP がトリガーされ、その原資産に対する残りの MMP 有効クオートがキャンセルされます。
  • 新規注文: 流動性をテイクする MMP 有効注文も、自身の約定を同様にカウントします。
  • コンボおよびインプライド注文: パッケージの保護対象となる各参加者は、取引したすべてのレッグをカウントします。評価はパッケージごとに 1 回行われます。
  • RFQ および RPI の約定は、現時点では MMP にカウントされません。 ただし、MMP の凍結中は、凍結されたクオート提供者による新規 RFQ の執行はブロックされます。

各約定はあなた自身のサイドから計測されます。コールを売る約定は、売り手のウィンドウには負のデルタを、買い手のウィンドウには正のデルタを加算します。

注文が mmp_enabled=true であるにもかかわらず、そのウォレットに該当原資産の MMP 設定がない場合、MMP はフェイルクローズします。最初の約定でトリガーされ、その原資産に対するそのウォレットの MMP 有効注文がキャンセルされます。注文にフラグを立てる前に MMP を設定してください。

約定処理の順序​

MMP の評価は約定後 (POST-FILL) に行われます:

  1. エンジンがマッチングを行い、まず約定を受け入れます
  2. 次に、MMP が約定の保護対象となる各サイドについて累積指標をチェックします
  3. あるサイドの制限を超過した場合:
    • そのサイドのウォレットと原資産について MMP がトリガーされます
    • エンジンが MmpTriggered イベントを発行します
    • エンジンがそのウォレット+原資産の MMP 有効な未約定注文をすべて自動キャンセルします
    • 超過したサイドが新規注文だった場合、その残数量の執行は停止し、理由 "MMP triggered during fill processing" とともに CANCELED になります
    • 超過したサイドが板上のメイカーだった場合、新規注文は他の流動性とのマッチングを継続します。メイカーの他の MMP 有効クオートはすでにキャンセルされています

影響: MMP がトリガーされる前に、設定したしきい値を超える約定を受ける可能性があります。

トリガー条件​

設定された制限のいずれかを超過すると、MMP がトリガーされます。

  • 数量制限: cumulative_qty > qty_limit
  • デルタ制限: |cumulative_delta| > delta_limit
  • ベガ制限: |cumulative_vega| > vega_limit

累積指標はローリングウィンドウ (interval_ms) 内で計算されます。

キャンセルの動作​

MMP がトリガーされると、以下のようになります。

  1. トリガーした新規注文: 残数量の執行は停止し、注文は理由 "MMP triggered during fill processing" とともに CANCELED になります
  2. トリガーした板上の注文: 約定は有効なままです。注文に残数量がある場合は、他の MMP 有効注文とともにキャンセルされます
  3. その他の注文: 同一のウォレット+原資産の MMP 有効な未約定注文はすべて、理由 "Order canceled by MMP trigger" とともに自動キャンセルされます

注: キャンセルされるのは MMP 有効注文のみです。mmp_enabled=false の注文は影響を受けません。

凍結の動作​

MMP がトリガーされた後:

  • そのウォレットと原資産は frozen_time_ms ミリ秒間凍結されます
  • 凍結中、そのウォレットはその原資産の RPI オークションおよび RFQ から除外され、そのウォレットを約定させるコンボまたはインプライドの執行は拒否されます
  • 凍結中に MMP 有効注文で通常の約定が発生した場合、その約定は有効なままですが、再び MMP がトリガーされ、その原資産に対するそのウォレットの MMP 有効注文がキャンセルされます
  • POST /mmp-config/reset で凍結を早期に解除できます

約定指標の計算​

数量​

  • ソース: 約定の size (契約単位)
  • 累積: ローリングウィンドウ内のすべての約定の合計

デルタ​

  • ソース: 約定シンボルと GreeksCache から計算
  • 累積: ローリングウィンドウ内のすべての約定デルタの合計

ベガ​

  • ソース: 約定シンボルと GreeksCache から計算
  • 累積: ローリングウィンドウ内のすべての約定ベガの合計

ローリングウィンドウ​

ウィンドウからの除外​

interval_ms より古い約定は、ウィンドウから自動的に除外されます。

  • 除外処理は次の約定が処理される際、新しい約定が追加される前に実行されます
  • 古い約定が除外されるにつれて、累積指標が減算されます

ウィンドウのリセット​

POST /mmp-config/reset で MMP 状態をリセットします。

  • ウィンドウ内のすべての約定をクリアします
  • 累積指標をゼロにリセットします
  • 通貨の凍結を解除します

MMP イベント​

MmpTriggered イベント​

内部イベント (現在 WS クライアントには転送されません):

MmpTriggeredMessage {
wallet: WalletAddress,
currency: String,
reason: String, // "MMP triggered during fill processing" | "MMP triggered by a resting order fill"
timestamp: u64,
}

ベストプラクティス​

設定​

  1. 適切な制限を設定する: リスク許容度と典型的な約定サイズに基づいて設定してください
  2. 通貨ごとの設定を使用する: 原資産 (BTC、ETH など) ごとに設定してください
  3. MMP のトリガーを監視する: トリガー頻度が高い場合、制限の設定ミスや不利な市場環境が考えられます

注文管理​

  1. MMP を選択的に有効化する: 保護したい注文にのみ mmp_enabled=true を設定してください
  2. 通貨を統一する: 同一原資産のすべての注文で、MMP 設定と同じ通貨を使用してください
  3. MMP によるキャンセルに対応する: MMP トリガーによるキャンセルを検知し、クオートを調整するロジックを実装してください

監視​

  1. MMP トリガーを追跡する: キャンセル理由 "MMP triggered during fill processing" および "Order canceled by MMP trigger" を監視してください
  2. 約定ウィンドウを確認する: 累積ウィンドウ指標はまだ API で公開されていません。原資産ごとにご自身の約定を追跡してください
  3. 制限を調整する: MMP のトリガーが頻繁すぎる場合は制限を引き上げ、少なすぎる場合は引き下げてください

よくある問題​

MMP のトリガーが頻繁すぎる​

原因:

  • 典型的な約定サイズに対して制限が低すぎる
  • 不利な市場環境
  • 高頻度のクオートにより多数の約定が発生している

解決策:

  • qty_limit、delta_limit、または vega_limit を引き上げる
  • interval_ms を延ばしてウィンドウ内でより多くの約定を許容する
  • クオートの頻度を下げる

MMP がトリガーされない​

原因:

  • 制限が高すぎる
  • 注文で MMP が有効になっていない (mmp_enabled=false)
  • 通貨の不一致 (MMP 設定の通貨 != 注文の原資産)

解決策:

  • 制限を引き下げる
  • 注文で mmp_enabled=true になっていることを確認する
  • MMP 設定の通貨が注文の原資産と一致していることを確認する

予期しないキャンセル​

症状: 予期していないのに、注文が理由 "Order canceled by MMP trigger" でキャンセルされた。

原因: 同一のウォレット+原資産の別の注文が MMP をトリガーした。

解決策: MMP がトリガーされた際は、同一原資産のすべての MMP 有効注文を確認してください。