bison-strategy

🦬 BISON v3.0.1 — 確信を持つ保有者

資産のホワイトリスト（BTC/ETH/SOL）。 確信の下限（minScore 11）。 時間による強制決済なし — すべての決済はフェーズ1＋フェーズ2の段階的な引き上げで行います。

v3.0.1（2026-05-18）— 保有資産の重複判定競合を修正＋DSLの間隔調整

運用信頼性の修正です。投資仮説の変更はありません。スコアリングの変更もありません。

確認された不具合。 2026-05-13から2026-05-17までのBison12（M192943）の監査で、ウォレットがすでに保有している資産に対し、BISON_CONVICTION の判断理由を含む 16件の create_position ENGINE_FAILURE が確認されました。これらのエラーは、重複排除されるべきだったプロデューサー生成シグナルに対して、実行時のLLMゲートが発火したものです。push_signal() がOKを返してから、次のティックで clearinghouseState を取得するまでの競合ウィンドウ中に、プロデューサーのオンチェーン heldAssets チェックが漏れていました。

修正1 — 最近のシグナルのキャッシュ（scripts/bison_config.py）。 record_signal(coin) は、成功したプッシュのたびに {coin: epoch_seconds} を state/recent-signals.json に書き込みます。main() は build_thesis() の前に was_recently_signaled(coin) を呼び出し、RECENT_SIGNAL_TTL_SEC（デフォルト180秒。一般的なALOの約定時間の約3倍）以内に確認されたコインをスキップします。スキップされたコインは、監査用にティックごとの出力の recently_signaled_skipped に記録されます。

修正2 — DSLの決済間隔を30秒から60秒に変更（runtime.yaml）。 監査では、決済成功の1～2ティック後に CLOSE_FEE_OPTIMIZED_FAILED "Reduce only order would increase position" と CLOSE_NO_POSITION のエラーがまとまって発生することも確認されました。クローズ済みポジションに関するランタイムの状態更新は、DSLの30秒間隔よりも時間がかかるため、ポジションがないHLに対してDSLがクローズを再実行していました。間隔を2倍にすることで、ランタイムがポジション状態を取得する時間を確保し、無駄なクローズ試行を半減します。根本原因（ランタイム側のポジション状態同期）はランタイムチームにエスカレーション済みです — このYAML変更は、下流での緩和策にすぎません。

この修正で解決しないこと。 DSLの状態とHLの状態が継続的に同期しない、ファントム孤立ポジションの問題です（完全な外部決済後もランタイムがポジションをオープンと見なす、またはその逆）。この種の不具合にはランタイム側での照合が必要です。プロデューサーにはDSLの状態を変更する権限がありません。

v3.0.0（2026-05-12）— 配線のみの移行

投資仮説の変更はありません。v2.1の資産ホワイトリスト、minScore 11、確信度に応じた証拠金ティア、方向判定のウォーターフォール、9コンポーネントのスコアリング、DSLプリセットはすべてそのまま維持されています。配線を6層にわたって変更しました。

1. MCPトランスポート：mcporter のサブプロセス（呼び出しごとのコールドスタートに2.5～5秒）から、senpi_runtime_helpers.SenpiClient.mcp_call() によるプロセス内HTTPS（約280ミリ秒）に変更しました。
2. シグナル発行：スキャナーが create_position を直接呼び出していました（Wolverineパターン）。現在はプロデューサーが push_signal() を介してランタイムの /signals にシグナルを発行します。ランタイムのLLMゲート付き bison_entry アクションがFEE_OPTIMIZED_LIMITでエントリーを開始し、ティアに基づくサイズ設定のために、シグナルデータの marginUsd と leverage を引き継ぎます。
3. 再入可能性：置き換えるv2のロックファイルはありません（Bison v2.xはプロデューサー側のロックなしでopenclaw cron上で動作していました）。producer_daemon がティックごとの scanner_lock を管理し、古いPIDを自動的に復旧します。
4. スケジューラー：openclaw cron（5分）から producer_daemon(interval_seconds=300) に変更しました。長時間稼働するプロセスのため、ティックごとのコールドスタートコストはゼロです。
5. リスクゲート：Pythonの MAX_DAILY_LOSS_PCT、動的スロットのPnLベース上限、資産ごとのクールダウン状態ファイルを、宣言型の risk.guard_rails ブロックに変更しました。state/trade-counter.json と state/asset-cooldowns.json はv3.0では役目を終えているため、削除できます。
6. 決済手数料：DSLの決済方式をMARKET（テイカー、0.045%）からFEE_OPTIMIZED_LIMIT（メイカー優先、0.015%、60秒のALOタイムアウト後にテイカーへフォールバック）に変更しました。エントリーの決済設定では、v2.1のALO待機ルールに従い ensure_execution_as_taker: false を維持します。

重要なルール

ルール1：プロデューサーがエントリーし、DSLが決済します。プロデューサーはポジションを決済しません。

v1.xでは投資仮説を再評価していたため、利益の出ているポジションを早期に手仕舞いしていました。v2.0でこれを削除しました。v3.0では、プロデューサーに close_position の呼び出し箇所がないため、構造上も決済できないようになっています。

ルール 2：プロデューサーは push_signal() でシグナルを送信し、ランタイムがポジションを建てます

プロデューサーは確信度に関するテーゼを評価し、client.push_signal() でシグナルを送信します。ランタイムの LLM ゲート付き bison_entry アクションは、ensure_execution_as_taker: false を指定した FEE_OPTIMIZED_LIMIT によってポジションを建てます（v2.1 の待機ルールを維持し、エントリーの ALO はメーカー約定を 30 秒待ちます）。

ルール 3：すべてのシグナルはスコアの加算要素であり、ハードゲートではありません

4H トレンド、1H トレンド、1H モメンタム、SM の方向、ファンディングはすべてポイントを加算または減算します。minScore のしきい値（v2.1 以降：11）のみがゲートです。スコア計算前にシグナルを無効にするものはありません。

ルール 4：アセットの許可リストを適用します（v2.1 以降）

デフォルトでは BTC/ETH/SOL のみです（bison-config.json の allowedAssets で設定可能）。v2.1 より前は、24 時間の想定元本取引高上位 10 件を取得していました。そのため、取引高が急増して対象に入った小型銘柄（例：5 月 4 日の ZEC）が、1 日 1 回の枠を消費していました。

ルール 5：エントリーでは ensureExecutionAsTaker = false を使用します

エントリーには ensure_execution_as_taker: false を指定した FEE_OPTIMIZED_LIMIT を使用します（v2.1 の待機ルール）。エグジットには ensure_execution_as_taker: true を使用します（クローズは必ず成立させる必要があり、テイカーへのフォールバックが安全策の最低ラインです）。

ルール 6：カスタム DSL 状態ファイルではなく、runtime.yaml の DSL プリセットを使用します

v2.x では、スキャナーの出力にハードコードされた DSL 状態テンプレートが含まれていました。v3.0 では、唯一の信頼できる情報源として、ランタイム YAML の dsl_preset ブロックを使用します。スキャナー側に DSL 状態はありません。

BISON v3.0 の取引方法

エントリー（すべてスコアの加算要素。v2.1 から維持）

シグナル	ポイント	種類
4H トレンドが一致	+3	スコア
4H トレンドが逆行	-1	スコア
1H トレンドが一致	+2	スコア
1H トレンドが逆行	-1	スコア
1H の強いモメンタム（≥1%）	+2	スコア
1H の中程度のモメンタム（≥0.5%）	+1	スコア
1H の逆行モメンタム	-1	スコア
SM が一致	+2	スコア
SM が逆行	-2	スコア
ファンディングが一致	+2	スコア
ファンディングが過密	-1	スコア
出来高が増加	+1	スコア
OI が増加	+1	スコア
RSI に余地あり	+1	スコア
RSI が極端	-1	スコア
4H モメンタム（>1.5%）	+1	スコア

最小スコア：11。最大スコア：約16。

方向の決定（優先順位順）

1. 4H トレンドの構造 → BULLISH なら LONG、BEARISH なら SHORT
2. 4H が NEUTRAL の場合 → SM の方向に従います
3. SM が NEUTRAL の場合 → 1H モメンタム（>0.5%）に従います
4. すべて NEUTRAL の場合 → シグナルなし

確信度に応じたマージン

スコア	マージン
8-9	アカウントの 25%
10-11	31%
12+	37%

プロデューサーはティアに基づいて marginUsd を計算します。シグナルデータにこれが含まれ、LLM ゲートがランタイムのペイロードに引き継ぎます。leverage も同じ方式で処理します（デフォルト 10x、最小 7x、最大 10x）。

エグジット — RatchetStop のみ

確信度に応じた変動を許容するため、DSL プリセットは意図的に広く設定されています。

• ROE +10%：ロックなし（機能していることを確認）
• +20% / +25% でロック
• +30% / +40% でロック
• +50% / +60% でロック
• +75% / +75% でロック
• ROE +100%：85% をロック — 無限トレール

フェーズ 1 の max_loss：30%。時間によるカット：hard_timeout と dead_weight_cut は無効。weak_peak_cut は維持（60 分／ピーク 3.0% で自動制限）。

リスクゲート（runtime.yaml の risk.guard_rails）

ゲート	設定	置き換え対象
max_entries_per_day	3	v2.1 の基本 1 日上限
per_asset_cooldown_minutes	120	v2.1 の cooldownMinutes
daily_loss_limit_pct	10	v2.1 の MAX_DAILY_LOSS_PCT
max_consecutive_losses	3	v2.1（暗黙）
cooldown_minutes（損失後）	30	新規（フリート標準）
drawdown_halt_pct	25	新規（フリート標準、Roach の教訓）
drawdown_reset_on_day_rollover	false	フリート標準

v2.1 の損益連動型の動的な 1 日上限（実現損益に応じて段階的に変わる、基本 3／ハード上限 6）は廃止され、静的な max_entries_per_day=3 と drawdown_halt_pct=25 に置き換えられます。保守的な上限と -25% のハードストップは維持されますが、「好調な流れに乗る」ティアは、状態ファイルなしでの信頼性を優先して採用されません。

ハードコードされた定数（設定不可）

• MAX_LEVERAGE：10
• MIN_LEVERAGE：7
• XYZ_BANNED：true（プロデューサーのスキャン段階で禁止）

オペレーターのデプロイトポロジー

Bison のランタイムとプロデューサーのペアは、オペレーターごとではなく、戦略ウォレットごとに実行されます。より多くの資金を投入したいオペレーターは、複数の戦略ウォレットをデプロイし、それぞれで独自のランタイムインスタンスと独自の bison-producer デーモンを実行します。各インスタンスは次のとおりです。

• 独自の ${WALLET_ADDRESS} を読み取ります（通常は環境変数経由）。ランタイム YAML の ${WALLET_ADDRESS} プレースホルダーは runtime create 時に解決され、プロデューサーは bison-config.json の wallet フィールドをフォールバックとして使用します。
• 独自のウォレットのオンチェーン clearinghouseState から held_assets を計算します。インスタンス間で互いのポジションが見えることはありません。
• 独自の state/recent-signals.json（インスタンスごとのキャッシュ）に書き込みます。
• 同じ SENPI_AUTH_TOKEN（オペレーター単位）を再利用します。1 人のオペレーターが、1 つの認証トークンで N 個の戦略ウォレットを実行できます。

その結果、2 ウォレットのデプロイでは資金投入額が 2 倍になり、アセット選択を並列化できます。 ウォレット A が SOL を選ぶ一方で、ウォレット B が同時に BTC を選び、相関のないエントリーを捉えられる可能性があります。各ウォレットの DSL ラチェットは独立しています。

このトポロジーは Bison の本番環境での実際の運用形態です（Predator MCP の bison-v1-0 スラッグで strategyWalletCount: 2 を参照）。これは Bison 固有の機能ではありません。senpi-trading-runtime プラグインが標準で拡張する方法であり、ウォレットごとに 1 つのランタイムを実行し、オペレーターごとに複数のウォレットを使用します。

シグナルの間隔（予想される動作）

• プロデューサーのティック： 300 秒（5 分）ごと。長時間稼働するデーモンのため、ティックごとのコールドスタートコストはかかりません。
• ティックごとにスキャンするユニバース： 最大 10 アセット。ホワイトリストでフィルタリングされます（デフォルトの BTC／ETH／SOL では 3 アセット）。
• ティックごとの MCP コスト： 約 4～7 回の呼び出し（market_list_instruments、leaderboard_get_markets、候補ごとの market_get_asset_data、保有確認用の strategy_get_clearinghouse_state）。
• シグナルの発行頻度： 通常の相場環境では 1 日あたり 0～5 件です。MIN_SCORE 11 の下限と 2 時間の per_asset_cooldown により、発行は選択的になります。
• 静かな日の特徴： 各ティックの出力は "note": "WAITING — no conviction thesis (min score 11)" で終わります。これは最も一般的な状態です。プロデューサーは稼働していますが、テーゼが発動していないだけです。
• プロデューサーが停止した疑いがある場合： audit_query({tool_name: "market_get_asset_data", user_ids: [<MID>]}) を確認してください。市場の取引時間中に 15 分以上エントリー数がゼロになった場合、デーモンが停止しており、disown で再起動する必要があります（2026-05-13 のフリートパターン）。

意思決定ログの読み方

Bison は、ランタイムの LLM ゲートを通じて、取引ごとの意思決定テレメトリーを出力します。特定の時間帯の推論チェーンを確認するには、次のようにします。

mcp__senpi-prod__audit_query({
  user_ids: ["<your Senpi MID>"],     # e.g. "M192943" for Bison12
  tool_name: "create_position",
  action_type: "create",
  limit: 50
})

各エントリーの ai_reasoning フィールドは、LLM ゲートの reasoning 出力です。通常は "BISON_CONVICTION <ASSET> <DIRECTION> - <top_score_reason>" の形式です。成功したエントリーは success: true を持ち、失敗したエントリーには error_code と error_message が含まれます。

close_position の監査クエリと組み合わせると、DSL の決済理由（weak_peak_cut、dsl_breach など）を確認できます。

監査クエリの経路は、Bison の事後検証における標準ツールです。Predator MCP では集計値（PnL、ROI、取引量）は確認できますが、取引ごとの推論は公開されません。「なぜこの取引が実行されたのか」という質問には、必ず audit_query を使用してください。

v3.0.0（2026-05-12）— 配線のみの移行

ユーザーとの会話を行う Claude セッションに関する厳格なルール

ユーザーとの会話を行う Claude セッションは、次のツールを呼び出してはなりません。 create_position、close_position、edit_position、 ratchet_stop_add、ratchet_stop_edit、ratchet_stop_delete、 cancel_order、strategy_close、strategy_close_positions。

これらのツールは、プロデューサーデーモン（エントリー経路）と DSL ラチェットエンジン（決済経路）の専用です。ユーザーとの会話を行うセッションは読み取り専用です。

オペレーター向けインストール

v2.1 からの新規インストールおよび移行コマンドについては、README.md を参照してください。

変更履歴

v3.0.0（2026-05-12）— 配線のみの移行

helpers-native（senpi_runtime_helpers）に移行しました。テーゼは一字一句そのまま維持されています。上記の 6 層の切り替えを参照してください。

v2.1 (2026-05-07)

• アセットのホワイトリスト（BTC/ETH/SOL）。v2.1 より前は出来高上位10銘柄を取得していたため、ZEC のような小型銘柄が1日の枠を消費することがありました
• minScore を 8 から 11 に変更。以前は深夜以降、平凡なセットアップで最初のシグナルが発生していましたが、現在はより確かな確信が求められます
• 単一アセットのパターンに従い、runtime.yaml で DSL の時間カットを無効化

v2.0 (2026-04-06)

• すべてのハードゲートをスコアの加点要素に変更
• Thesis exit（evaluate_held_position）を削除
• スキャナーが内部で create_position を呼び出すように変更（Wolverine パターン。v3.0 では helpers-native の push_signal に置き換え）
• 方向判定の段階的なフォールバック：4H → SM → 1H モメンタム

ライセンス

Apache-2.0 — 二次的著作物には帰属表示が必要です。Copyright 2026 Senpi (https://senpi.ai)。

スキルの帰属表示

戦略を作成する際は、呼び出しに skill_name と skill_version を含めてください。詳細は references/skill-attribution.md を参照してください。