wolverine-strategy

🦡 WOLVERINE v6.1.0 — HYPE 患者の確信

v6.1.0 (2026-06-01) — HYPE のボラティリティに対応し、Phase 1 のリトレース許容幅を拡大

DSL の変更は1か所のみです。スコアリング、ゲート、レバレッジ、Phase 2 に変更はありません。 exit.dsl_preset.phase1.retrace_threshold 8 → 15。

理由。 HYPE の壮大な上昇局面で、Wolverine は ROE +16.4% の利益を捉えましたが、値動きの大半を取り逃し、直近の期間では勝率が25%、損失は ROE −5%〜−9% に集中しました。証明可能な構造的原因は、レバレッジ5倍では ROE 8ポイントのリトレースが HYPE価格の1.6%の許容幅（8 ÷ 5）に相当することです。HYPE は15分足のローソク1本の中で3〜5%のヒゲを頻繁につけるため、この1回の違反で発動する（consecutive_breaches_required: 1）リトレースは通常のノイズに反応し、広い Phase 2 の「利益を伸ばす」ラダーが乗るために設計された大きなトレンドへ成長する前に、小さな損失でポジションを決済していました。損失が −5%〜−9% に集中しているのは、取引が ROE +2〜3% でピークをつけ、価格が1.6%戻したところで8ポイントのリトレースが発動したと考えれば整合します。

修正内容。 ROE 15ポイントは、レバレッジ5倍で 価格の許容幅が約3.0% となり、バッファーがおよそ2倍になります。それでもハードストップの max_loss_pct 20% を大きく下回るため、ハードストップと一体化するのではなく、ピークから追従する独立したルールとして機能します（そのため、max_loss と同じ値になる20ではなく15にしています）。

これだけに限定する理由。 直近の期間は n=12（スコアの各バケットは n=2-4）で、統計的には勝率50%と区別がつきません。Phase 2 のロック、エントリースコアの下限、MIN_4H_STRUCTURE を再調整する根拠としては不十分です。このリトレース修正だけは、サンプルサイズに左右されず、ストップ幅とボラティリティの計算だけを根拠に正当化できる変更です。それ以外の変更はデータが集まるまで保留します。

判断基準。 40〜50件の取引後に期待値を再測定します。利益を伸ばすトレンドエージェントは、勝率が低くなるのが当然です。問題となるのは、利益の大きさが損失額を上回れない場合だけです。勝率25%で損益分岐に達するには、平均利益と平均損失の比率が3:1必要です（直近の期間では1.56:1で、利益が早く打ち切られていました）。この修正を適用し、十分なサンプルを得ても期待値がマイナスのままであれば、HYPE にトレンドフォロー型のアーキタイプは合わず、書き直すべきです。それまでは戦略が壊れているのではなく、調整が不適切なだけです。

v6.0.0（2026-05-18）— Patient-Conviction の採用（Bison v3.0.1 の移植）

スコアリングに変更はありません。戦略にも変更はありません。ゲートにも変更はありません。動作プロファイルを「スコア ≥9 で1日4回エントリー、T0 ロック=35 の厳格な設定」から「スコア ≥10 で1日2回エントリー、T0 ロック=0 の緩やかな設定で数日間保有」へ変更します。

理由。 Bison v1.0（BTC/ETH/SOL を確信を持って保有するエージェント）は、2026-05-12 にこのパターンをそのままリリースし、その4日後には、乱高下、V字回復、日中の含み損が一時 -8% になる局面を経て4日間保有した SOL のショートポジションで ROE +93.5% を記録していました。この SOL ポジションは、SOL が $92.30 → $83.67（現物価格で -9.4%）となる値動きを乗り切りました。これは、フリート内のすべての高速ローテーション型エージェント（Cheetah、Scorpion、Turbine）がエントリーから数分以内に手仕舞いした値動きです。Bison は、+10% を超えるリトレースが発生するまでポジションに余裕を持たせる DSL のおかげで、ノイズを乗り切りました。この T0 ロック=0 の第1段階は、Bison のラダーで最も効果の大きい単一の調整項目です。

Wolverine は、明らかな追随を拒否するようゲートを厳格化した +12.8% の HYPE 日の事後検証（PR #281、2026-05-15）以来、マイナスが続いています。現在のゲートは、きれいなトレンドを正しく識別できています。不足していたのは、そうしたトレンドを伸ばすための後段の規律でした。v6.0.0 では、Wolverine のフロントエンドには手を加えず、Bison のバックエンドを移植します。

変更内容（5つの小規模な編集）：

ファイル	変更
runtime.yaml risk.guard_rails.max_entries_per_day	4 → 2
runtime.yaml risk.guard_rails.per_asset_cooldown_minutes	120 → 240
runtime.yaml exit.interval_seconds	30 → 60（REDUCE_ONLY のスパムを軽減）
runtime.yaml exit.dsl_preset.phase2.tiers	Bison の幅広いラダー（T0 ロック 0 から T5 ロック 85 まで）
config/wolverine-config.json minScore	9 → 10
scripts/wolverine-producer.py + wolverine_config.py	recent-signals の競合ウィンドウ重複排除（Bison v3.0.1 のパターン）

変更していない内容。

• 6つのゲートによるエントリー検証（4h トレンド、構造 ≥0.65、1h-4h の一致、15m モメンタム ≥0.15、ベーステクニカルの下限、4h 変動幅 ≥1.0%）はそのまま維持します。
• 逆方向に対する SM のハードブロックはそのまま維持します。
• RSI のハードゲート（74 LONG / 26 SHORT）はそのまま維持します。
• マルチファクタースコアリング（最大約17）はそのまま維持します。
• 確信度別のレバレッジ（標準 3x / apex 5x）はそのまま維持します。Bison は主要銘柄で 7-10x を使用しますが、HYPE のボラティリティでは、まだそれを正当化できません。レバレッジではなく DSL ラダーから、確信を持って辛抱強く保有するメリットを得ます。
• FP-001 の静穏時間（apex スコアが 11+ でない限り、00-04 UTC）はそのまま維持します。
• すべての時間制限による決済は引き続き無効です（v3.0.4 の調整で設定した hard_timeout、weak_peak_cut、dead_weight_cut）。

監視すべきトレードオフ。

• T0 ロックを緩めると、勝ち幅の小さい取引で利益をより多く吐き出すことになります（+12% の値動きが +0% までリトレースした場合、v5.x ではロック済みの +4.2% で決済されるのに対し、損益ゼロで決済されます）。大きなトレンドで獲得できる利益が、小さな勝ちの損失を上回る場合にのみ、全体としてプラスになります。Bison の実績は主要銘柄でこれを裏付けていますが、HYPE 固有のデータはデプロイ後30日以上にわたって必要です。
• エントリーを4回から2回に減らすと、HYPE がもみ合う局面で待機時間が増えます。これは許容範囲です。v5.x で Wolverine がマイナスだった期間は、セットアップが稀すぎたのではなく、境界的なセットアップで頻繁にエントリーしすぎたことが原因でした。
• 4時間のクールダウンは recent-signals の重複排除と重なります。シグナルの頻度にかかわらず、Wolverine が HYPE に発注するのは最大でも4時間ごとになります。

ロールバック条件。 v6.0.0 で2週連続して週あたりのエントリーがゼロまたは1回になる場合、下限が高すぎます。wolverine-config.json の minScore を9に戻してください（プロデューサー側の下限は9のままです。オペレーターの選択性のみが設定によって決まります）。その他の差分は維持してください。

v5.0.0 (2026-05-08) → v5.0.1（維持）

v3 → v4 のアーキテクチャを全面的に書き換えました。 v3.x はエージェンシー全体をスキャンするものでした。v4.0 では、標準の senpi-trading-runtime プラグインパターンに切り替えています。プロデューサーがシグナルを出力し、実行と状態はランタイムが管理します。

構造上の変更点：

• wolverine-producer.py（新規）が wolverine-scanner.py（削除）に置き換わりました
• v2-runtime ネイティブ：external_scanner + LLM パススルーゲート + ネイティブ risk.guard_rails
• DSL の出口は FEE_OPTIMIZED_LIMIT 経由です（メイカー約定による決済ごとに約 0.020～0.030% を節約）
• トレードチェーン DB がトレードごとのテレメトリーを出力します。Wolverine でチェーン DB を可視化するのは今回が初めてです
• Python 状態クラッシュ系のバグ（load_tc / set_cooldown / has_resting_orders）は、v4.0 では構造上発生し得ません

v3.0.3/v3.0.4 からそのまま維持されているもの：

• HYPE 単一アセットのテーゼ
• 6段階のエントリー検証：
  1. 4h トレンド != NEUTRAL
  2. 4h 構造的強さ ≥ 0.75
  3. 1h 方向が 4h と一致
  4. 15m モメンタム ≥ MIN_MOM_15M (0.15)（方向も一致）
  5. ベーステックの下限（strong_15m または aligned_5m）
  6. 4h の値幅 ≥ 1.5% — 値動きがほぼないもみ合いを除外する v3.0.3 の修正です。Wolverine 自身による 2026-04-23 の自己診断では、Week 5 の 6 件すべてのトレードが失敗しました。trend_strength_4h は構造的指標（高値切り下げの回数）であるため、4h の価格変動幅がほぼゼロでも条件を通過してしまうためです。
• 方向が反対の場合、SM をハードブロック
• RSI のハードゲート（74 LONG / 26 SHORT）
• マルチファクター採点（最大約 17 点）：ベーステック + SM 集中度 + SM 速度 + ファンディングの整合性 + ファンディングレジーム + ファンディングの持続性 + 出来高 + OI 速度 + BTC 相関 + RSI の余地 + 4h モメンタムボーナス + 値動きの過熱ペナルティ
• MIN_SCORE = 9（設定で上書き可能）
• コンビクションに応じたレバレッジ：5x エイペックス（スコア ≥11）/ 3x 標準（≥9）
• DSL プリセットを維持：タイムカットはすべて無効、Phase 1 は max_loss 20% / retrace 8（v6.1.0：→ 15）/ 3 breach、Phase 2 はラダー（10/15、20/35、35/55、55/70、80/85）

v3.0.1/3.0.2/3.0.4 の v1-DSL 修正を維持：

• dead_weight_cut：無効（単一アセットにはローテーションコストがありません）
• hard_timeout：無効（v1 DSL は Phase 2 で誤ってこれを発動しました）
• weak_peak_cut：無効（v3.0.4 — タイムカットの一掃を完了）
• すべての決済は価格アクションのみで行われるようになりました（100%）

---

⛔ ハードルール（Fleet パッチ）

RULE FP-002：ユーザーとの会話中の Claude セッションは取引してはなりません

ヒューリスティックではなく、厳格なルールです。 ユーザーメッセージに応答する際、Claude Code セッションは次のいずれも呼び出してはなりません。

• create_position
• close_position
• edit_position
• ratchet_stop_add / ratchet_stop_edit / ratchet_stop_delete
• cancel_order
• strategy_close / strategy_close_positions

これらのツールはプロデューサーの cron（wolverine-producer.py）と DSL ラチェットエンジン専用です。cron のみがエントリー経路であり、DSL のみが決済経路です。ユーザーとの会話中のセッションは読み取り専用です。

RULE FP-001：流動性の低い時間帯の静穏時間

デフォルトでは、プロデューサーは 00:00～04:00 UTC の間、出力をスキップします。エイペックス設定（スコア >= quietHours.apexBypassScore、デフォルトは 11）は対象外です。

wolverine-config.json の quietHours.{startUtc,endUtc,apexBypassScore} で設定できます。無効にするには、startUtc == endUtc に設定します。

---

🦡 WOLVERINE — 独自のテーゼ

単一アセット。単一のテーゼ。スマートマネーが仕掛け、Wolverine が飛びかかり、DSL がトレンドを追います。

概要

Wolverine は 3 分ごとに Hyperliquid 上の HYPE をスキャンし、モメンタムシグナルの収束を検出します。

• スマートマネーのコンセンサス — 上位トレーダーの利益率が最低値以上で、トレーダー数もしきい値を超えていること
• 速度の加速 — 15m と 1h の寄与度変化がともにプラスで、さらに上昇していること（15m > 1h）
• 価格による確認 — 4H と 1H の両方がシグナルの方向に動いていること
• 出来高による確認 — 出来高が 6h 平均を上回る急増時にボーナス
• 15m の鮮度ゲート — 古いシグナルにペナルティを与えます（15m velocity < 0）

スコアが 8 以上になると、Wolverine はコンビクションに応じたレバレッジ（7x または 10x）と FEE_OPTIMIZED_LIMIT 注文タイプで HYPE のエントリーを実行します。ポジション管理はすべて DSL 決済エンジンに委任されます。Wolverine 自身がポジションを決済することはなく、エントリーのみを行います。

v2.3 — チョップ耐性を強化

2026-04-14、Wolverine v2.2は約3時間のチョップ相場でHYPEの取引に5回連続で負け、合計-$113となりました。v2.2の基準では、どのエントリーも「新しいシグナル」でしたが、スキャナーには「同じコインで直近N回負けた」という概念がありませんでした。v2.3では、次の3つの保護機能を追加しました。

1. チョップ検出によるロックアウト

3時間以内にHYPEで2回負けると、Wolverineは最後の損失から6時間、HYPEの新規エントリーを拒否します。スキャナーはCHOP_LOCKEDを出力し、チョップ相場が終わるまで待機します。定数：

• CHOP_WINDOW_HOURS = 3
• CHOP_MAX_LOSSES = 2
• CHOP_LOCKOUT_HOURS = 6

2. 方向転換の厳格なゲート

新しいシグナルが、2時間以内のHYPEでの直近の取引と反対方向で、かつその取引が損失だった場合、Wolverineは新規エントリーを厳格にブロックします。チョップロックアウトのしきい値に達する前でも、LONG → SHORT → LONGの往復パターンを検出します。利益が出た後の方向転換は正当な反転の捉え方として引き続き許可し、損失後の方向転換はチョップ相場での追いかけとしてブロックします。

3. 永続エントリーログ

すべてのENTRY、EXIT、CHOP_LOCKOUT、FLIP_BLOCKEDイベントは、state/entry-log.jsonlにJSON形式の1行として書き込まれます。このログはopenclaw sessions clear --currentを実行しても保持されます。データはLLMのコンテキストではなく、ディスク上に保存されます。セッションのリセット後に「この取引のスコアは何だった？」と尋ねられた場合、ログの末尾を確認して答えられます。

tail -20 /data/workspace/skills/wolverine-strategy/state/entry-log.jsonl | jq

4. 決済追跡フック

sync_closed_positions(wallet, state)は各スキャンの開始時に実行され、現在のポジションと前回のスキャン時のスナップショットを比較し、以前のENTRYメタデータに関連付けたEXITイベントを追加します。チョップ検出のループを完結させ、スキャナーが各取引の実現損益を把握できるようにします。

フリート標準のガードレール（すべて実装済み）

• create_positionによる自動執行（外部のアクションレイヤーは不要）
• 損益を考慮した動的な1日のエントリー上限（PR #176）
• has_resting_orders()が10分を超えた古いメイカー注文を自動キャンセル（PR #177）
• load_trade_counter()の古い日付に関するバグ修正（PR #177）
• 資産ごとのクールダウン（デフォルト180分）
• 確信度に応じたレバレッジ。上限は10倍（フリートH12監査）

主な設定

設定	値	理由
資産	HYPE	単一資産に集中し、並行して賭けない
最大ポジション数	1	集中運用
取引ごとの証拠金	50%	高い確信がある場合は資金を大きく投じる
最大レバレッジ	10倍	フリート上限（H12監査で、10倍を超えると手数料によって優位性が失われることが判明）
最小スコア	8	これを超えると確信度が本物であるとみなす
資産ごとのクールダウン	180分	取引の間隔を空ける
DSLのハードタイムアウト	240分	HYPEの利益が出る取引は、値動きが形成されるまで2～4時間かかることが多い
DSLフェーズ1の最大損失	ROE 25%	フリート標準の下限
DSLフェーズ2のティア1	+8% / 25%ロック	フリート標準より早い

⛔ エージェントの重要ルール

1. インストール先は/data/workspace/skills/wolverine-strategy/です
2. スキャナーはポジションを決済しません — すべての決済はDSLが処理します
3. 最大1ポジション — HYPEのみ
4. 監査で調整されたフリート全体のしきい値に影響するため、テストなしにスキャナーの定数を変更しないでください
5. HYPEのモメンタムシグナルには3分が適切な間隔であるため、デーモンの実行間隔を3分より短くしないでください

セットアップ

ステップ1 — インストール先

スキルは/data/workspace/skills/wolverine-strategy/に配置する必要があります。パッケージには次が含まれます。

wolverine/
├── README.md                     # User-facing summary
├── SKILL.md                      # This file (LLM-facing)
├── runtime.yaml                  # OpenClaw runtime config + DSL preset
├── config/
│   └── wolverine-config.json     # Wallet, strategy ID, chat ID
└── scripts/
    ├── wolverine-scanner.py      # Main scanner (v2.3)
    └── wolverine_config.py       # Helper module (atomic write, MCP, state I/O)

senpi-skills GitHubリポジトリから取得します。

mkdir -p /data/workspace/skills/wolverine-strategy/{config,scripts,state}

curl -s https://raw.githubusercontent.com/Senpi-ai/senpi-skills/main/wolverine/runtime.yaml \
  -o /data/workspace/skills/wolverine-strategy/runtime.yaml

curl -s https://raw.githubusercontent.com/Senpi-ai/senpi-skills/main/wolverine/SKILL.md \
  -o /data/workspace/skills/wolverine-strategy/SKILL.md

curl -s https://raw.githubusercontent.com/Senpi-ai/senpi-skills/main/wolverine/config/wolverine-config.json \
  -o /data/workspace/skills/wolverine-strategy/config/wolverine-config.json

curl -s https://raw.githubusercontent.com/Senpi-ai/senpi-skills/main/wolverine/scripts/wolverine-scanner.py \
  -o /data/workspace/skills/wolverine-strategy/scripts/wolverine-scanner.py

curl -s https://raw.githubusercontent.com/Senpi-ai/senpi-skills/main/wolverine/scripts/wolverine_config.py \
  -o /data/workspace/skills/wolverine-strategy/scripts/wolverine_config.py

ステップ2 — ウォレットとチャットIDの設定

runtime.yamlで戦略用ウォレットアドレスを設定します。

sed -i 's/${WALLET_ADDRESS}/<YOUR_STRATEGY_WALLET>/' /data/workspace/skills/wolverine-strategy/runtime.yaml
sed -i 's/${TELEGRAM_CHAT_ID}/<YOUR_TELEGRAM_CHAT_ID>/' /data/workspace/skills/wolverine-strategy/runtime.yaml

または、config/wolverine-config.jsonに直接設定します（環境変数またはruntimeプレースホルダーが設定されていない場合、スキャナーはJSONの値を使用します）。

{
  "strategyId": "your-strategy-id",
  "wallet": "0xYourStrategyWallet",
  "chatId": "your-telegram-chat-id"
}

スキャナーは環境変数WOLVERINE_WALLETとWOLVERINE_STRATEGY_IDにも対応しています。

ステップ3 — OpenClawにランタイムをインストール

openclaw senpi runtime create --path /data/workspace/skills/wolverine-strategy/runtime.yaml
openclaw senpi runtime list && openclaw senpi status

ステップ4 — 手動スキャンを1回実行して確認

python3 /data/workspace/skills/wolverine-strategy/scripts/wolverine-scanner.py

想定される結果：エラーなく終了し、JSON出力に"_wolverine_version": "2.3"が含まれます。初回の実行では、ハートビート（シグナルなし）が表示される可能性が高いですが、これは正常です。WolverineはHYPEのモメンタムが複数の条件で合致したときに動作しますが、そのような状況はまれです。

ステップ 5 — スキャナーを定期スケジュールで実行する

推奨される方法は、LLM の起動コストがゼロの、バックグラウンドで動作する bash ループです（Turbine のパターンに一致します）。

nohup bash -c 'while true; do python3 /data/workspace/skills/wolverine-strategy/scripts/wolverine-scanner.py >> /tmp/wolverine-loop.log 2>&1; sleep 180; done' > /tmp/wolverine-nohup.log 2>&1 &

# Verify the loop is running
ps aux | grep wolverine-scanner | grep -v grep
tail -5 /tmp/wolverine-loop.log

別の方法として、sessionTarget: isolated を指定して OpenClaw の cron を設定できます。sessionTarget: main は避けてください。cron がプロデューサースクリプトを直接実行せず、LLM 駆動のエージェントターンを起動する場合に料金が急増する、既知のパターンです。

運用上の注意

エントリーログの確認

Wolverine が最初の取引を行った後、構造化エントリーログを読み込んで、正確なスコア、理由、レバレッジ、結果を確認できます。

tail -10 /data/workspace/skills/wolverine-strategy/state/entry-log.jsonl | jq

ログはセッションをクリアしても保持されるため、openclaw sessions clear --current を実行した後でも「最後のエントリースコアはいくつだったか」を確認できます。

チョップ時の取引停止状態の確認

Wolverine が CHOP_LOCKED の記録を出力した場合、3 時間以内に HYPE で 2 回以上の損失が発生したことを検出し、最後の損失から 6 時間、取引を見送っています。いつ解除されるか確認するには、次を実行します。

grep CHOP_LOCKOUT /data/workspace/skills/wolverine-strategy/state/entry-log.jsonl | tail -1 | jq '.unlock_ts'

これは意図された動作であり、バグではありません。Wolverine は相場が荒れている間、資金を保護しています。

指値注文の自動キャンセルの確認

Wolverine は、10 分を超えた古い FEE_OPTIMIZED_LIMIT メーカー注文をキャンセルします。ログに Auto-cancel attempted on stale order ... と表示される場合、安全機構が正常に動作しています。

おすすめの用途

• HYPE 1 銘柄に特化したモメンタムエージェントを求める運用者
• 1 日あたり 2～4 回の取引が適切な頻度となる取引環境（高頻度取引ではない）
• サーキットブレーカーがなければ、1 日の相場の荒れで大きな損失が発生する可能性のある口座
• 手動でポジションを決済する必要がなく、エージェントによる自律管理を求める運用者

おすすめしない用途

• 複数銘柄への分散（代わりに Phoenix、Condor、または Polar を使用してください）
• 高頻度スキャルピング
• スキャナーに決済判断をさせたい場合（すべての決済は DSL が処理します）
• XYZ DEX の株式（Wolverine は HYPE のみを対象とします）

ライセンス

MIT — Copyright 2026 Senpi (https://senpi.ai).