name: scorpion-tracker # Runtime SCHEMA version must be major=1 per the senpi-trading-runtime # plugin. Strategy/skill is "Scorpion v4.1.0" — lives in description + # SKILL.md + _scorpion_producer_version. Do not set this to 4.x.x. version: 1.4.3 description: > SCORPION v4.1.0 — XYZ unblock + asymmetric MIN_SCORE. v4.0.2 sample (12 accepts / 1,089 rejects, 2026-04-24 → 2026-04-30) surfaced two structural breaks: 1. Producer was injecting btcMacroDirection into XYZ signal payloads. LLM gate then cited "BTC macro" as a reason to skip oil/brent — structurally irrelevant. 280 XYZ rejections / 0 accepts. v4.1 sets btcMacroDirection: NOT_APPLICABLE for XYZ signals. 2. LLM rubric said "be MORE selective for XYZ" — capped XYZ confidence at 5-6 (1 below the 7 threshold). BRENTOIL_LONG had fleet's highest avg confidence (6.03) yet 0% accept. v4.1 rewrites the rubric to evaluate XYZ on its own terms (SM dominance + 4H trend + funding + xyzPeerMomentum). v4.1 also: - Asymmetric MIN_SCORE: crypto raised 9 → 11 (score-9 crypto bled -$10.07 across 11 trades); XYZ held at 9 (no accept data). - Phase 2 tier 1 lock 30 → 50 (5% peak now locks 2.5% breakeven floor instead of 1.5%; only 1/12 trades reached P2 in sample). - DSL time cuts loosened (dead_weight 30→60, weak_peak 60→90) to let XYZ trades develop without bleeding crypto trades that were already exiting on score-9 noise. SCORPION v4.0.2 — Maker-exit timeout bumped 15s → 60s. 2026-04-24 controlled test: at 30s the ALO timed out → taker fallback. At 60s the ALO was crossed by a mild retracement → maker fill (saved 0.030% on exit). Prior to this fix, 23/23 close fills over 36h were taker. 60s is long enough for soft exits + Phase 2 trailing locks to catch maker; max_loss hard cuts in fast-moving chops may still fall through — that's a structural mismatch requiring an engine change (reprice-ladder), not a config fix. SCORPION v4.0 — Multi-Market Active Trader (v2-runtime-native rewrite). First multi-asset agent on senpi-trading-runtime v2. Replaces v3.2 which logged 43 fills / 18h / -$79.84 in Arena Week 5 despite MAX_DAILY_ENTRIES=3 — the scalp re-entry bypass logic and in-Python trade counter were silently leaking. v4.0 removes all that bookkeeping and delegates to the runtime: - Producer emits signals only (no execution, no counters, no cooldowns) - LLM gate evaluates each signal with 4TF + SM + BTC macro context - risk.guard_rails ENFORCES max_entries_per_day: 5 with no bypass - per_asset_cooldown_minutes: 120 (runtime-authoritative; no scalp re-entry shortcut path) - DSL now uses FEE_OPTIMIZED_LIMIT on EXITS — v2's biggest win for high-turnover agents. At ~40 trades/day this is the single largest P&L improvement in the migration (~$20/week in fee savings from maker-preferred exits). Thesis preserved: crypto + XYZ DEX multi-market trend-follower, SM direction gated on 4H price alignment, multi-factor score. strategy: wallet: "${WALLET_ADDRESS}" slots: 2 margin_per_slot: 250 trading_risk: moderate enabled: true risk: data_retention_hours: 72 guard_rails: daily_loss_limit_pct: 5 max_entries_per_day: 5 bypass_max_entries_per_day_on_profit: false max_consecutive_losses: 3 cooldown_minutes: 90 drawdown_halt_pct: 20 drawdown_reset_on_day_rollover: false per_asset_cooldown_minutes: 120 scanners: - name: position_tracker type: position_tracker interval: 10s - name: scorpion_signals type: external_scanner outputs: signals: true context: false config: fields: score: { type: number, required: true } isXyz: { type: boolean, required: true } reasons: { type: array, required: true } smPct: { type: number, required: true } smTraders: { type: number, required: true } priceChange4hPct: { type: number, required: true } priceChange1hPct: { type: number, required: false } contribChange15m: { type: number, required: false } contribChange1h: { type: number, required: false } contribChange4h: { type: number, required: false } btcMacroDirection: { type: string, required: false } btcMacro24hPct: { type: number, required: false } fundingRegime: { type: string, required: false } heldAssets: { type: array, required: false } recentEntryCountThisAsset: { type: number, required: false } xyzPeerMomentum: { type: number, required: false } # v4.1: count of other XYZ assets trending same direction in this scan actions: - name: position_tracker_action action_type: POSITION_TRACKER decision_mode: rule scanners: [position_tracker] - name: scorpion_entry action_type: OPEN_POSITION decision_mode: llm decision_model: "${SCORPION_DECISION_MODEL}" # REQUIRED. Pass BARE model name only — NO provider prefix. Valid: "gemini-2.5-pro", "claude-sonnet-4-20250514". INVALID: "google/gemini-2.5-pro" (OpenClaw double-prefixes → 500 Unknown model). No default by design. scanners: [scorpion_signals] min_confidence: 7 params: order_type: FEE_OPTIMIZED_LIMIT fee_optimized_limit_options: ensure_execution_as_taker: true execution_timeout_seconds: 60 # v4.0.2: 15 → 60 — 2026-04-24 live test with 60s timeout landed maker fill (vs 30s fell to taker). Entries typically non-adverse so ALO catches market easily. context: - type: signal scanner: scorpion_signals decision_prompt: | You are Scorpion's trade-decisioning evaluator. A multi-market scanner just surfaced a trend-following signal on a crypto or XYZ DEX asset. Decide whether to open a position. SIGNAL: {{signal_scorpion_signals}} ## STRICT OUTPUT RULES — DO NOT VIOLATE 1. The `asset` in your output payload MUST be the exact value from the signal's `asset` field. Do NOT substitute a different asset. If signal says "xyz:BRENTOIL", output exactly "xyz:BRENTOIL", not "BRENTOIL" and not "OIL". 2. The `direction` MUST match the signal's `direction` field exactly. 3. Every claim in `reasoning` MUST reference values that appear literally in the signal payload. Do NOT fabricate SM percentages, trader counts, or TA states. Quote actual values from the signal. 4. If a signal field is UNKNOWN or 0, do NOT describe it with confidence-inflating language ("strong", "exceptional", "deep"). Report the literal value. ## HARD SKIP CONDITIONS (output execute: false) - score < 9 (producer should filter, but skip defensively) - score < 11 AND asset is crypto (v4.1 producer floor; defensive) - BTC macro direction opposite of signal direction AND asset is crypto major (BTC, ETH, SOL) AND score < 12 — macro risk - recentEntryCountThisAsset >= 2 within 24h — over-traded - fundingRegime opposes direction in a way that makes thesis structurally broken (e.g. LONG into deep LONG_CROWDED) ## SCORPION'S THESIS Follow trends with SM conviction + 4TF price alignment across a broad crypto + XYZ universe (CL, BRENTOIL, GOLD, SPX plus ~15 crypto majors/mid-caps). Short-hold active trading — DSL manages exits, you manage entries. ## CRYPTO vs XYZ — DIFFERENT REGIMES, DIFFERENT RULES ### For crypto signals (BTC, ETH, SOL, mid-caps): - btcMacroDirection IS relevant. Apply the macro hard-skip above for crypto majors at score < 12. - fundingRegime: LONG_CROWDED is reversal risk for LONG; reduce confidence by 1. - SM thresholds: 200+ traders is "deep" for majors, 80+ for mid-caps. - v4.1 producer floor is MIN_SCORE_CRYPTO = 11. Score-9/10 crypto should not reach you — if it does, SKIP defensively. ### For XYZ signals (xyz:CL, xyz:BRENTOIL, xyz:GOLD, xyz:SPX): - **btcMacroDirection will be "NOT_APPLICABLE" — IGNORE it.** Do NOT cite BTC macro in XYZ reasoning. It is structurally irrelevant to oil, gold, and indices. - **XYZ trader pools are narrower (~80-150t at peaks).** A 12%+ SM dominance with 80+ traders on XYZ is high-conviction — proportionally equivalent to 35%+ SM on a crypto major. - **xyzPeerMomentum**: if other XYZ assets are trending the same direction in this scan (peer count >= 1), add +1 confidence — macro tailwind. Peer count 0 = isolated move, treat as standard. - **Volatility profile**: BRENTOIL/CL routinely move 4-5% per day. A 2% 4H move on oil is real momentum, not noise. Do NOT down- weight XYZ for "lower volatility" — that premise was wrong in v4.0 and produced 0% XYZ acceptance. - **XYZ confidence floor**: score 9 + SM dominant (>=12%) + 4H trend aligned (>=2%) + (peer momentum >= 1 OR funding regime supports) → confidence 7+ (execute). Don't be artificially selective on XYZ. ## OUTPUT FORMAT Return this JSON. Values must be your decisions, NOT placeholders. { "execute": true OR false, "actionType": "OPEN_POSITION", "confidence": integer 1-10, "reasoning": "concrete sentence citing specific numbers from the signal — e.g. 'score 12 LONG on ETH, 4h +4.2%, SM 18.3% DOMINANT with 67 traders, BTC macro UP +1.2%, funding LONG_CROWDED supports'", "payload": { "signals": [ { "asset": "copy signal's asset EXACTLY", "direction": "copy signal's direction EXACTLY", "reason": "one-liner citing actual score + top 2 reason labels" } ] } } ## CONFIDENCE SCORING - 9-10: score >= 12 AND all 4TFs aligned AND SM >= 12% AND (crypto: BTC macro supports / XYZ: peer momentum >= 1) - 7-8: score >= 11 (crypto) OR score >= 9 (XYZ with floor met per the XYZ confidence floor rule above) AND SM dominant AND clean 4H trend - 5-6: mixed confirmation — SKIP (does not meet min_confidence: 7) - 1-4: hard-skip condition or noise — SKIP (execute: false) Minimum confidence to execute is 7. If you cannot honestly justify >=7 citing values from the signal, output execute: false. exit: engine: dsl interval_seconds: 30 # v4.0 KEY WIN — maker-preferred exits. HL taker is 0.045%, maker # is 0.015% — saves ~0.030% on every maker-filled exit. # v4.0.2 update (2026-04-24): execution_timeout bumped 15 → 60. # Evidence: 23/23 Scorpion close fills over prior 36h were taker # (queried via HL Info API userFillsByTime). Jason ran controlled # test — 30s timeout fell to taker, 60s timeout landed maker fill. # 60s gives ALO time to be crossed by a mild retracement. Max_loss # hard cuts in fast-moving chops may still fall through; Phase 2 # trailing locks + soft exits are the big wins. order_type: FEE_OPTIMIZED_LIMIT fee_optimized_limit_options: ensure_execution_as_taker: true # maker first; fall back to taker on no-fill execution_timeout_seconds: 60 # v4.0.2: 15 → 60 — see test evidence in comment above # Short-hold DSL profile preserved from v3.2. Time cuts kept because # Scorpion is multi-asset + multi-slot: rotation opportunity cost is # real. # Note on hard_timeout behavior: Daniel's test (2026-04-23) confirmed # hard_timeout fires at its configured interval REGARDLESS of phase — # the v2 runtime-concepts.md doc that says "disabled in Phase 2" is # incorrect per implementation. hard_timeout is an outer-bound # protection, not a phase-gated patience violation. At 12h it caps # Scorpion's short-hold rotation ceiling in both phases — acceptable # for this thesis. # weak_peak_cut is effectively Phase-1-only by its own trigger logic # (min_value=2 < tier 1 trigger_pct=5, so once Phase 2 is reached # peakROE > min_value and the cut condition is mathematically # impossible). dead_weight_cut similarly fires only in Phase 1 # because ROE must be <= 0 and Phase 2 requires positive ROE. dsl_preset: hard_timeout: enabled: true interval_in_minutes: 720 # 12h forced rotation ceiling weak_peak_cut: enabled: true interval_in_minutes: 90 # v4.1: 60 → 90 — let XYZ trades grind before breaking; crypto Phase-1 noise still caught min_value: 2.0 dead_weight_cut: enabled: true interval_in_minutes: 60 # v4.1: 30 → 60 — oil consolidates 1h+ before moving; loosening costs little since v4.0.2 sample fired this on score-9 crypto noise that v4.1 producer floor (MIN_SCORE 11) now blocks phase1: enabled: true max_loss_pct: 15.0 retrace_threshold: 6 consecutive_breaches_required: 2 phase2: enabled: true tiers: - { trigger_pct: 5, lock_hw_pct: 50 } # v4.1: 30 → 50 — fix asymmetry math (5% peak now locks 2.5% breakeven floor instead of 1.5%) - { trigger_pct: 10, lock_hw_pct: 65 } # v4.1: 50 → 65 - { trigger_pct: 15, lock_hw_pct: 75 } # v4.1: 70 → 75 - { trigger_pct: 25, lock_hw_pct: 85 } - { trigger_pct: 40, lock_hw_pct: 90 } - { trigger_pct: 80, lock_hw_pct: 94 } notifications: telegram_chat_id: "${TELEGRAM_CHAT_ID}" dsl_lifecycle: true dsl_notify_sl_updates: false action_lifecycle: true