<< All versions

Skill v1.0.0

currentLLM-judged scan90/100
79yuuki/dotfiles/market-microstructure-execution
──Details
PublishedOctober 24, 2026 at 06:02 AM
Content Hashsha256:cac9ad3caac27293...
Git SHA387673d7edae
──Files
Files (1 file, 4.3 KB)
SKILL.md4.3 KBactive
SKILL.md · 94 lines · 4.3 KB

version: "1.0.0" name: market-microstructure-execution description: トレードbotの注文執行、板情報、スプレッド、スリッページ、約定可能性、CEX/DEXアービトラージ、マーケットメイク、funding rate、オーダーフロー、レイテンシを設計・検証する時に使う。


Market Microstructure Execution

裁定や短期戦略は「価格差を取って引き算する」だけでは動かない。実運用で重要なのは、見えている価格で約定できるか、どの順序で注文するか、失敗時にどう逃げるか。

まず分類する

  • Directional: シグナルに従って片側売買する
  • Arbitrage: 複数市場/商品間の価格差を取る
  • Market making: maker 注文と在庫管理で収益化する
  • Funding/carry: funding、金利、貸借、先物ベーシスを取る
  • DEX/MEV-sensitive: ガス、ブロック、RPC、MEV の影響が大きい

分類により、必要なデータ粒度と失敗時のヘッジが変わる。

執行設計

  1. 市場データの鮮度を測る
  • 取引所ごとの受信時刻、イベント時刻、ローカル時刻を分ける
  • 板と約定履歴の遅延、欠落、順序入れ替わりを検知する
  • アービトラージでは比較対象の時刻差を明示する
  1. 約定可能価格で評価する
  • mid price ではなく bid/ask、板厚、想定発注量で損益を計算する
  • スプレッド、手数料、funding、借入、ガス代、送金コストを入れる
  • 部分約定と片側約定の損失を見積もる
  1. 注文方式を戦略ごとに選ぶ
  • maker/taker、指値/成行、post-only、IOC/FOK、トレーリングを使い分ける
  • マーケットメイクでは在庫、逆選択、ティックサイズ、板の透明性を監視する
  • DEX ではMEV、サンドイッチ、ガス、ブロック確定、RPC遅延を別リスクにする
  1. 失敗時の状態遷移を設計する
  • 片側だけ約定した時のヘッジ
  • 注文キャンセル失敗時の再照会
  • WebSocket断、REST制限、取引所メンテ時の縮退
  • ポジションと注文の再同期
  1. 本番監視に接続する
  • latency、spread、fill ratio、cancel reject、order age をメトリクス化する
  • 閾値超過時はサイズ縮小または取引停止する
  • trading-ai-agent-ops の監視ログに渡せる形式にする

バックテストに入れるもの

  • bid/ask スプレッド
  • 板厚に応じた価格インパクト
  • taker/maker 手数料とリベート
  • 注文遅延、キャンセル遅延、約定失敗
  • funding rate と清算コスト
  • ガス代、ブリッジ、送金待ちが必要な戦略ならその時間リスク

出力テンプレート

markdown
## Execution Model
-Strategy class:
-Data freshness threshold:
-Price used for PnL:
-Order types:
-Expected costs:
-Failure states:
## Runtime Metrics
| Metric | Threshold | Action |
|---|---|---|
| market_data_lag_ms | | |
| spread_bps | | |
| fill_ratio | | |
| order_age_ms | | |
| position_mismatch | | |

実装レビューの質問

  • PnL は mid ではなく実際に取れる価格で計算しているか
  • データ時刻差が閾値を超えたら取引を止めるか
  • 最小利益幅はコストと片側約定リスクを超えているか
  • 約定しなかった注文が残り続けないか
  • API障害後に、ローカル状態と取引所状態を照合しているか
  • paper と live で注文状態遷移が同じコードを通るか

Transparent order-flow venues

  • Hyperliquid など透明な order flow を持つ venue では、短期情報量が market maker に有利に働く一方、大口/遅い参加者には adverse selection が増える。
  • 透明性を「流動性が良い」とだけ評価しない。flow visibility、front-run/MEV risk、latency、fee、privacy、custody/security を同時に見る。
  • 大口執行では、公開 flow と秘匿化/ミキシング/OTC/分割発注のトレードオフを明示する。秘匿化サービスは単一口座集約や custody risk を別途レビューする。
  • DEX/CEX比較では、手数料だけでなく「どの情報が誰にいつ見えるか」を Execution Model に含める。
All versions