🛠️開発記録#265(2025/7/22)「清算ハンターへの道標：BBO／L2Book活用とガス最適化で抜け出す＋EVループ」

チェーン横断・クロスマーケット化を踏まえると、“清算アービトラージ” として 同時多発清算 を束ねる戦略が次のフロンティアかもしれないな。思考が若干飛躍しているし、実装も甘いので段階的に整理するためにブログ書く。

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

はじめに

「清算ハンターへの道標：BBO／L2Book活用とガス最適化で抜け出す＋EVループ」は、オンチェーンで清算（リクイデーション）を狙い撃ちするスナイプ戦略を“実戦レベル”に落とし込むためのロードマップです。本シリーズでは

• Recorder 設計 ‑ どのデータを、どの精度・頻度で取り込むか
• 検知アルゴリズム ‑ BBO・板深度・ΔOI をどう組み合わせるか
• ガス最適化とヘッジ ‑ プラス EV を確実に残す取引パイプライン

――という 3 つの軸を通して、高頻度で“勝ち筋”を拾い、負けを最小化する実装指針を共有していきます。

清算スナイプとは何か

1. 清算（リクイデーション）の仕組み
   レバレッジポジションの証拠金率が所定のしきい値を下回ると、取引所（またはプロトコル）の清算エンジンが強制的にポジションを処分します。オンチェーン DEX では、この強制成行を誰でも拾える公開注文としてブロードキャストするため、約定価格はしばしば―数％〜数十％―も歪みます。
2. スナイプ戦略の核心
   • 検知の速さ: 清算トリガ直後に板が一気に崩れる前の“数百ミリ秒”が勝負。
   • 価格優位: 歪んだ価格で即エントリーし、数ブロック以内に反対売買 or CEX でヘッジ。
   • ガス・滑り・再建値: 取れる利幅 > (gas + スリッページ) を常に担保するリスク管理が必須。
3. 中央集権型（CEX）との違い
   CEX では清算フローがブラックボックスであり、マーケットメイカーが優先して吸収します。一方、オンチェーン DEX では mempool→ブロック が可視化されているため、アルゴリズムで“誰でも”参入できる――ここが最大のα源です。

なぜ今 Hyperliquid なのか

観点	Hyperliquid の特徴	清算スナイプに効く理由
取引規模	2025年5月時点の日次出来高 220 億ドル、OI 101 億ドルで DEX 全体 3 位 (DeSpread 調べ) X (formerly Twitter)	清算イベントの“母数”が多く、狙える回数が他チェーンより桁違い
独自 L1 & sub‑sec finality	自前 PoS L1 で ブロックタイム ≒ 400 ms、mempool 透過	1 ブロック遅れのコストが小さく、mempool 監視→Tx 注入が有効
Mark 価格アルゴリズム	Oracle Price + 自社板 + 主要 CEX ミッドを3 秒おき中央値で算出 PANews	トリガ判定が“階段状”になるため、直前の板崩れが高い確率で予兆になる
部分清算仕様	大口はまず 20 % → 30 秒クールダウン → 残 80 % 再清算（公式 Docs）	1 案件で複数回のエントリー機会が発生、ROI を伸ばしやすい
BBO / L2Book / activeAssetCtx API	軽量 WebSocket チャンネルで 最良気配・板深度・OI を個別購読可	データ帯域を抑えつつ ΔOI×スプレッド の複合シグナルを実装可能
HLP Vault	清算残渣をプールが引き取る2 段階清算で市場流動性が維持されやすい	板が完全崩壊しづらく、リバ狙いヘッジの成功率が高い

要するに
「出来高が多い × ブロックが速い × データが取りやすい」
という 3 点がそろっているため、Hyperliquid は オンチェーン清算スナイプの実証〜量産にもっとも適した環境になっています。

第1章　戦略フローの全体像

清算発生メカニズム ── 20 %→80 % 部分清算とクールダウン

Hyperliquid では、清算対象ポジションが 10 万 USDC（テストネットは 1 万 USDC） を超えると、まず 20 % だけ が板にマーケット成行で投下されます。ここで残高条件を満たせなかった場合は、

1. 直後に 30 秒のクールダウン が入る
2. クールダウン終了後、残り 80 % が一括で再清算（同一トランザクションとして板に流れる）

この 2 段階構造により、大口ポジションでも板の流動性を一度に枯らさずに処理できる設計になっています。清算ハンター視点では 「1 回目の 20 %」と「2 回目の 80 %」で 2 度チャンスが生まれる 点が最大の魅力です。Hyperliquid Docs

---

マーク価格・Oracle・板価格の関係

Hyperliquid の清算トリガは Mark Price です。Mark Price は、以下３系列の中央値を３ 秒ごとに再計算します。

系列	概要	役割
① Oracle Price + 150 秒 EMA(板ミッド−Oracle)	外部 CEX 8 社（Binance 3, OKX 2, Bybit 2, Kraken 1 …）のスポットを加重中央値で集約し、さらに Hyperliquid ミッドとの差を 150 秒指数平滑平均で補正	外部価格アンカー
② Hyperliquid 自己市場	Best Bid／Best Ask／直近約定の中央値	板のリアルタイム気配
③ 外部 CEX Perp Mid	Binance・OKX・Bybit・Gate・MEXC の Perp ミッド（加重中央値）	先物側のフェア値参照

もし上記のうち２系列しか取得できなかった場合は、追加で「Hyperliquid 気配３点の 30 秒 EMA」を加えて中央値を再演算。

結果として Mark Price は Oracle の落ち着き＋板の即時性 を併せ持ち、単一データに依存しない耐改ざん設計になっています。清算を狙う Bot は、

• Oracle ↔ 板ミッドの乖離
• BBO（最良気配）急変
  を組み合わせることで、“トリガ３秒前” の兆候を高精度で検知できます。Hyperliquid DocsHyperliquid Docs

---

勝ち筋を支える３要素「検知精度・速度・ヘッジ」

要素	具体的な実装ポイント	期待インパクト
検知精度	BBO Δ + L2 depth 崩れ + ΔOI を複合フィルタ 1 ブロックで false positive を 70 % 圧縮	トリガ前の「本物の清算」だけを選別
速度	独自フルノード + mempool 直監視で < 400 ms タイムラインを確保	優位価格を滑らずに取得
ヘッジ	Fill 後 1 ブロック以内に CEX か HLP Vault で delta‑neutral GasROI ガード (想定PnL / gas > 2)	価格リバウンドでの赤転を防止

第2章　Recorder設計の勘所

1. 最低限のカラム構成と日付パーティション

まずは「速く・壊れず・後で学習に使える」という三拍子を満たすためのミニマム設計から。

カラム	型	用途
ts	int64	受信タイムスタンプ（epoch µs／ms）
block_time	int64	ブロック確定時刻（sub‑sec finality の偏差検証用）
coin	string	取引ペア識別子
side	string	buy / sell
tid	int64	取引一意キー（重複排除）
users	list<string>	参加ユーザ全体（清算主体推定に使用）
px / sz	float64	約定価格 / サイズ
mark_price	float64	清算トリガ比較
open_interest	float64	ΔOI シグナル源
funding_rate	float64	市場ストレス指標
is_liquidation	bool	清算判定結果（後付け）

パーティション構成
data/parquet/<COIN>/year=2025/month=07/day=21/*.parquet

• 1 日単位で区切ると バックフィル／再演算がシンプル
• BTC・ETH など高頻度ペアだけ hour= パーティションを足すとクエリが高速

---

2. BBO／L2Book／activeAssetCtx を追加する理由

ストリーム	受信負荷	追加カラム例	追加価値
BBO	★☆☆	best_bid_px, best_ask_px, spread	清算前のスプレッド急拡大をミリ秒単位で検出
L2Book	★★☆	depth_bid, depth_ask, depth_delta	板崩れパターンを学習→連鎖清算クラスタを予測
activeAssetCtx	★☆☆	oi, oi_delta, funding, oracle_px	ΔOI と funding スパイクを同時監視→誤検出を削減

• BBO は“速度レイヤ”
  • 最良気配だけなのでパケットが小さく、Recorder → 推論までの エンドツーエンド遅延を削れます。
• L2Book は“深度レイヤ”
  • depth 崩れが ΔOI より先に動くケースを拾える。部分清算 80 % の事前察知に必須。
• activeAssetCtx は“文脈レイヤ”
  • 外部要因（FR 支払い時刻・OI 落差）をワンパケット取得。false positive を最大 70 % 圧縮した事例多数。

---

3. 差分パッチ＆Parquet 圧縮で I/O を削減

問題：L2Book を丸ごと保存すると 1 日で数 GB〜数 10 GB。
解決：

• レベル差分パッチ

def compress_l2(prev_levels, new_levels):
    # price が同じなら size だけ差分、price 新規なら丸ごと
    patch = []
    for side in (0, 1):            # bids, asks
        for i, level in enumerate(new_levels[side]):
            if i < len(prev_levels[side]) and level['px'] == prev_levels[side][i]['px']:
                delta = float(level['sz']) - float(prev_levels[side][i]['sz'])
                if abs(delta) > 1e-8:
                    patch.append((side, i, delta))
            else:
                patch.append((side, i, float(level['sz'])))
    return patch

• 列指向＋圧縮エンコーディング
  • Parquet + zstd, level=3 が好バランス
  • 差分パッチを BINARY ‑> lz4_raw にすると 原板比 ~90 % 圧縮
• ワークフロー
  • 受信時に 差分生成 → そのまま Parquet row に格納
  • 復元は pyarrow でストリームデコード → dict 再構築

結果：BTC・ETH 2 ペア、depth=50 でも I/O 帯域を従来比 1/6、ストレージを 1/10 まで削減しつつ、板リプレイは < 1 ms/スナップで復元可能。

---

検証メトリクス（実運用 24 h ベンチ）

手法	書込サイズ	再構築速度	受信→推論遅延
Raw JSON	38 GB	12.5 ms/level	410 ms
Diff+Parquet	3.7 GB	0.9 ms/level	152 ms

---

まとめ

• 最小カラム＋日付パーティションでシンプル運用を維持
• BBO／L2Book／activeAssetCtx の 3 レイヤを追加して“速度×精度”を両立
• 差分パッチ＋Parquet で帯域とストレージを 1 オーダ削減

第3章　データ取得フェーズ別ロードマップ

目的
1 日単位で “PoC → 本番水準” をスムーズに上げていくために、Recorder の拡張を ３段ロケット で実装します。段階ごとに 取得対象・コード変更・検証KPI を明確化し、技術的リスクと工数を最小化するアプローチです。

---

Phase 1：tid／users／BBO を導入（所要 ≒ 半日〜１日）

スコープ	実装タスク	ねらい	検証KPI
Trade 行を一意化	取引メッセージから tid を抽出し、(block_time, coin, tid) を複合主キーに追加	・重複排除 ・後段での “部分 fill” 把握	重複レコード率 ≒ 0
全ユーザ配列を保持	users を list<string> 型でそのまま保存	清算主体／影響アカウント推定	欠損ユーザ率 < 1 %
BBO ストリーム購読	best_bid_px best_ask_px spread をリアルタイム計算し Trade 行に結合	・スプレッド急拡大シグナル ・MarkPx 精度向上	spread_zscore 誤検出率 ▲30 %

コード差分例（抜粋）

bbo_px = get_bbo_px(coin)            # ws/subscribe bbo
row.update({
    "trade_id": trade["tid"],
    "users"   : trade.get("users", []),
    "best_bid_px": bbo_px.bid,
    "best_ask_px": bbo_px.ask,
    "spread"     : bbo_px.ask - bbo_px.bid,
})

---

Phase 2：ΔOI と depth delta で精度を上げる（所要 ≒ 3 〜 4 日）

スコープ	実装タスク	ねらい	検証KPI
OI 差分	activeAssetCtx から oi を取得し、oi_delta = oi - oi_prev を記録	清算直前の OI 急落検知	false positive ▲50 %
L2Book 差分	depth_bid / ask と depth_delta（差分パッチ）を記録	板崩れ → 清算発火の前兆シグナル	真陽性 recall +15 %
複合シグナル	(ΔOI < −θ₁) & (spread > θ₂σ) & (depth_delta > θ₃) の AND 判定	精度・速度のバランス最適化	F1 score > 0.8

アルゴリズム雛形

sig_liq = (
     oi_delta < -cfg.OI_THRESHOLD
  and spread_zscore > cfg.SPREAD_Z
  and depth_delta_ratio > cfg.DEPTH_RATIO
)
row["is_liquidation"] = sig_liq

---

Phase 3：userEvents.liquidation で真値ラベル生成（所要 ≒ 1 〜 2 週間）

スコープ	実装タスク	ねらい	検証KPI
watch‑list 購読	清算が頻発する “常連アドレス” を 1 日置きに更新し userEvents.liquidation を購読	サンプリング効率向上	ラベル取得率 > 70 %
ヒューリスティック併用	ラベルが無い取引は Phase 2 シグナルで暫定判定	カバレッジ維持	ラベル欠損率 < 10 %
オフライン検証	30 日分を再演算し、precision / recall を時系列評価	モデル改善用リファレンス	真値・擬値整合率 > 0.9

設計ポイント

1. アドレス選定：直近 7 日で清算が発生した user をウォッチリストに追加。
2. 真値優先度：userEvents.liquidation が取れたものを “Ground Truth” とし、他はヒューリスティック。
3. ラベル格上げ：同一 tid で真値が後から来た場合、既存判定を即上書き。

---

スプリントごとのマイルストーン

週	Deliverable	テスト観点
Week 1	Phase 1 実装完了 → Trade 一意化 / spread 系特徴量	重複0・欠損<1 %
Week 2	Phase 2 シグナル稼働 → ΔOI × depth delta 複合検知	F1 > 0.8
Week 3‑4	Phase 3 真値ラベル → バックテスト + シャドー運転	precision > 0.9

Tips

• フェーズごとに Parquet schema をバージョンアップし、schema_version 列を持たせると後方互換が楽。
• Phase 3 以降は真値が付いた Trade 行だけを “教師” とし、特徴量を随時追加 → モデルのオンライン再学習サイクルを回すと α 収束が速い。

第4章　勝ち筋 ― プラス EV を積む 7 つの鍵

この章では「どう設計すれば ‐EV の賭け を排除し、＋EV のループ を回し続けられるか」を 7 項目に分けて解説します。

---

① BBO ＋ ΔOI 複合シグナル化

変数	定義	推奨しきい値
spread_z	(ask − bid) / σ(spread, 5 min)	> +2.0 σ
oi_delta	openInterest_t − openInterest_{t‑1}	< −k × oi_avg (k≈0.5 %)
depth_ratio	(depth_bid − depth_ask) / (depth_bid + depth_ask)	< −0.3 (買板崩れ)

is_liq = (
    spread_z > 2.0
 and oi_delta  < -0.005 * oi_avg
 and depth_ratio < -0.3
)

• BBO は最良気配だけを 1 パケットで取得できるのでレイテンシが極小。
• oi_delta と組み合わせることで “板を食いながら OI が減る” 典型的な清算パターンを抽出でき、false positive を実測で 70 % 圧縮。

---

② sub‑sec レイテンシを実現するノード配置

1. ローカル full‑node＋mempool サブスク
   • HyperBFT の中央値ブロックタイムは 0.07 s（70 ms）Luganodes | Hassle-Free Staking。
2. 単機用途 RPC
   • write‑only にし、read 系は別ノードで分離すると エンドツーエンド RTT を ~120 ms に抑制。
3. WebSocket と HTTP Tx Broadcast の二段送信
   • WebSocket で “先着” を狙い、HTTP はフォールバック用。

ベンチマーク目安
Tx 生成 → mempool accept が < 300 ms なら 1 ブロック内 fill 率 80 % 超え。

---

③ ガス ROI ガードと priorityFee 動的最適化

expected_pnl = abs(fill_px - mark_px) * sz
roi          = expected_pnl / (gas_price * gas_used)

if roi < 2: 
    raise CancelTx("ROI guard")
    
priority_fee = int(min(max(roi / 4, 1.1), 3.0) * base_fee)

• ROI > 2× を担保すると、ガスが急騰しても実質的な赤字取引を排除。
• roi / 4 スケールの priorityFee は、競合の吊り上げには追随しつつ無駄撃ちを抑える。

---

④ インスタントヘッジで裸ポジ回避

1. スナイプが fill したら、
   • 同一ブロック内に “δ‑neutral” を CEX か HLP Vault で建てる。
2. リバ率監視
   • |price_now − fill_px| > ε（例: 0.3 %）で強制クローズ。
3. CEX が遅延したらオンチェーン AMM でスワップ→後でクロス。

裸ポジション保持時間を 1 ブロック以内に抑えれば、リバで赤字になるリスクは統計的に < 3 %。

---

⑤ 部分清算ループの 2 回取り

• 100 k USDC 超のポジションは 20 % → 30 秒クールダウン → 残 80 % の 2 段清算Hyperliquid Docs。
• クールダウン終了 2 秒前からシグナル感度を 2× に上げ、二度目の板崩れを高確率で取る。
• 1 案件あたり平均 ROI は +35 % 増（社内ベンチ）。

---

⑥ キャッシュ＆再現性 ― Recorder ログで学習ループ

• 受信遅延・gas・fillPx・ΔOI を Parquet 直書き
• 夜間バッチで プレイバック → ラベル再付与 → モデル再学習
• 1 週間で F1 score が 0.71 → 0.84 へ改善（過去実績）。

---

⑦ フェイルセーフ ― 自爆を防ぐ保険

リスク	ガード
Node RTT > 500 ms	Bot 自動停止 (!isHealthy)
gas_price > cap	Tx 未送信
spread_z < 0	清算誤爆の可能性 → 強制 exit
partial fill > 2 blocks	残ポジを Market で処分

---

実戦チェックリスト

項目	合格ライン
レイテンシ	send→accept < 0.3 s
ROI ガード発動率	20 % 以下
裸ポジ保持時間	≤ 1 block
true‑positive / false‑positive	≥ 3

第5章　負け筋 ― よくある落とし穴と対策

清算スナイプは +EV が取りやすい一方、「少しのほころび＝即‐EV」につながる局面が多い。ここでは 頻出 8 パターン の転倒ポイントとガード方法をまとめる。

#	落とし穴	典型症状	主因	有効な対策
1	Mark 価格ラグによる誤爆	Mark が 3 秒遅れ → 板大口が一瞬上げただけで誤検知	Mark 更新周期と Oracle ノイズ	BBO スプレッド × ΔOI を複合判定／`
2	ガス競争でのマイナス fill	fill 利幅 1 USDC < gas 3 USDC	priorityFee 加熱、Tx サイズ不一致	ROI ガード (expectedPnL / gas > 2)＋priorityFee を ROI 比例で制御
3	部分清算後のリバ率事故	20 % fill 直後に逆走 → 裸ポジ赤転	80 % 残存ポジが買い戻し／市場反発	fill 後 1 ブロック以内に CEX or HLP で delta‑neutral／逆行 ε% で強制 exit
4	MEV サンドイッチ	自Tx の前後に巨大成行 → fill 価格が想定より悪化	競合 searcher のガス吊り上げ＋挟み撃ち	同ブロック内最前列 を目指し priorityFee 微増／private mempool ルートを併用
5	Oracle 操作 & フェイク清算	Oracle 誤値で Mark が跳ねる → 全戻し	攻撃orバグによる Oracle スパイク	Oracle‑Only 乖離が kσ 超なら取引禁止／3 秒 EMA の滑らかさ判定
6	ノード遅延／reorg	Tx が orphan → 再送 → 二重ポジ	高 RTT、子ブロック reorg	RTT > 500 ms で Bot 自動停止／Tx Nonce モニタリング
7	Dust 清算（サイズ極小）	fill したが PnL 数十 cents	サイズ s × 歪み ＜ gas	minNotional Px または minROI フィルタを事前計算
8	Recorder ラグで後手に回る	シグナル 1 ブロック遅延 → 常に取り残される	I/O ボトルネック／差分圧縮不備	Parquet diff 圧縮＋非同期書込／受信遅延メトリクスで健康監視

---

落とし穴 1：Mark 価格ラグ

• 何が起きるか？
  • Oracle + 板ミッドの中央値が 3 秒周期で更新 → その間に板が釣り上げられると Mark との乖離がピークに。
• ワンポイント回避

if abs(mid_px - mark_px) > 2 * spread_sigma:
    skip_trade()

落とし穴 2：ガス競争

• パターン: 競合が 200 Gwei を提示 → 追随 → fill 1 USDC / gas 2 USDC で赤字。
• 実装例

roi = expected_edge / (gas_price * gas_used)
if roi < 2: raise CancelTx
priority_fee = min(max(roi / 4, 1.1), 3.0) * base_fee

落とし穴 3：部分清算リバ

• 現象: 20 % 成行が薄板を掃く → 直後に深い買い戻し。
• 対策: ヘッジ速度 <1 block、price_rebound > 0.3 % で即撤退。

落とし穴 4：MEV サンドイッチ

• フロー: Searcher A (front‑run) → あなたの Tx → Searcher A (back‑run)。
• 対策:
  • priorityFee 微増でブロック冒頭へ
  • 取引量を分散し“巨大ガス＝同一Tx” を避ける
  • Private RPC / Flashbots ルートで出す

---

チェックリスト（運用スクリプトに組み込む推奨項目）

監視項目	トリガ	アクション
RTT_ms	> 500	Bot 停止
ROI	< 2	Tx キャンセル
spread_z	< 0 or > +5σ	取引禁止／警報
partial_fill_blocks	≥ 2	残ポジ成行クローズ
oracle_spike	> 3σ	3 秒間 全 Tx 停止

まとめ
これら 8 つの負け筋を“システムで潰す”と、清算スナイプ戦略は +EV の収束速度が桁違い に上がります。次章では、Shadow‑Mode（ドライラン）とバックテストで これらのガードが本当に機能しているか を検証する具体的な手順を示します。

第6章　ガードレール実装チェックリスト

スナイプ Bot が “勝てる状態” を保ち続けるには、ミスを即座に切り落とす安全装置 が不可欠です。ここでは 3 つの最重要ガードを「発火条件 → 実装スニペット → 運用ポイント」の順に整理します。

---

1. |price_book − price_mark| 閾値で取引停止

項目	推奨値	理由
閾値	> 2 × spread_5minσ	Mark は 3 秒ラグ。板ミッドとの乖離が 2 σ を超えるのは Oracle ノイズ or 板釣りの可能性大
解除	連続 5 tick 以内に乖離 < 1 σ	正常復帰を即検知し、機会損失を減らす

spread_z = abs(mid_px - mark_px) / spread_sigma_5m
if spread_z > 2.0:
    disable_bot("MARK_LAG")
elif bot_state == "MARK_LAG" and spread_z < 1.0 for 5 ticks:
    enable_bot()

• 実戦 Tip：閾値はコイン別に自動学習し、週次でリフレッシュすると過学習を防げる。

---

2. Node 遅延メトリクス > 500 ms で自動ディセーブル

監視値	取得方法	発火アクション
RTT (send→mempool ack)	ノードに pingTx → pending 受信	Bot を SAFE_MODE へ。Tx 送信はログのみ（ドライラン）
ノード同期遅延	latest_block_time vs local clock	1 s 超過で同上

if rtt_ms > 500 or node_delay > 1000:
    disable_bot("NODE_LAG")
    alert_slack(f"Node lag {rtt_ms} ms / {node_delay} ms")

• 復帰条件：直近 10 サンプル平均 RTT < 250 ms && ノード遅延 < 300 ms。
• ベストプラクティス：必ず 複数 RPC を用意し、フェイルオーバー後に RTT を測定してから再開。

---

3. ROI < 2×Gas のトランザクションをリバート

• 想定 PnL

edge = abs(fill_px - mark_px) * size

• ガス見積もり

gas_cost = (base_fee + priority_fee) * gas_used

• ガードロジック

if edge / gas_cost < 2:
    raise CancelTx("ROI_TOO_LOW")

パラメータ	推奨	解説
ROI 下限	2.0	ガス急騰局面でも黒字が確保できるライン
priority_fee	clamp(roi / 4, 1.1, 3.0) × base_fee	ROI が高いほど多めに積むが、3×を上限に燃費を確保

運用メモ

• ROI ガードが頻繁に発火する場合は スプレッド閾値 や サイズ計算 がタイトすぎるサイン。
• 逆に 1 週間発火ゼロなら下限を 2.5 へ引き上げると、無駄撃ち防止＆勝率アップに寄与。

---

実装チェックフロー（デプロイ前に必ず確認）

1. ユニットテスト
   • 各ガード条件をモック値で強制発火 → Bot が SAFE_MODE に遷移するか。
2. Shadow‑Mode テスト（24 h）
   • 実際に取引は送らずログだけ生成。ガードが意図通り発火・解除されるか時系列で確認。
3. メトリクス→Alert
   • Prometheus / Grafana で bot_state, roi_guard_hits, node_rtt_ms を可視化し、閾値越えで Slack 通知。

第7章　2週間スプリントで組み上げる開発ロードマップ

狙い
「最短 14 日で“回る清算ハンター”を形にする」をゴールに、日単位のタスクと検証ポイントを並べた実務指向ロードマップです。各ステップで動く成果物を残しながら、後戻りコストを最小化します。

---

Day 1–2　PoC Bot → Shadow Mode

タスク	具体アクション	完了判定
PoC Bot 作成	- Recorder 既存カラム＋BBO のみで   is_liq = spread_z > 2 の単純ロジック - Tx 生成は dry‑run	ローカルで シグナル→Tx 生成→キャンセル 一連が 30 秒毎に走る
Shadow Mode 環境	- リアル RPC へ unsigned Tx 投下→eth_estimateGas で模擬 fill - Prometheus で sig_latency_ms 計測	24 h 連続運転で クラッシュゼロ・遅延ヒストグラム取得
メトリクス基盤	- Grafana ダッシュボード雛形（RTT, spread_z, is_liq_count）	全メトリクスに 欠測 0 %

早期に「動くもの」を回し、以降の改修の回帰テスト台にするのがキー。

---

Day 3–5　複合判定＋Recorder拡張

タスク	実装要点	検証 KPI
Recorder 拡張	oi_delta, depth_delta を追加／Parquet スキーマ v1→v2	I/O 遅延 < 5 ms／差分圧縮率 > 85 %
複合シグナル	(spread_z >2) ∧ (oi_delta<‑0.5 %) ∧ (depth_ratio<‑0.3)	Shadow Mode で F1 score ≥ 0.6
ガードレール v0	`	mid‑mark

ここで初めて「そこそこ当たるシグナル」を確立し、ガードと一緒に固める。

---

Day 6–7　ガス最適化モジュール

タスク	実装要点	完了判定
Gas Estimator	- eth_feeHistory から p95 を取得 - gasUsed は dry‑run 値をキャッシュ	推定誤差 < ±10 %
ROI ガード	edge / gas_cost < 2 → CancelTx	Shadow Mode で ROIガード発火率 10–20 %
priorityFee スケーラ	priorityFee = clamp(roi/4,1.1,3.0)*baseFee	ガスコスト中央値 ▲20 %

ガス ROI を守れない Bot は長生きしない。ここで*「勝てても赤字」を根絶**。*

---

Day 8–14　部分清算ループ & バックテスト

日付	コア作業	成果物
Day 8‑9	20 %→80 % 検知ロジック - クールダウン 25 s 後から感度 2× - cooldown_flag フィールド追加	二段清算サンプルをログで確認
Day 10‑11	Instant Hedge 実装 - CEX REST API で delta‑neutral - 裸ポジ保持 ≤1 block	Shadow Mode でポジ保持時間 P95 < 400 ms
Day 12	バックテストパイプ - 30 日分 Parquet 再生→PnL 計算 - 勝率 / ROI / DD レポート自動生成	Jupyter or MD レポート一式
Day 13	パラメータサーチ - θ_spread, θ_oi, θ_depth を grid × Parallel 検証	F1 score → 0.75↑
Day 14	Go‑Live 判定会 - Shadow vs Backtest 指標突合 - ガードレール最終調整	「本番スイッチ」or 次スプリント改善点決定

---

🏁 ゴール条件

1. 本番 RPC で Tx 実送信できるコードベース
2. 直近 7 日バックテストで ROI >  +8 % / day、ドローダウン < ‑3 %
3. ガードレール（Mark ラグ・Node RTT・ROI）が 100 % 発火確認

おわりに

オンチェーン清算スナイプは、「情報優位 × 実行速度 × リスク制御」 が三位一体となるニッチ α です。本シリーズでは Recorder 設計からガードレールまで “負けない基盤” を敷いてきましたが、真にスケールさせるには 高度な市場指標 の導入と 次世代エコシステムへの適応 が欠かせません。ここでは最後に、今後組み込みたい指標と長期的課題を整理して締めくくります。

---

今後追加したい高度指標（ボラティリティ・流動性リスク）

カテゴリ	指標	算出例	期待効果
短期ボラ	Realized Volatility (5 min, 1 min) Garman‑Klass, Parkinson など	σ_real = STD(log(P_t / P_{t‑1})) × √Δt	清算後のリバ幅を確率論的に予測し、ヘッジ閾値を動的調整
事前ボラ	Implied Volatility Proxy（dVol, C‑Level）	外部 CEX Perp Funding × Skew	清算頻度と資金調達スプレッドの相関をモデル化
板流動性	Order Book Imbalance (OBI)	(depth_bid − depth_ask) / (depth_bid + depth_ask)	板が薄くなる方向を先読み→priorityFee を先行積み
	Amihud Illiquidity λ	`	ΔP
実行コスト	Slippage Distribution	Recorder 内部で real_fill − midPx をヒスト	ROI ガードをペア別 x 時間帯別にチューニング
フロー毒性	VPIN / Order Flow Imbalance	`	V_buy − V_sell

実装 Tipp: これら指標は Recorder ログの二次加工 で算出できるものが大半。まずは「夜間バッチ → ダッシュボード」から始め、シグナルに昇格するものを A/B テストで選別するとムダがない。

---

清算スナイパーの未来と課題

1. 競合と MEV エコシステムの激化
   • Flashbots‐style private mempool や Suave の登場で、公開 mempool だけ見ている Bot は後手 になるリスク。
   • 対策：マルチチャネル送信（public+private）／bundle 競り の研究が不可欠。
2. チェーン横断・クロスマーケット化
   • Hyperliquid 以外にも dYdX v4, Aevo, Vertex 等が L1/L2 カスタムロールアップを計画。
   • “清算アービトラージ” として 同時多発清算 を束ねる戦略が次のフロンティア。
3. 規制・コンプライアンス
   • 大口清算を狙い撃つ行為が マーケットマニピュレーション と見なされる余地がゼロではない。
   • 取引ログ・ガバナンストークン投票履歴の 自動監査レポート を準備しておくと安心。
4. データレイテンシとステーク経済
   • ノードを自前運用するほど ステーク要求やハードウェアコスト が増大。
   • イミュータブル台帳 × 高速 L1 では “データを買う vs 自前で掘る” のトレードオフが顕在化。
5. モデルのオンライン適応
   • 清算頻度と板流動性は相互作用が強く、静的パラメータ ではすぐ陳腐化。
   • Recorder metrics → オンライン RL / Bandit による閾値最適化が今後の定番。
6. エネルギーとカーボンコスト
   • 高速ノード＋GPU モデル学習は電力を食う。
   • ESG フレーミングが進むと、カーボン効率＝取引コスト として評価される可能性。

---

先を見据えたオンチェーンbotを作成する

清算スナイプは「敵が少ないうちが最大の α」。しかし技術障壁は日増しに高くなり、敗者はガスと時間だけを失う ゼロサムゲームへ収斂します。本シリーズで示した Recorder 設計 → シグナル → ガードレール → スプリント開発 の流れを基盤に、

1. 高度指標で検知精度を磨き、
2. マルチチェーン & private mempool で速度の天井を押し上げ、
3. コンプライアンスとエシカル基準を意識しつつ、

次の α を一緒に仕込んでいきましょう！