🛠️開発記録#269(2025/8/2)高頻度MM戦略のスケールアイデア【Part.2】

高頻度MMbotのスケーリングアイデアを８つまとめました。

高頻度MMの知見は以下の戦略にもシナジーがある。8月は開発をスケールさせていく。
・クロス CEX／DEX arb
・perp‐spot “ベーシス”／Funding arb
・清算スナイプ & 部分清算ループ
・オプション ガンマスキャルピング & ボラMM
・統計アービトラージ（ペア／PCAモデル）
・MEV サンド／バックラン

— よだか(夜鷹/yodaka) (@yodakablog) July 25, 2025

今回の記事で扱うのは以下の４つです。

・オプション Γ（ガンマ）スキャルピング
・Statistical / Pairs Arbitrage
・DEX Concentrated-LP Rebalancing
・MEVプライオリティトレード

暗号資産のデリバティブ領域は日本居住のままで実戦に移そうとなると規制面で引っかかることが多くて煩わしいな。実用上は 「清算先の国籍制限 × FSA のデリバティブ規制」 がボトルネックでDeribit系や Binance系デリバティブはほぼ触れず、CME系やオンチェーン現物 RFQ が現状の選択肢、みたいな。

— よだか(夜鷹/yodaka) (@yodakablog) August 2, 2025

オプション Γ（ガンマ）スキャルピング ― 実装ガイド

目的：Γ > 0（価格変動に対して収益が凸）のポートフォリオを構築し、
underlying が動くたびに 秒〜分足のデルタヘッジ を回して “ガンマを刈り取る”
（＝小さな値動きでも確定利益を積む）

1. 基本概念をおさらい

戦略コア：

1. Γ > 0 を確保（例：ATM オプション買い／ロング straddle/strangle）
2. underlying が ±Δp 動くたびに、Δ をゼロに戻す（現物 or 先物で反対ポジ）
3. 得られた スキャルピング α = Σ(Δhedge * Δp) が Θ を上回れば勝ち

2. システム全体図

graph LR
    P(Price Feed) --> D(Delta-Gamma Engine)
    O(Option Greeks Feed) --> D
    D -->|"hedge order"| R(Route Executor)
    D -->|"quote RFQ"| Q(RFQ Handler)
    R --> E(Exchange Adapter)
    Q --> E
    E --> I(Inventory Manager)
    I --> D
    M(Metrics & Alert) --> D
    M --> I

RFQ Handler は大口ヘッジを Paradigm / 0x で一括決済するときに使用。

3. モジュール詳細

4. Gamma ポジの作り方（３パターン）

Γ_min は資本の 20–30 delta equivalent を目安。

5. Delta-Hedge アルゴリズム

def hedge_loop():
    while True:
        u_px = price_feed.last()
        greeks = option_feed.greeks()        # {'delta':-, 'gamma':-, ...}
        d_err = greeks['delta'] + inv.delta  # net Δ
        if abs(d_err) > cfg.delta_band:
            qty = -d_err / 1      # 1 = Δ per contract for underlying
            route_executor.exec_market(qty)  # or IOC limit
        time.sleep(cfg.hedge_interval_ms/1000)

• delta_band：±0.3 % notional / ±n Δ でトリガ。
• hedge_interval_ms：50–500 ms（板厚次第で可変）。
• 在庫キャップ：|inv.delta| < cap, |inv.gamma| < 1.5×target.

6. IV クラッシュ & 流動性断絶へのガード

νリスク は sell wing options (vega hedge) or long upside call spread で抑える。

7. RFQ 併用フロー

1. size > block_thresh（例：> BTC 10 Δ相当）
2. rfq = {"side":"SELL","inst":"BTC-PERP","qty":Δ_eq} → Paradigm WS
3. best_quote ← 200 ms 集約 → accept → block trade
4. Route Executor で反対 legs を同時に閉じる

ブロック MM で説明した Quote Engine をそのまま流用可。

8. KPI & 監視指標

Slack 通知例：

[GammaBot] ✅ α/Θ = 1.42 | Γ 380 | νPnL +0.004 BTC | Δ 0.02 %
[GammaBot] ⚠️ νPnL -0.002 BTC (<0)

9. PoC 14 日ロードマップ

TL;DR

1. Γ>0 ポジ（ATM straddle など）を構築。
2. 秒〜分足 で Δ が外れたら underlying で即ヘッジ
   → スキャルピング α 獲得。
3. Θコスト + ガス/手数料 + νリスク を常時計測し、
   α/Θ > 1.3 が続く限りロール継続。
4. 流動性不足や大口決済は RFQ で一撃処理。
   モジュールはほぼ MM で使っている dual-leg 発注・在庫キャップ・モニタリング の再利用で済む。
   まずは小資本で PoC を回し、α/Θ と νドローダウン が許容範囲か数字で確認する。

Statistical / Pairs Arbitrage ― 実装ガイド

目的：複数銘柄の過剰乖離を分単位で検知し、平均回帰（Mean-Revert）の瞬間に 両建て で抜く。
基本フロー：

1. ペア発掘（日次） → リアルタイム乖離検知（rolling z-score） → 同時発注（µs-級）
2. ポジ解消：スプレッド 0 回帰 or 時間切れ／ストップに達したらイグジット

1. 全体アーキテクチャ

graph LR
    D(Data Collector) --> F(Feature Store)
    F --> P(Pairs Finder)
    P --> S(Signal Engine)
    FT(Feed Taker) --> S
    S -->|"long / short"| R(Route Executor)
    R --> E(Exchange Adapter)
    E --> I(Inventory Service)
    I --> S
    B(Backtest Engine) --> P
    B --> S
    M(Metrics Alert) --> S
    M --> I

2. データ収集 & Feature Store

3. ペア発掘ロジック（毎日 00:05 UTC）

3-1. PCA ファクタモデル

X = np.stack([log_price[s] for s in universe], axis=1)
X = (X - X.mean(0)) / X.std(0)
pca = PCA(n_components=k).fit(X)
residual = X - pca.inverse_transform(pca.transform(X))
corr = np.corrcoef(residual.T)

• k：説明分散 80–90 %（典型的に 3-4）
• 上位 corr < -0.2（負相関大） or > 0.8 を候補へ。

3-2. 距離メトリクス & Cointegration

• ADF test p-value ≤ 0.05
• Hurst exponent < 0.5
• Mahalanobis distance < thresh → 類似歩調。

自動再計算：全ペア数 nC2 ⇒ n≈50 の universe でも ~ 1 250 ペア。DuckDB + NumPy で 30 s 内に完了。

4. シグナル生成（Signal Engine）

def spread(s1, s2):
    beta = hedge_ratio[s1,s2]          # from linear regression
    return log_price[s1] - beta*log_price[s2]

z = (spread_now - roll_mean) / roll_std
entry = abs(z) > z_entry       # e.g. 2.0
exit  = abs(z) < z_exit or t > max_hold

• 自適応バンド：roll_std は 30 min EWMA、分単位で更新。
• スリッページ調整：edge_adj = z * roll_std - est_slip。edge_adj < 0 なら skip。

5. Route Executor（発注）

1. 同時注文：POST /batchOrders or multi-call SDK
2. 注文種別：IOC / FOK、slippage ≤ 0.05 % wrapped
3. レイテンシ最短化
   • 原資 MM Trader の gRPC 発注パイプを再利用
   • 同一 NUMA→socket pinning → µs 低減

6. Inventory & Risk

ポジションクローズは Inventory Service で一括管理。

7. バックテスト & Online Refit

• Backtest Engine（既存 MM の tick-sim 再利用）
  • 仮想委託 x-ray：fill ルール＝BestBid|Ask ± slip。
  • パフォ指標：Sharpe > 1、Win_rate > 55 %、roll-maxDD < -5 %。
• Walk-Forward：30 d train → 7 d test → 日次リフィット。

8. KPI & Monitoring

9. PoC 14 日ロードマップ

TL;DR

1. 日次：PCA & cointegration で “今日の仲良しペア” を生成。
2. 分単位：z-score が±2σを超えた瞬間、同時両建て → 平均回帰でクローズ。
3. MMの高速発注・在庫管理 をそのまま流用し、Fill レイテンシ < 150 ms を確保。
4. Backtest → Shadow → 小ロット運用で Sharpe > 1、Win_rate > 55 % が続くかを検証して本格投入へ。

DEX Concentrated-LP Rebalancing ― 実装ガイド

目標：Uniswap v3/v4・Pancake v3・Hyperliquid LPD などの CLMM (Concentrated-Liquidity Market Maker) で、
1️⃣ ズレクオート（Dynamic Spread）＋ 2️⃣ 帯幅の自動再配置 を実行し、
手数料 APR を極大化しながら impermanent loss (IL) を最小化する。
新課題は ガス最適化 (L1/L2 差異) と IL 事前シミュレーション。

DEX Concentrated-LP Rebalancing の “そもそも”

仕組みを流れで見る

1. 価格フィード取得
   • CEX や DEX オラクルで現在価格とボラσを 1 s〜1 min 間隔で取得
2. 帯域を決定
   • 例：現在価格P、幅 = k σ (k=1〜1.5)
   • → 下限 P·(1-幅), 上限 P·(1+幅) に mint して流動性を集中
3. 手数料を稼ぐ
   • 価格が帯域内に留まる間、トレードが起こるほど手数料が積み上がる
4. ドrift検知 & 再配置
   • Mid が帯域中心から 20-30 % ずれたら burn → 新帯域へ mint
   • Uniswap v4 Hook や multicall で 1 Tx にまとめガス節約
5. ILモニタ
   • シミュレーションで「手数料 < 予想IL」なら離脱 (一度トークン化)
6. ガス/ROI ガード
   • ガスコスト / 見込み手数料 < 0.2 など閾値を満たすときだけ実行

何が嬉しいの？

抑えておくリスク

1. 急激な価格ジャンプ
   → 再配置が間に合わず IL が跳ね上がる
2. ガス高騰
   → リバランス頻度を落とす / L2 へ逃がす
3. 出来高低下
   → 手数料が稼げず、IL だけ抱える “負けパターン” に
4. スマコン更新（Uniswap v4など）
   → Hook 仕様変更で bot が動かなくなる

まとめ

DEX Concentrated-LP Rebalancing は

板読み MM の「スプレッド調整」と「在庫リバランス」を
そのまま CLMM の「帯幅」と「再配置」に置き換え、
手数料で IL を上回らせる自動 LP 戦略

です。
CLMM の “自分で価格帯を決められる” 性質を活かし、常に市場の中心に流動性を集中させることで
薄利 MM より高 APR を狙いつつ、ボラが大きく動けば即帯域を移動して損失を限定します。

1. システム全体

graph LR
    P(Price Feed) --> B(Band Manager)
    V(VOL & Skew Feed) --> B
    G(Gas Oracle) --> X(Tx Router)
    B -->|"mint / burn bands"| X
    D(Data Lake) --> S(IL Simulator)
    B --> S
    X --> A(DEX Adapter)
    A --> I(Inventory & Fees)
    I --> B
    M(Metrics & Alert) --> B
    M --> I

2. モジュール詳細

3. バンド設計アルゴリズム

def compute_band(mid, vol, skew, cfg):
    # 1. width from vol  (1σ ≈ vol * sqrt(dt))
    width = cfg.k_sigma * vol * math.sqrt(cfg.dt)
    # 2. dynamic skew adjustment (buy/sell pressure)
    shift = cfg.skew_coef * skew          # skew ∈ [-1,1]
    lower = mid * (1 - width) * (1 - shift)
    upper = mid * (1 + width) * (1 + shift)
    return round_tick(lower), round_tick(upper)

MM の dynamic spread パラメータを width に写像しているだけ。

4. 自動 Rebalance フロー

Uniswap v4 の Hooks を使えば burn+mint+fee-claim を 単一 Tx にまとめられ、
ガス削減 & MEV 保護が可能 Medium。

5. ガス最適化 (L1 vs L2)

実践指針：L1 では 4 h 毎、L2 では 1 h 毎 のリバランスが一般的。

6. Impermanent-Loss (IL) シミュレーション

1. インパーマネント・ロス（IL）の準閉式準閉式：IL(r) = (2 * sqrt(r) / (1 + r)) - 1
   ・r はポジションを組んだ価格 P₀ に対する、現在価格 Pₜ の比率 r = Pₜ / P₀
   ・sqrt(r) は r の平方根です
   ・返り値は負の値（＝損失）になる。手数料収入が IL を上回れば総合計でプラスになる見込み。
   cointracker.io
   
2. Monte-Carlo：
   • Generate GBM paths with σ=vol over horizon T.
   • For each path compute IL & fee income.
   • Decide k_sigma such that E[fee] - E[IL] > roi_target.
3. Hook-based off-chain preview (Uniswap v4):
   • simulate() returns fee + IL vs gas before broadcasting.

7. リスク & ガードレール

8. KPI

Slack 通知例：

[CL-LP] ✅ APR 24.3 % | In-range 83 % | IL/Fee 0.55 | Gas/Fee 0.18
[CL-LP] ⚠️ Gas spike 220 gwei, rebalances paused

9. PoC 14日ロードマップ

TL;DR

1. Dynamic Spread → Band Width に単純マッピングし、mid±kσ のレンジで LP。
2. Price drift > tol ごとに burn→mint をワンショット Tx（Uniswap v4 Hook or multicall）。
3. リバランス前に IL シミュレーション＋Gas / Fee ロジック を回し、
   Expected Fee – (IL + Gas) がプラスのみ実行。
4. L1 は 4 h 周期／L2 は 1 h 周期が目安。
   まずは L2 テストネットで Shadow → 小口 live。
   Fee APR > 20 % & IL/Fee ≤ 0.6 を 2 週間キープできれば本格投入へ。

MEVプライオリティトレード― 実装ガイド

— “μs級オーダーループ” を EVM Tx + Private Bundle に置き換え、サンドイッチ／バックランで α を取る —

「MEV プライオリティトレード」とは？

ざっくり言えば 「“並べ替え権” をお金で奪い合う短期トレード手法」 が MEV プライオリティトレードです。

どんな種類がある？

これらはすべて 「順番さえ取れれば無リスク or 超低リスク」 なので、
bot 同士が PGA（ガス吊り上げ戦） に陥りやすい仕組みです Collective Shift。

仕組み：何を“買って”いるのか？

1. 公開メンプール (lit route) で
   ガス価格 -→ max gas ≒ 期待α まで入札競争。
2. プライベートバンドル (dark route) で
   ビルダーへ ブロック内挿入順位 を“賄賂”付き発注。
   • Flashbots Relay / Titan / bloXroute などを利用 Flashbots Docs。
3. Validator/Bundler がより高い贈与 (priority fee) を優先し、
   順番権を落札した bot が α（裁定利益） − 手数料 を獲得。

どうして“μs級 HFT ロジック”が効くのか？

• 取引探索：メンプールから平均 10 ms 以内 に価格インパクトを推測
• バンドル生成：50 ms 未満で gas, nonce, access list を計算
• 送信：ローカルノード IPC → Builder Relay へ TCP keep-alive
  → ブロック締切まで 100–200 ms の余裕を確保

この速度要件は、あなたが既に使っている HFT-MM の μs級オーダーループ と共通で、
“REST 注文 → EVM Raw tx” に置換するだけで PoC が動きます。

価値だけでなくリスクも“大”

まとめ

• MEV＝「ブロック内並べ替えで抜ける追加価値」
• プライオリティトレード＝「その価値を取る順番権を買う競り」
• 主な手口は Front / Back / Sandwich / PGA / 清算 / JIT など、
  すべて “取引順序 × μs レイテンシ” が勝敗を分けます。
• 技術は 既存 HFT-MM の高速オーダーループ＋ガス入札ロジック の組み合わせで流用可能。
• ただし 規制・倫理ライン が曖昧な領域も多く、
  ToS と法規制を踏まえた撤退基準 をコードに埋め込むのが実運用の鍵。

1. 戦略概要

コアは order-flow 予測 × レイテンシ競争。既存 MM の µs ループを「pendingTxストリーム → Bundle送信」に差し替えれば PoC が動くようになる。

2. システム構成

graph LR
    M(Mempool Sniffer) --> C(Classifier)
    S(MEV-Share / Private OF Stream) --> C
    C -->|"victim tx & trade plan"| B(Bundle Builder)
    G(Gas Oracle) --> B
    B -->|"bundle"| R(Builder Relay)
    R --> N(Local Node RPC)
    N --> P(PnL Tracker)
    P --> A(Alert)
    E(Ethics Guard) --> C
    E --> B

• Mempool Sniffer：geth/parity RPC の txpool.content + p2p gossip
• MEV-Share：Flashbots private order-flowイベント Flashbots Docs
• Builder Relay：https://relay.flashbots.net など Flashbots Docs
• Ethics Guard：規制・ToSフィルタ（後述）

3. オーダーフロー予測

並列化：Rust or C++ で tx feed → lock-free queue。
レイテンシ目標：< 25 ms でバンドル構築。

4. Bundle Builder & Gasマネジメント

bundle = [
  my_front_tx,   # sandwichの場合
  victim_tx,     # 要同一nonce除外
  my_back_tx
]

bundle_params = {
  "txs": [tx.raw for tx in bundle],
  "block": current_block + 1,
  "minTimestamp": now,
  "maxTimestamp": now + 1200,   # 20 min
  "revertingTxHashes": []       # front/backが失敗したらbundle反転
}
relay.send_bundle(bundle_params)

• gas_limit：simulate() → +10 %。
• priority_fee：tip_coef * sqrt(pending_tx) 動的計算。
• baseFee上限：eth_feeHistory → 95%tile 超なら skip。

失敗 Tx は Bundle Cache API で即再利用 Flashbots Docs。

5. レイテンシ最適化 Tips

6. Ethics & Regulation Checklist

Ethics Guard コンポーネントで Txごとに K/KYC リスト & ToS 非遵守チェック → NGなら skip。

「“sandwich（＝front-running）の禁止条項」が明記されている代表的な DEX ToS 例

ポイント

• “サンドイッチ攻撃” は法的には front-running の一形態なので、ToS では front-running tool / market-manipulation の一括禁止でカバーされるケースが多い。
• CoW Swap や 1inch Fusion など “MEV-resistant” を謳う UI は ToS で明確に攻撃を禁じる一方、Uniswap v3/v4 のように 禁止を明文化していない UI もある（代わりに MEV FAQ でリスクを啓蒙）。

どう読み替えればよいか

1. ToS で front-running が禁止 ⇒ サンドイッチも不可
   • bot 実装者側はインターフェースを迂回（オンチェーン直接呼び出し）しても、規約違反リスクを完全に排除できるとは限らない。
2. ToS に禁止記載がない ⇒ “黙認” ではなく自己責任
   • コントラクト自体は permissionless でも、UI／ブランド側の利用規約違反で API Key BAN 例もある。

実運用では 「利用 UI の ToS＋各国規制」 を二重に確認し、リスク低減のために

• Private Tx Relay（Flashbots Protect / MEV-Share）
• Intent-based DEX（CoW Swap など）
  を併用するのが無難。

7. PnL & KPI

PnL Tracker が Flashbots/Relay receipts + eth_getTransactionReceipt でガス・報酬を集計。

8. PoC 14 日ロードマップ

TL;DR

1. Mempool + MEV-Share で order-flow を先読みし、
2. 25 ms 以内に private bundle を組んで Relay へ送信、
3. Gas / BaseFee / Ethics Guard を通過したものだけ実行、
4. KPI が hit≥40 %、α/gas≥1.5、規制違反0 を維持できなければ自動撤退。

既存 MM の µsオーダーループ を EVM bundle に差し替えるだけで PoC は作れる。
ただし 規制・道義的ライン を事前に文書化し、“やめ時” を自動化してから本格運用へ移行する必要あり。

付録：MEV プライオリティトレードの体系図

軸 ❶：取りに行く価値 (Value)
軸 ❷：抽出手段 (How it is extracted)
軸 ❸：ブロック内での位置関係 (tx ordering)

下表は研究・Flashbots 文献で頻出の分類を三軸で整理し、「優先ガス競争＝Priority Trade」 に該当するものを網羅しています。

位置づけ早見

flowchart TD
    %% ───── Nodes ─────
    VD[Value-Diverting]
    ORD["Ordering Only\n(Sand / Front / Back)"]
    PGA[PGA]
    VDC["Value-Diverting &\nValue-Creating\n(Arb, Liq, JIT)"]
    SCM[State-Change MEV]

    %% ───── Edges ─────
    VD  --> ORD
    VD  --> PGA
    ORD --> PGA
    PGA --> VDC
    VDC --> SCM

各カテゴリの “Priority Trade” 共通要件

倫理・規制フレームと紐付け

実装ロードマップへの落とし込み例

1. フェーズ0: DEXアービトラージ／Liquidation（低グレー度）から実装
2. フェーズ1: Back-run＋JIT流動性 → Private order-flow優先
3. フェーズ2: Sandbox環境で Front/Sandwich を実験、Ethics Guard と撤退ラインを自動化

参照した主なソース

• Flashbots Research “MEV Transaction Taxonomy” (2024) arXiv
• 1inch・Sushi ToS の front-running禁止条項例 SpringerLink
• BitQuery / CoW Docs MEV attack explanations (front/back/sandwich) Bitquerycow.fi
• Cross-chain MEV (front-run in atomic swaps) 新規論文 2025-06 ResearchGate