tiger-strategy

TIGER v2 — マルチスキャナーによる目標ベースの取引

5つのスキャナー。1つの目標。調整可能な積極性。機械的な決済。

理念： WOLF は本能で狩ります。TIGER は必要なものを計算し、その分だけ正確に狩ります。予算、目標、期限を与えると、積極性を自動で調整します。

---

アーキテクチャ

┌──────────────────────────────────────────┐
│           10 OpenClaw Crons              │
│  Compress(5m) Corr(3m) Momentum(5m)     │
│  Reversion(5m) Funding(30m) OI(5m)      │
│  Goal(1h) Risk(5m) Exit(5m) DSL(30s)    │
├──────────────────────────────────────────┤
│           Python Scripts                  │
│  tiger_lib.py  tiger_config.py           │
│  5 scanners / goal-engine / risk /       │
│  exit / oi-tracker / dsl-v4              │
├──────────────────────────────────────────┤
│           Senpi MCP (via mcporter)        │
│  market_list_instruments                  │
│  market_get_asset_data / market_get_prices│
│  create_position / close_position         │
│  edit_position / cancel_order             │
│  strategy_get_clearinghouse_state         │
│  leaderboard_get_markets                  │
│  account_get_portfolio                    │
├──────────────────────────────────────────┤
│           State Files                     │
│  tiger-config.json → tiger_config.py      │
│  state/{instance}/*.json (atomic writes)  │
└──────────────────────────────────────────┘

状態の流れ： OI Tracker がすべての資産をサンプリング → スキャナーがコンフルエンスに基づいてシグナルをスコアリング → Goal Engine が積極性を設定 → Agent が create_position でエントリー → DSL がトレーリングストップを管理 → Risk Guardian が制限を適用 → Exit Checker がパターン固有の決済を処理します。

---

スキルの帰属情報

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

---

クイックスタート

1. Senpi MCP が接続されていることを確認します（mcporter list に senpi が表示されます）
2. カスタム戦略を作成します：strategy_create_custom_strategy
3. ウォレットに資金を追加します：strategy_top_up
4. セットアップを実行します：

   python3 scripts/tiger-setup.py --wallet 0x... --strategy-id UUID \
     --budget 1000 --target 2000 --deadline-days 7 --chat-id 12345
   

5. references/cron-templates.md から OpenClaw cron を10個作成します

最初の1時間： OI Tracker が OI データを圧縮／平均回帰スキャナーで利用できるようにするには、約1時間分の履歴が必要です。Goal Engine と Risk Guardian はすぐに動作します。

---

5つのシグナルパターン

1. 圧縮ブレイクアウト（主要）

OI の蓄積を伴う BB スクイーズ → 価格がバンドをブレイクします。

要因	重み	しきい値
BB スクイーズ（4h）	0.25	幅 < bbSqueezePercentile（デフォルト：35パーセンタイル）
BB ブレイクアウト（1h）	0.25	価格が1h BBの外側で終値を付ける
OI の積み上がり	0.20	1時間で OI が5%超上昇
OIと価格の乖離	0.15	OI は上昇、価格は横ばい
出来高の急増	0.15	短期出来高 > 長期平均の1.5倍
RSI が極端でない	0.10	RSI 30～70
資金調達率が方向と一致	0.10	資金調達率が方向を支持
ATR が拡大	0.05	ATR > 2%

2. BTC/ETH 相関ラグ（v2 — 複数リーダー、複数ウィンドウ）

リーダー（BTC または ETH）が大きく動く → 相関性の高いアルトがまだ追随していません。

複数ウィンドウでの検出： 1h、4h、12h、24hのローリングウィンドウを、しきい値を段階的に調整（基本しきい値の1倍、1倍、1.5倍、2倍）して確認します。単一のローソク足のチェックでは見逃す継続的な値動きを検出します。

複数リーダー： BTC と ETH の両方をリーダーとして追跡します。ETH にはボラティリティが高いため、0.8倍のしきい値乗数を適用します。各リーダーには、それぞれ独自のアルトリストがあります：

• BTC アルト： SOL、DOGE、AVAX、LINK、ADA、DOT、NEAR、ATOM、FIL、INJ、SEI、SUI、TIA、JUP、WIF、PEPE、RENDER、FET、TAO、AR
• ETH アルト（エコシステム固有）：OP、ARB、MATIC、STRK、AAVE、UNI、LDO、SNX、MKR、ENS、PENDLE、EIGEN、ENA、ETHFI、DYDX、CRV、COMP、SUSHI、IMX、BLUR

スマートな重複排除： BTC と ETH が同じ方向に動いた場合、冗長性を避けるため BTC のアルトのみをスキャンします。55秒のタイムアウト内に収めるため、1回のスキャンにつき最大4銘柄のアルトを対象とします。

要因	重み	しきい値
リーダーの大きな値動き	0.20	いずれかのローリングウィンドウで btcCorrelationMovePct（デフォルト：2%）超
アルトの遅れ	0.25	ラグ比率 ≥ 0.5
出来高が静穏	0.15	アルトの出来高がまだ急増していない
RSI が安全圏	0.10	極端な値ではない
SM が一致	0.15	スマートマネーの方向が一致
高い相関性	0.10	資産がリーダーの既知のアルトリストに含まれる
十分なレバレッジ	0.05	最大レバレッジ ≥ minLeverage

ウィンドウの評価：STRONG（ラグ > 0.7）、MODERATE（0.5～0.7）、CLOSING（0.4～0.5）。

3. モメンタムブレイクアウト

出来高で確認された強い価格変動です。

要因	重み	しきい値
1h の値動き	0.25	> 1.5%
2h の値動き	0.15	> 2.5%
出来高の急増	0.20	比率 > 1.5倍
4h のトレンドが一致	0.15	値動きが4hの方向と一致
RSI が極端でない	0.10	30～70
SMA が一致	0.10	価格が SMA20 の正しい側にある
ATR が健全	0.05	> 1.5%

DSL の注記： フェーズ1の戻り幅を小さく（0.012）設定します。モメンタムの反転は急速に起こります。

4. 平均回帰

行き過ぎた資産に反転の兆候が見られる場合 → 逆張りします。

要因	重み	閾値
RSI の極端な値（4h）	0.20	rsiOverbought より大きい、または rsiOversold より小さい（必須）
RSI の極端な値（1h）	0.15	4h の値を確認
RSI のダイバージェンス	0.20	反転の方向と一致するダイバージェンス
価格の行き過ぎ	0.10	24時間で 10% を超える変動
出来高の枯渇	0.15	価格が行き過ぎる局面で出来高が減少
BB の極値	0.10	価格が BB バンドを超える
OI の偏り	0.15	OI が平均を 15% 以上上回る
ファンディングが有利	0.10	ポジションの方向でファンディングを受け取れる

5. ファンディングレート裁定

極端なファンディング → 大衆と逆方向にポジションを取り、収益を得ます。

要因	重み	閾値
極端なファンディング	0.25	年率換算で minFundingAnnualizedPct を超える（デフォルト：30%）
トレンドとの一致	0.20	SMA20 が方向を支持
RSI が安全圏	0.15	ポジションに不利な極端な値ではない
OI が安定	0.15	ファンディングの発生源が崩れていない
SM との一致	0.10	スマートマネーが同じ側にいる
日次利回りが高い	0.10	証拠金に対する日次利回りが 5% を超える
出来高が健全	0.05	日次出来高が 1,000 万ドルを超える

DSL に関する注意： リトレースの階層幅を広くします（0.02 以上）。強みは価格の方向性ではなく収益です。ファンディングが反転した場合、Risk Guardian が自動的に決済します。

---

目標エンジンと積極性

goal-engine.py は1時間ごとに実行されます。必要な日次リターンを計算し、積極性を設定します。

積極性	必要な日次レート	最小コンフルエンス	トレーリングロック	挙動
保守的	< 3%	0.75	85%	高品質なセットアップのみ、タイトなロック
通常	3-8%	0.65	70%	標準運用
高め	8-15%	0.55	50%	エントリー幅を広げ、閾値を下げる
中止	> 15%	999（なし）	90%	新規エントリーを停止し、すべての設定を厳しくする

---

DSL v4 — トレーリングストップシステム

ポジションごとの DSL 状態ファイルです。統合ランナー（dsl-v4.py）が30秒ごとにすべてのアクティブなポジションを確認します。

重要： DSL の cron は、まず TIGER の状態にある activePositions を確認する必要があります。ポジションが開いていない場合は、直ちに HEARTBEAT_OK を出力し、dsl-v4.py を呼び出さないでください。これにより、TIGER がアイドル状態のときに不要なセッションが発生するのを防ぎます。

フェーズ 1（ティア 1 前）：絶対下限。3回連続で下限に達した場合 → 決済します。最大継続時間：90分。

フェーズ 2（ティア 1 以降）：トレーリングティア。

ティア	ROE トリガー	最高値からのロック率	備考
1	5%	2%	早期の利益シグナル
2	10%	6%	モメンタムを確認
3	15%	11%	旧 T3→T4 の間隔を埋める
4	20%	16%	堅調なランナー
5	30%	25%	強いトレンド
6	40%	34%	大きな値動き
7	50%	44%	例外的な上昇
8	65%	57%	まれな領域
9	80%	72%	最大値に近い水準
10	100%	90%	ムーンロック

停滞時の利確： ROE が 8% 以上で、最高値が1時間更新されない場合 → 自動決済します。

パターン別 DSL の調整

パターン	フェーズ 1 のリトレース	ティア幅	備考
COMPRESSION	0.015（標準）	標準	偽のブレイクアウトに注意
CORRELATION_LAG	0.015	標準	絶対下限をタイトに設定 — 機会がすぐに終わる
MOMENTUM	0.012（よりタイト）	標準	反転が速い
MEAN_REVERSION	0.015	中程度	2〜3 ATR の値動きを想定
FUNDING_ARB	0.020 以上（広め）	広め	収益ベースのため、余裕が必要

---

リスク管理

ルール	上限	設定キー	デフォルト
単一トレードの最大損失	残高の 3%	maxSingleLossPct	3
日次最大損失	1日の開始時点の残高の 8%	maxDailyLossPct	8
最高値からの最大ドローダウン	15%	maxDrawdownPct	15
同時保有ポジション数の上限	2	maxSlots	2
OI 急減による決済	1時間で OI が 25% を超えて減少	oiCollapseThresholdPct	25
ファンディング反転による決済	FUNDING_ARB でファンディングが反転	—	自動
期限が近い場合	最後の24時間 → すべてのストップを厳しくする	—	自動

すべてのパーセンテージ値は整数です（5 = 5%）。

---

アンチパターン

1. 決して焦って ABORT 状態でエントリーしないでください。 ゴールエンジンが ABORT を設定するのには理由があります。
2. 決して DSL を上書きしないでください。 DSL は自動的に終了します。DSL の終了後に再エントリーしないでください。
3. 資金調達率が反転した後、決して FUNDING_ARB を維持しないでください。 その戦略の根拠は失われています。
4. 2 時間経過後、決してモメンタムを追いかけないでください。 1 時間の値動きを逃した場合は、次の機会を待ってください。
5. 4 時間足の RSI が極端な水準に達していない状態で、決してリバージョンにエントリーしないでください。 これは必須のフィルターであり、任意ではありません。
6. タイムアウトラッパーなしで、決してスキャナーを実行しないでください。 timeout 55 によって重複実行を防止します。
7. xyz: アセットをメインのスキャナーグループに決して混在させないでください。 プレスクリーナーによって group_xyz に分離され、スキャナーではハードフィルターで除外されます。

---

レジリエンスアーキテクチャ

xyz: ハード分離（3 層）

1. プレスクリーナー：xyz: プレフィックス付きのアセットを group_xyz に分離し、メイングループ a-f には混在させません
2. スキャナーのフィルタリング：すべてのスキャナーに names = {n for n in names if not n.startswith("xyz:")} ガードがあります
3. アセットごとの try/except：xyz: アセットが漏れた場合も、アセットごとのエラーハンドラーで捕捉されます

アセットごとのエラー分離

4 つすべてのスキャナー（圧縮、相関、モメンタム、リバージョン）で、アセットごとの分析ループを try/except で囲んでいます。問題のあるアセット（データ不足、API エラー、想定外の形式）がある場合、そのエラーをログに記録してスキップし、スキャンの残りは通常どおり続行します。これにより、問題のあるアセットがスキャン全体を停止させる連鎖的な障害を防ぎます。

---

API の依存関係

ツール	使用元	目的
market_list_instruments	すべてのスキャナー、oi-tracker	アセットの検出、OI、資金調達率、取引量
market_get_asset_data	すべてのスキャナー	ローソク足（1h、4h）、資金調達率
market_get_prices	correlation-scanner、risk-guardian	BTC 価格、アルトコイン価格
leaderboard_get_markets	correlation、funding スキャナー	SM の整合性
account_get_portfolio	goal-engine	ポートフォリオ残高
strategy_get_clearinghouse_state	goal-engine、risk-guardian	証拠金、ポジション
create_position	スキャナー出力を受け取ったエージェント	ポジションを開く
close_position	dsl-v4、risk-guardian、tiger-exit	ポジションを閉じる
edit_position	risk-guardian	ポジションサイズの調整

---

状態スキーマ

フィールドの説明を含む完全なスキーマについては、references/state-schema.md を参照してください。

主な状態ファイル：

state/{instanceKey}/
├── tiger-state.json              # Positions, aggression, safety, daily stats
├── dsl-{ASSET}.json              # Per-position DSL trailing stop state
├── oi-history.json               # 24h OI time-series
├── trade-log.json                # All trades with outcomes
└── scan-history/                 # Scanner output history

すべての状態ファイルには version、active、instanceKey、createdAt、updatedAt が含まれます。すべての書き込みで atomic_write() を使用します。

---

Cron の設定

すぐに使える OpenClaw の cron ペイロードについては、references/cron-templates.md を参照してください。

無通知ポリシー — 重大：cron が実行され、結果が HEARTBEAT_OK、NO_POSITIONS、またはアクション可能なシグナルなしの場合：

• Telegram に通知しないでください
• チャットで返信しないでください
• cron が実行した内容を説明しないでください
• スキャン結果を要約しないでください
• いかなる種類の出力も行わず、完全に無通知にしてください アクション可能な事象が発生した場合にのみ、チャットまたは Telegram で通知してください。対象となるのは、取引の開始、取引の終了、アグレッションの変更、リスクによる停止の発動、または対応が必要なエラーです。アイドルサイクルは完全に無通知にしてください。

すべての cron は分離して実行されます。 メインセッションの cron はありません。スキャンサイクル中に実況しないでください。ユーザーには HEARTBEAT_OK、スキャナーの推論、「システムは正常です」といったメッセージを一切表示しないでください。

#	ジョブ	間隔	スクリプト	モデルティア
0	事前スクリーナー	5 分	prescreener.py	ティア 1
1	圧縮スキャナー	5 分	compression-scanner.py	ティア 1
2	相関スキャナー	3 分	correlation-scanner.py	ティア 1
3	モメンタムスキャナー	5 分	momentum-scanner.py	ティア 1
4	リバージョンスキャナー	5 分	reversion-scanner.py	ティア 1
5	ファンディングスキャナー	30 分	funding-scanner.py	ティア 1
6	OI トラッカー	5 分	oi-tracker.py	ティア 1
7	目標エンジン	1 時間	goal-engine.py	ティア 2
8	リスクガーディアン	5 分	risk-guardian.py	ティア 2
9	決済チェッカー	5 分	tiger-exit.py	ティア 2
10	DSL 統合	30 秒	dsl-v4.py	ティア 1
11	ROAR アナリスト	8 時間	roar-analyst.py	ティア 2

ティア 1（高速／低コスト）：しきい値チェック、データ収集、DSL の計算。delivery.mode: "none" と明示的なモデル（設定済みのモデル）を指定して、isolated で実行します。 ティア 2（高性能）：アグレッションの判断、リスク判断、決済の評価。delivery.mode: "announce" と明示的なモデル（設定済みのモデル）を指定して、isolated で実行します。OpenClaw は HEARTBEAT_OK を自動的に抑制し、実際の内容のみを配信します。 DSL（Cron 10）：main セッション（systemEvent）で実行されます。ポジション状態のコンテキストが必要です。

mcporter のレート制限を避けるため、スキャナーの実行時刻は 1～2 分ずつずらしています（cron-templates.md を参照）。

---

ROAR — 再帰的最適化・調整ランタイム

ROAR は TIGER のメタオプティマイザーです。8 時間ごと（および 5 回目の取引ごとに臨時）に実行され、TIGER の取引ログを分析し、設定範囲内で実行パラメーターを調整します。ユーザーの意図（予算、目標、リスク制限）には一切手を加えません。

ROAR が調整する項目（厳格な最小値／最大値の範囲内）：

• パターンごとのコンフルエンスしきい値（0.25–0.85）
• スキャナーのしきい値（BB スクイーズのパーセンタイル、BTC 相関の値動き、年率換算ファンディング）
• フェーズごとの DSL リトレースしきい値（0.008–0.03）
• アグレッションレベルごとのトレーリングロック率

ROAR が決して変更しない項目（保護対象）：予算、目標、期限、max_slots、max_leverage、maxDrawdownPct、maxDailyLossPct、maxSingleLossPct。

ルールエンジン（6 つのルール）：

1. 10 件以上の取引で勝率が 40% 未満 → パターンのコンフルエンスしきい値を 0.05 引き上げる
2. 10 件以上の取引で勝率が 70% を超える → より多くのシグナルを捉えるため、しきい値を 0.03 引き下げる
3. 平均 DSL 決済ティアが 2 未満 → フェーズ 1 のリトレースを 0.002 緩和する（ポジションを維持する）
4. 平均 DSL 決済ティアが 4 以上 → フェーズ 1 のリトレースを 0.001 厳しくする（利益を確保する）
5. 5 件以上の取引実績があるパターンで 48 時間エントリーがない → しきい値を 0.02 引き下げる
6. 20 件以上の取引で期待値がマイナス → パターンを 48 時間無効にする（自動的に再有効化）

安全性：各サイクルで「悪化した場合は元に戻す」チェックを実行します。前回の調整以降、勝率と平均 PnL の両方が悪化している場合は、前の設定に自動的に戻します。

スクリプト：roar-analyst.py（エンジン）、roar_config.py（範囲、状態、復元ロジック）。

---

予想されるパフォーマンス

指標	目標
1日あたりの取引回数	1-4（量より質）
勝率	55-65%
プロフィットファクター	1.8-2.5
1日のリターン目標	1.5-3%（ミッション1で持続可能性を実証済み）
最適な相場状況	明確なセットアップを伴う高ボラティリティ（スクイーズ→ブレイクアウト）
最悪の相場状況	低ボラティリティのじり安・じり高（シグナルが少ない）、不安定な相場（ブレイクアウトの失敗）
手数料による損失（10倍、往復）	証拠金の約1.8%。すべての損益見積もりに織り込んでください

---

既知の制限事項

• OI 履歴の初期取得。 OI に依存するシグナルの信頼性を高めるには、スキャナーに約1時間分の OI データが必要です。
• mcporter のレイテンシー。 1回の呼び出しに約6秒かかります。スキャナーが1サイクルで処理できる資産は8件までです。
• DSL はポジション単位です。 ポジションごとに専用の DSL 状態ファイルが必要です。
• 相関スキャナーは BTC と ETH をリーダーとして追跡します。 他の資産が主導する値動き（例：SOL 主導の上昇）は検出しません。
• ファンディング裁定には忍耐が必要です。 優位性は時間とともに得られる収益です。DSL は十分に広く設定する必要があります。
• 目標エンジンは1時間ごとに再計算します。 取引の途中で積極性が変わる場合があります。

---

最適化の調整項目

調整項目	設定キー	保守的	デフォルト	積極的
コンフルエンスしきい値（NORMAL）	minConfluenceScore.NORMAL	0.75	0.65	0.55
BB スクイーズのパーセンタイル	bbSqueezePercentile	20	25	35
BTC 相関の値動き %	btcCorrelationMovePct	4	3	2
最大レバレッジ	maxLeverage	7	10	10
最大スロット数	maxSlots	1	2	3
1日の損失上限 %	maxDailyLossPct	5	8	12
トレーリングロック（NORMAL）	trailingLockPct.NORMAL	0.85	0.70	0.50
スロットあたりの証拠金 %	margin_pct_per_slot	0.25	0.30	0.40
出来高比率ゲート（モメンタム）	volume_ratio_gate.MOMENTUM	1.5	1.2	1.0

---

注意点

• maxSingleLossPct は整数です。5 は5%を意味します。
• minConfluenceScore の値は小数（0.40 = 40%）であり、整数ではありません。これは0～1の加重スコアです。
• trailingLockPct の値は小数です（0.60 = 60%をロック）。
• DSL ティアの triggerPct は ROE %（5 = ROE 5%）であり、価格 % ではありません。
• DSL の lockPct は、ロックする高値更新幅の割合であり、リトレースのしきい値ではありません。
• DSL が読み取るのは DSL_STATE_FILE 環境変数のみです。位置引数は黙って無視されます。
• cron の重複実行を防ぐため、すべてのスクリプトに timeout 55 を設定します。
• cron の開始時刻をずらすオフセット：:00 compression、:01 momentum、:02 reversion、:03 OI、:04 risk+exit。

---

実取引から得た教訓

運用

• DSL 状態ファイルの active フィールド：dsl-v4.py が {"status": "inactive"} を返すため、必ず active: true を含めてください（22行目のチェック）。新しいポジションの設定時に最もよくある落とし穴です。
• DSL の呼び出し構文：DSL_STATE_FILE=/path/to/file.json python3 scripts/dsl-v4.py COIN
• API のレイテンシー：market_get_asset_data は呼び出しあたり約4秒、market_list_instruments は約6秒です。55秒のスキャン時間内で処理できる資産は最大8件です。これは正常な動作です。これを前提に設計し、問題の原因と決めつけないでください。
• 相関スキャナーのタイムアウト：55秒以内に収めるため、1回のスキャンにつきアルトコインは最大4件です（6件から削減）。時間に敏感なラグトレードに対応するため、cron の間隔は3分に短縮しました。
• compression スキャナーのシグナル：実行可能なシグナルには breakout: true と direction の両方が必要です。圧縮スコアが高いだけでは不十分です。
• 編集のたびに必ず出口スクリプトをテストする：出口スクリプトのクラッシュは気づかれないまま実損につながります（UnboundLocalError により PUMP で約43ドルを損失）。
• コードが読み込まない設定変更に意味はありません：変更した設定キーを、利用するコードが実際に読み込んでいることを必ず確認してください。
• 取引所の SL を先に、DSL 状態はその後に設定する：エントリー直後に edit_position で取引所レベルの SL を設定してください。DSL はインテリジェンス、取引所の SL はセーフティネットです。
• 頻繁な cron 起動によるゾンビプロセス：PID 1 の下に蓄積して fork 失敗を引き起こす場合があります。必要に応じて監視し、コンテナを再起動してください。
• mcp-remote の stdio プロキシは不安定です：代わりに直接 streamable-http トランスポートを使用してください。

取引

• OI が積み上がっている圧縮資産をショートしないでください — 圧縮は上方向に解消されることが多いです。
• ポジションを重複させない：すでに active_positions にある資産のシグナルはスキップしてください。
• 反対方向への再エントリーは有効です：シグナルが強い場合、同じ資産に反対方向でエントリーするのは効果的です。
• DSL のトレーリングストップ >> 固定 TP：勝ちトレードはすべて、固定 TP なら決済されていた水準を超えて伸びました。利益を伸ばしましょう。
• 高スコアのシグナル（0.85 以上）ならブラックリストを無効にする根拠になります：元の損失が小さく、新しい方向が異なる場合は取引してください。
• create_position の形式：coin、direction、leverage、marginAmount、orderType フィールドを含む orders 配列が必要です。
• ALO 手数料の最適化：エントリーと、緊急ではない決済（停滞、時間切れ、日次目標）には、orderType: "FEE_OPTIMIZED_LIMIT" と ensureExecutionAsTaker: true を使用してください。約定ごとに約 8 bps 節約できます。MARKET は、DSL 違反による決済、リスクガーディアンのハードストップ、日次損失上限への到達、取引所レベルの SL にのみ使用してください。edit_position の取引所 SL の orderType は、必ず MARKET にしてください。
• close_position の構文：mcporter call 'senpi.close_position(...)'
• CLOSE_NO_POSITION パターン：DSL の決済呼び出しより前に、オンチェーンですでにポジションが閉じられている場合があります。エラーとして扱わず、適切に処理してください。
• ポジションサイズの決定：まず証拠金を基準に考える：per_slot_budget は、証拠金として残高の 30% に設定します。想定元本を求めるにはレバレッジを掛けます。以前の計算式（残高÷スロット数÷レバレッジ）では、PUMP で 730 ドル分を取り逃しました。
• 10 倍のレバレッジでは、往復手数料が証拠金の 1.8% を消費します：残高は価格差分ではなく、clearinghouse の accountValue から追跡してください。
• 4 時間足が乖離すると、24 時間の相関シグナルは古くなります：必ず時間足の整合性を確認してください。1 時間で反転した SEI／OP／ARB の LONG 取引で約 90 ドルを失いました。
• 出来高比が 1.2 未満の場合、モメンタムエントリーの確信度は不十分です：出来高比 0.42 の XPL は即座にストップアウトしました。設定で厳格に制限してください。
• エントリー時の RSI が 70 を超えている場合は危険信号です：FARTCOIN は RSI 70.4 でエントリーし、ROE が -13.7% になりました。RSI の制限を厳しくしました。
• 取引所の LIMIT SL は信頼できません：ストップロスには常に orderType: "MARKET" を使用してください。急な値動きでは LIMIT が失敗する可能性があります。
• 現実的な目標は大きすぎる目標に勝ります：ミッション 1（2.5 日で 18.5%、約 1 日あたり 3%）は成功しました。ミッション 3（1 日あたり 8%）は中止されました。目標は最大で 1 日あたり 1.5～3% にしてください。
• 資金が 3,000 ドルなら、3 スロットより 2 スロットが有利です：資金が少ない場合は、分散より集中が有効です。各ポジションに十分な証拠金を配分できます。