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

高頻度MMbotの開発で得た知見をスケールさせるためのbotアイデアを８つまとめました。

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

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

今回の記事では以下の4つの拡張戦略と実装プランを扱います。

・クロス CEX／DEX アービトラージ
・RFQ／ブロック向けマーケットメイク
・Perp-Spot ベーシス & Funding アービトラージ
・清算スナイピング

クロス CEX／DEX アービトラージ ― 実装ガイド

ゴール：板読み MM で培った “サブ秒レイテンシ・在庫制御” をそのまま流用し、
価格差 ≧ （取引手数料 + ガス + 出金手数料） を検知した瞬間に 同時約定 で抜く PoC を２ 週間で構築する

1. 全体アーキテクチャ

┌──────────────────────────────┐
│  Liquidity Snapshot Service  │  ← WebSocket / REST
└───────────────▲──────────────┘
                │ best_bid / best_ask / depth
┌───────────────┴──────────────┐
│ Dynamic Edge Calculator      │  ← 手数料・ガス・Withdraw 推定
└───────────────▲──────────────┘
                │ edge ≥ 0 ?
┌───────────────┴──────────────┐
│ Order-Router / Tx Coordinator│  ← atomic swap or risk-skew
└───────────────▲──────────────┘
                │ fills / rejects
┌───────────────┴──────────────┐
│ Inventory / Risk Engine      │  ← hot-wallet balances
└──────────────────────────────┘

• Liquidity Snapshot
  • 既存 MM の order-book collector を拡張：複数 CEX REST+WebSocket、複数 DEX SDK (e.g. 0x, Uniswap routers)。
• Edge Calculator
  • edge = (sell_px – buy_px) – fees_buy – fees_sell – gas_est – withdraw_est wundertrading.com
• Order-Router
  • “双方向同時発注” が基本。片側 fill 失敗時は ヘッジ成行 でポジを閉じる。
• Inventory Engine
  • Hot-wallet = 倉庫 と割り切り、exchange1_qty – exchange2_qty = net_delta を常に 0±ε に維持。
• Monitoring / Slack
  • 未約定建付が 3 s > 0 の場合は circuit_breaker を発動しペアをクールダウン。

2. 優先タスクの詳細

2-1. “hot wallet ≈ ポジション” 在庫モデル

2-2. 動的エッジ計算器

def calc_edge(pair, buy_ex, sell_ex, qty):
    buy_fee   = fee_table[buy_ex](qty)
    sell_fee  = fee_table[sell_ex](qty)
    gas_cost  = gas_oracle.estimate(tx_size(pair, qty))   # DEX only
    wd_cost   = withdraw_cost[buy_ex][pair.base]          # CEX→CEX用
    edge      = sell_px - buy_px - buy_fee - sell_fee - gas_cost - wd_cost
    return edge

• fee_table：Maker/Taker, VIPティア, リベートまで動的計算 Medium
• gas_oracle：EIP-1559 (baseFee × 1.1 + tip) を RPC から取得 HyroTrader
• withdraw_cost：API or Parse HTML → 1 h毎にキャッシュ（変動が遅いため）

閾値：edge >= min_profit_pct * buy_px でトリガ。 min_profit_pct は 0.15–0.30 % が現実的。

3. Order-Router / Tx Coordinator

4. 既存 MM モジュールへの差し込みポイント

5. PoC ロードマップ（2 週間）

6. リスクと拡張

次段階の拡張

• Flash-loan or CEX 借入 でレバレッジ → エッジ薄でも ROI↑。
• オフチェーン solver（e.g. Cow-Protocol）接続で MEV 抑制。
• Edge Score Engine を組み、MMBot と資本を自動シフト。

一言まとめ

板読みMMの “速さ” と “在庫制御” を横展開し、
サブ秒の価格乖離をスキャン → エッジ計算 → 同時発注 → 在庫ゼロ化 のループを作る。
これが動けば 手数料＋ガスを払っても“確定利益” を量産できる ― まずは最小ロットで PoC を回し、Fill率と損益を数値で検証する。

RFQ／ブロック向けマーケットメイク ― 実装ガイド

狙い：板外で飛んでくる Request-For-Quote を瞬時に値付けし、大口取引を 確実・手数料効率的 に成約させる。
コア資産：既存MMの ①高速価格計算 ②在庫スキュー制御 ③発注エンジン を再利用。

1. 対象ネットワークの整理

※PoCなら Paradigm (デリバティブ) と 0x (オンチェーン現物) の 2本立てで十分幅広い検証が可能。

日本居住の個人でも実行可能か？

結論だけ先に

• Paradigm 自体は「日本在住＝即 NG」ではない。制裁対象国・US/CA 個人などが“Restricted Jurisdictions／Persons”に列挙されているが、日本は該当しない paradigm.co。
• ただし
  1. 機関投資家／適格投資家向け（法人・プロ向け KYC が必須）
  2. クリアリング先（Deribit など）が日本居住を禁止している場合、そのプロダクトは利用不可 ─ Paradigm は「清算先の国籍制限をそのまま継承する」と明言 paradigm.co。
  3. 日本の金融商品取引法・改正資金決済法により、個人が海外暗号資産デリバティブを扱うこと自体がグレー／NG のケースが多い（FSA の認可を受けた業者経由でないと基本的に禁止）。

1. Paradigm のオンボーディング要件

2. 清算先ごとの実際の可否

実用上は 「清算先の国籍制限 × FSA のデリバティブ規制」 がボトルネックです。
Deribit系や Bybit系デリバティブはほぼ触れず、CME系やオンチェーン現物 RFQ が現状の選択肢。

3. 日本居住者が実際に使うまでのステップ

1. 法人（または個人事業主）名義で Paradigm KYC
   • 登記簿・代表者パスポート・主要株主リストを提出。
2. 対象プロダクトのクリアリング要件を確認
   • 例：CME ClearPort なら国内 FCM（ABNアムロ東京支店など）との取引関係が必要。
3. FSA への自己確認
   • 商品デリバティブ扱いになる場合、「第一種金融商品取引業」登録がないと自己売買不可。実質は 「プロップは不可・投資運用業が必要」。
4. 税務 & 会計処理
   • 裁定収益は雑所得（個人） or 法人所得。オンチェーン RFQ で得た手数料も課税対象。
5. オンチェーン清算の場合のガス管理
   • ETH/GAS をホットウォレットに常時補充。
6. コンプラ体制
   • 反社チェック、疑わしい取引報告（STR）フローを準備。Paradigm から定期的にデューデリが来る。

4. まとめ & 実務アドバイス

• 規約上は日本は“許容国” ⇒ Paradigm の申請フォームに存在し、Restricted リスト外。
• 実戦では
  • 日本 FSA の 個人向け海外デリバティブ規制
  • 清算先（Deribit 等）の 自主規制で日本禁止
    が二重で効くため、使えるのは CME系 + オンチェーン現物RFQ 程度。
• 法人格 & プロ投資家ステータス があれば、Paradigm＋CME でブロック取引を行う余地はあり。
• 最終的には Paradigm オンボーディング担当と日本の外為法・金商法専門の弁護士へ確認 するのが安全（本回答は法律アドバイスではありません）。

2. システム構成

graph LR
    A(RFQ Gateway) -->|"RFQ JSON"| Q[Quote Engine]
    Q -->|"price size ttl"| G[Quote Signer]
    G -->|"signed quote"| A
    A -->|"fill or expire"| S(Settlement Orchestrator)
    S --> E[Exchange and Chain Adapter]
    E --> I[Inventory and Risk Service]
    I -->|"inventory skew"| Q
    M[Metrics and Alert] --> I
    M --> Q

3. Quote Engineのロジック

def build_quote(rfq: RFQ, inv: Inventory, cfg):
    mid = price_feed.mid(rfq.symbol, rfq.size)
    skew = cfg.inv_skew_coef * inv.net_delta(rfq.symbol)
    risk_margin = cfg.base_margin + cfg.vol_curve(rfq.size)
    price = mid + skew + rfq.side.sign * risk_margin
    ttl = min(cfg.max_ttl_ms, rfq.request_ttl_ms)
    return Quote(price=round_price(price, cfg.tick), size=rfq.size, ttl=ttl)

• inventory_skew_coef：在庫が+Δなら売り値を下げ／買い値を上げて自然ヘッジ。
• vol_curve：サイズ依存のマージン（例：risk_margin = k * sqrt(size)）。
• 価格算出から署名返信まで < 150 ms を目標。

4. ネットワーク別実装ポイント

5. Inventory “hot-wallet” モデル

1. ウォレット＝ポジション
   • inv[custodian][asset] = on_exchange_balance().
   • RFQ提示サイズは avail_balance – safety_buffer 以内に制限。
2. Rebalance Job
   • |net_delta| > rebalance_threshold なら
     withdraw(exchangeA) → deposit(exchangeB) を自動スケジュール。
   • 出金手数料も Quote Engine の risk_margin に反映。
3. Circuit Breaker
   • 在庫偏り > hard_cap、または連続未約定 n 件 ⇒ RFQ Gateway を pause 60 s。

6. PoC ２週間ロードマップ

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

8. KPI 例（週次レビュー用）

TL;DR

1. RFQ Gateway でネットワーク特有のRFQを受ける → Quote Engine で mid ± margin + inventory_skew を<150 msで値付け → Signer で返送。
2. 成約時は Settlement Orchestrator が即ブロック注文（CEX）／オンチェーンTx（0x）を発火し、Inventory Service が在庫偏りを監視。
3. Paradigm（オフチェーンデリバティブ）と 0x（オンチェーン現物）を押さえれば、「大口・板外」マーケットへの 初期シェア を小資本でも確保できる。

早期にShadow Mode→小ロット実運用→KPI計測のサイクルを回し、利幅の厚いRFQ市場で“存在感”を築きます。

Perp-Spot ベーシス & Funding アービトラージ ― 実装ガイド

目的：

• 8 h ごと に発生する Funding Fee と Perp-Spot ベーシス（価格乖離）を同時に抜き取る。
• デルタニュートラル を維持しつつ、連続ポジション維持コスト（資金調達・在庫バランス）を最小化する。

1. システム全体像

graph LR
    P(Perp Price Feed) --> C(Core Engine)
    S(Spot Price Feed) --> C
    F(Funding Oracle)  --> C
    C -->|"open / close"| R(Route Executor)
    R --> A(Exchange Adapter)
    R --> B(Exchange Adapter)
    C --> I(Inventory Service)
    I --> C
    M(Metrics & Alert) --> C
    M --> I

2. モジュール詳細

3. エッジ計算ロジック

# t: 秒単位
funding_edge = funding_rate * perp_price * (seconds_to_next / 28800)
basis_edge   = perp_price - spot_price      # コンバージ狙いなら符号反転
carry_cost   = borrow_rate * spot_price * (holding_sec / SEC_IN_YEAR)
tx_cost      = taker_fee_perp + maker_fee_spot + est_slippage
edge         = funding_edge + basis_edge - carry_cost - tx_cost

• funding_rate：年率ではなく 8 h 単位（Bybit, Binance 等は API で直接取得可）。
• borrow_rate：現物不足時の margin borrow or オフチェーンレポレート。
• edge ≥ min_profit_pct × spot_price でエントリ。
• exit 条件：edge < -cut_loss_pct * spot_price or max_holding_hrs 超過。

4. ポジション管理フロー（8 h サイクル想定）

1. Pre-Check
   • edge_calc() が正値かつ |net_delta| < cap。
2. Open
   • Perp SHORT + 同数量 Spot LONG（or Perp LONG + Spot SHORT）
   • 同一取引所に現物が無ければ cross-exchange でヘッジし在庫 Service へ登録。
3. Hold
   • Funding 受取（or 支払）ごとに PnL + funding を記録。
   • basis_edge が逆転したら delta neutr を維持しつつポジサイズを調整。
4. Close
   • 一括成行 or basis 0 接近時の指値で約定。
   • inventory.rebalance() が現物差引、出金/入金をスケジュール。

要点：日常の MM で 1 秒〜数分おきに行っている delta hedge を 8 h 間隔に伸ばすだけ。
リアルタイム板取り合いではないため、レイテンシは 100 ms 程度でも十分。

5. 維持コスト & リスクモデル

ポジション続投判定
exp_edge_next = funding_edge_next - borrow_fee_next
exp_edge_next > keep_threshold なら継続、そうでなければロールオフ。

6. PoC 14 日ロードマップ

7. 監視 & KPI

実装Tips

1. 同一 CEX 優先：Bybit や Binance は 現物 & Perp を同アカウントで持てる → Withdraw コスト不要。
2. 跨 CEX の場合は flash-transfer 的に hot-wallet 在庫 を厚めに維持し、出金遅延リスクを緩和。
3. Borrow Limit Guard：マージン枠を使う場合は API で borrowable を取得 → 枠が 10 % 未満なら新規建を停止。
4. Funding Spike Detection：rolling_zscore(funding_rate, 24h) > 2 で 優先度 HIGH。
5. 税務考慮：Perp の未実現 PnL と Funding Fee 課税タイミングが異なる場合、会計レイヤで仕分けを分離。

TL;DR

• Edge = Funding + Basis – Carry – 手数料 をリアルタイム計算し、正の期待値が出た瞬間だけ Perp SHORT + Spot LONG（逆も可）を建てる。
• 既存 MM の delta ヘッジロジック と 在庫管理 を “8 h ペース” に緩めるだけで PoC は動く。
• 維持コストモデル（Funding 変動・Borrow Fee）を常時更新し、続投 or 差し替え を数字で判断。
  まずは Shadow → 小ロット実運用 で Funding PnL が手数料を安定的に上回るかを検証する。

清算スナイピング ― 実装ガイド

狙い：清算発火の数十〜数百ミリ秒前に「危険ポジション検知 → Tx 発火」し、
Liquidator Incentive（清算ボーナス）＋ Price Impact α を獲得する。
対象は Hyperliquid‐style on-chain perpetual DEX を想定（EVM L2 同系でも同手法）。

1. システム全体アーキテクチャ

graph LR
    B(BBO and L2 Feed) --> D(Detector)
    O(OI Change Feed)  --> D
    P(Price Oracle)    --> D
    D -->|"liquidation signal"| Q(Quote Builder)
    Q -->|"tx params"| X(Tx Dispatch)
    X -->|"bundle"| H(Builder Relay)
    H --> N(Node RPC)
    N --> G(Gas Monitor)
    G --> D
    I(Inventory and Profit) --> D
    I --> M(Metrics)
    M --> X

2. データ・シグナルレイヤ

3. Liquidation Detectorアルゴリズム

def detect_liq(r):
    # r = realtime snapshot dict
    # 1) price crosses liq price within Δ%
    cross = r['best_ask'] <= r['liq_px'] * (1 + cfg.cross_tol)
    # 2) OI shrink or spike in bankrupt events
    oi_drop = r['OI_now'] < r['OI_prev'] * (1 - cfg.oi_tol)
    # 3) L2 depth vacuum (thin layer)
    depth_vac = r['depth_bid_lvl1'] < cfg.depth_thresh
    # α score
    score = cfg.w1*cross + cfg.w2*oi_drop + cfg.w3*depth_vac
    return score > cfg.score_cut, score

• cross_tol: 0.2-0.4 %
• 重み w1>w2>w3（価格優先）
• 検知〜Tx 構築で ≤ 50 ms を目標。

4. Tx Dispatch & Builder Private Tx

1. Quote Builder
   • liquidate(account, max_pos) か take_ask(size) の calldataを生成。
   • gas_limit = シミュレーション (eth_estimateGas) + 15 %.
2. Builder Relay（Flashbots / Titan）
   • bundle = [tx], target block = pending_block_number + 1.
   • send_bundle(bundle) → returns bundle hash + bundle_price。
   • フォールバック：builder不応答 100 ms → eth_sendRawTransaction.
3. Gas オプティマイザ
   • baseFee spike > cfg.max_base ⇒ Tx skip。
   • priorityFee = cfg.tip_coef * sqrt(pending_txs) （動的）。
4. μs レイテンシ短縮 Tips
   • IPC でローカル geth --http=false --ipcdisable=false に直送。
   • TLS offload：builder エンドポイントへ持続コネクション。
   • CPU pinning：Detector → Quote → Dispatch を同 NUMA node 上に。

5. Inventory & Profit Accounting

6. ガストークン在庫管理

1. Wallet Manager
   • eth_balance < 3 × avg_bundle_cost ⇒ swap(USDC→ETH) via 0x API。
2. Prefund Queue
   • Pre-sign prefund_tx (nonce+1) を mempool監視で自動送信、ガス不足リスクを 0 に。
3. Alert
   • ETH 残高 < min_balance ⇒ Slack mention。

7. KPI と監視

Slack 通知フォーマット例

[Liq-Bot] ✅ profit 0.014 ETH | α 0.009 | reward 0.006 | gas 0.001  
[Liq-Bot] ⚠️ hit_rate 28 %(24h) < target

8. PoC 2 週間ロードマップ

9. リスクとガードレール

TL;DR

1. Detector が price cross + OI drop + depth vacuum を数十 ms でスコアリング。
2. Quote Builder → Builder Relay へ private bundle を投げ、競合より前に清算Txを確定。
3. ガス残高オート補充と KPI 監視で 勝率 > 40 %・Net α > gas×1.5 を維持できれば成功。
   まずは Shadow → 小ロット運用で bundle inclusion latency と Net PnL を数字で確認し、
   インセンティブが期待通りに乗るか検証する