# Cron Job: CryptoTradingBot 24h Focused Paper Fleet Review **Job ID:** a2e197df5e6a **Run Time:** 2026-06-05 22:32:27 **Schedule:** once at 2026-06-05 22:30 ## Prompt [IMPORTANT: The user has invoked the "algorithmic-trading-bot-safety" skill, indicating they want you to follow its instructions. The full skill content is loaded below.] --- name: algorithmic-trading-bot-safety description: "Safety-first engineering workflow for API-based algorithmic trading bots: dry-run gates, runtime state separation, journals, daily risk limits, kill switches, panic guards, and side-effect-free alert plans." version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [algorithmic-trading, trading-bots, risk-management, hyperliquid, safety, dry-run, testing] related_skills: [test-driven-development, github-pr-workflow, finance-system-architecture] --- # Algorithmic Trading Bot Safety Engineering Use this skill when modifying, refactoring, reviewing, or deploying an API-based crypto/market trading bot, especially one that can place live orders on an exchange such as Hyperliquid. ## Core rule Treat trading code as production-financial software. Default to **no live side effects** until safety boundaries are explicit, tested, and intentionally enabled. ## Standard workflow 1. **Start from a clean branch** - Verify git status and current branch. - Work on a feature/safety branch. - Keep remotes token-free. 2. **Use TDD for behavior changes** - Write failing tests first for entry decisions, exit decisions, risk gates, journal metrics, alert formatting, and panic guards. - Keep exchange/network calls out of unit tests. - Prefer pure functions and small dataclasses for decisions. 3. **Separate runtime data from source code** - Keep logs, journals, account health, cooldowns, reports, CSV exports, and portfolio state out of Git. - Write runtime state under a user-local runtime directory, e.g. `~/.local/state//`. - `.gitignore` runtime artifacts aggressively. 4. **Centralize configuration** - Use a typed config object loaded from JSON/env. - Include explicit flags for: - `dry_run` - `tls_verify` - `runtime_dir` - max open positions/trades - max daily loss - max daily trades - cooldown period - Default `dry_run` to true. 5. **Add an execution boundary** - Wrap exchange calls behind a small executor. - In dry-run mode, return structured intended actions without calling the exchange. - In live mode, delegate to the exchange client. 6. **Keep strategy/risk pure and testable** - Extract entry logic into a pure strategy function returning an `EntryDecision`. - Extract exit logic into a pure strategy function returning an `ExitDecision`. - Extract risk gates into a separate function returning a `RiskDecision`. - Do not bury risk checks inside a large infinite loop if they can be tested independently. 7. **Implement hard safety gates** - Kill-switch file blocks new entries. - Daily loss limit blocks new entries once realized PnL breaches threshold. - Daily trade limit blocks new entries after the configured count. - Panic-close requires an exact wallet-specific confirmation string. 8. **Journal every trading decision** - Append JSONL events for entry/exit. - Include UTC timestamp, event type, coin, side, price, size, dry-run flag, reason, realized PnL when known, and structured extras. - Daily metrics must ignore dry-run events when calculating live realized PnL. 9. **Plan alerts before sending them** - Build side-effect-free alert plans first. - Assert alert plans have `side_effects=()` in tests. - Ensure alert text never contains credentials, API keys, private keys, raw wallet secrets, or token paths. - Only after the plan boundary is green should a Telegram/email adapter perform actual sending. - For Telegram topic bots, require an explicit thread/topic ID before sending; missing topic ID should skip/fail closed. 10. **Prefer paper trading before live strategy work** - Add a paper exchange/executor that matches the subset of the real exchange interface the bot uses (`set_leverage`, `create_order`, `fetch_positions`). - Persist paper state under the runtime directory, not Git. - Keep live market-data reads separate from order execution so the bot can use live prices with simulated fills. - Distinguish `dry_run` from `paper_trading`: dry-run means no execution at all; paper trading means execution is allowed but lands in local paper state. - Collect market context for strategy learning, not blind execution - Before moving from toy paper sizes to a planned live wallet, add wallet-aware risk-based position sizing: derive notional from wallet equity, risk-per-trade percent, stop distance, leverage caps, margin/notional caps, and journal the sizing decision. See `references/risk-based-position-sizing.md`. - During paper-trading runs, collect chart/exchange context into runtime JSONL separate from the trade journal. - Include indicators such as RSI-14, SMA fast/slow, ATR-14, Bollinger bands, VWAP, funding, open interest, volume/liquidity, and derived tags. - Track source/reliability metadata for every context source; news, listings, social, or rumor-like signals are context only until measured against outcomes. - Correlate each paper/live trade to the most recent preceding context snapshot and score tags/sources by hit rate, average return, drawdown, time-in-trade, and exit reason. - With fewer than ~5 closed paper trades, report observations only; do not recommend strategy changes from tiny samples. 12. **Supervise paper runs as experiments** - Start long-lived paper bot processes under managed background process tooling, then verify the startup mode from runtime logs before reporting success. - For multi-strategy paper fleets, do not rely on a launcher that starts child processes and exits; keep a long-lived supervisor parent or tracked background process so VM/session restarts do not silently leave `0` bots running. - After a VM/network interruption, check actual process count, recent log mtimes, and exchange connectivity before interpreting missing trades as a strategy signal. - Pair a silent/script-only market-context collector with a slower LLM-backed analyst monitor that reports to the correct trading topic. - Monitor jobs must fail safe: no live orders, no config/code changes, and no strategy tuning without explicit user approval. For paper-only fleets, a watchdog may alert or restart only after explicitly verifying mode flags remain paper-only. - Prefer a read-only dashboard after journal/context/correlation are stable; dashboards should inspect runtime state only and never place orders or mutate config. - See `references/paper-fleet-supervisor-watchdog.md` for a concrete supervisor/watchdog pattern and restart-status checklist. 13. **Run strategy tournaments as isolated paper/backtest portfolios** - When comparing old Git strategies, reconstruct parameter presets instead of running historical commits directly. - Group near-duplicate commits into strategy families and label hand-picked challengers as candidates. - Give every strategy its own runtime directory, paper state, journal, metrics, logs, and PID file under `~/.local/state//experiments//`. - Include `strategy_id` in every journal event so tournament metrics and context correlation can separate outcomes. - Before launching parallel bots, cap API load: filter exchange-internal pseudo-symbols (for example `@123`), stablecoins, malformed symbols, blacklists, and illiquid assets; use a liquid whitelist and `max_scan_coins` for live paper runs. - Cache expensive baseline/indicator requests, set request timeouts, throttle repeated error logs, and use unbuffered logging for background processes. - Rank by risk-adjusted metrics (expectancy, drawdown, profit factor, win rate, time-in-trade) and keep reports observation-only for tiny samples. - When live paper signals are rare, add a side-effect-free historical replay layer with walk-forward segments, per-coin attribution, exit-reason stats, coin-leakage checks, and small parameter sweeps around the current champion. - When paper bots produce zero trades, add near-miss telemetry before loosening thresholds: record closest rejected signals, trigger distance, reject reason, and strategy ID into runtime JSONL, then surface it in the read-only dashboard. - Do not overfit only to previous bot versions: add an independent strategy lab with tested archetypes (for example momentum breakout, RSI mean reversion, trend pullback, volatility-squeeze breakout) and rank them against the same cached candles before promoting any candidate. - If the user wants to explore non-mean-reversion approaches, add a separate paper-only strategy-family sampler rather than stretching the flash-crash entry path. Use a `strategy_family` dispatch, family-specific config/env mappings, replay parity tests, and research-only dashboard labeling; see `references/non-drop-strategy-samplers.md`. - When prior human/AI development notes contain durable trading lessons, encode them as explicit paper-only candidate constraints and regression tests (for example short dead-fish exits, hard unlevered stops, early break-even snap), not as live settings. - Make long-horizon replay data quality explicit: handle API rate limits with bounded retry/backoff, use stale-cache fallback only with reporting, and mark missing/fresh/stale coin coverage. - Promote sweep winners only as new paper-only candidate presets; never live-trade from replay alone. - Add read-only dashboards after journals/reports exist; dashboards may inspect runtime state but must not place orders, mutate config, or restart bots. If the user needs phone/PC access, serve only the runtime reports directory over the Tailscale IP and make the static dashboard refresh explicit. - For long-running paper fleets after VM/network restarts, add a script-only hourly watchdog that is silent when healthy, verifies exact expected strategy IDs and paper-only env flags, avoids restart thrashing when the exchange API/DNS is down, and restarts only the focused paper fleet when processes are missing/unsafe/unexpected. Before enabling the watchdog, remove scorecard-blocked strategy IDs from the running fleet rather than wasting scan/API capacity on known losers. Use a canonical focused runner outside Git, verify actual child process environments, and probe Hyperliquid `/info` with a JSON POST such as `{"type":"meta"}` rather than a bare GET. See `references/paper-fleet-watchdog-and-focused-strategies.md` and `references/focused-paper-fleet-repair.md`. - Before live-preview/live discussion, dashboard open exposure as well as closed trades: open count, unrealized PnL, notional, margin, leverage, entry/current price, and strategy ID. Persist enough paper/live position metadata (`entryTs`, `highPrice`, `atrSlPx`, `beActive`, `trailingActive`) so restarted bots can recover exit state; conservatively reconstruct legacy positions and log throttled warnings. See `references/open-position-dashboard-restart-state.md`. - Dashboards/scorecards must not trust `bot.pid` plus `os.kill(pid, 0)` alone for `running=yes`: stale PID files can point to unrelated reused PIDs. Verify `/proc//environ` matches the exact `CTB_STRATEGY_ID`, `CTB_RUNTIME_DIR`, `CTB_PAPER_TRADING=true`, and `CTB_DRY_RUN=false`, and add a regression test using the current test-process PID as a reused stale PID. See `references/dashboard-process-identity.md`. - When the user asks for paper-bot status, trend, adjustments, or how much longer/margin before live, run a compact status review: verify process liveness and paper/live env flags, run tests if readiness is discussed, aggregate per-strategy journals, compute win rate/profit factor/PnL/coin distribution, and count true open exposure only from non-zero contracts rather than merely from `positions` keys. See `references/paper-status-review-playbook.md`. - After open-position dashboarding exists, add a read-only live-readiness scorecard before discussing live preview. Score each strategy on closed-trade sample size, win rate, profit factor, realized + unrealized PnL, max drawdown, consecutive losses, coin leakage, average journaled risk, and explicit blockers. Gate statuses as Research / Candidate / Live-preview-ready / Blocked; keep tiny samples and `research-sampler` presets in Research even when one trade looks excellent. See `references/strategy-readiness-scorecard.md`. - If paper bots make zero trades, diagnose market selectivity before changing thresholds: check process liveness, log ticks, journal count, recent rolling drawdowns versus trigger thresholds, and add near-miss telemetry before launching any looser paper-only sampler. - When adding indicator expansion packs, keep each family as a pure entry function with tests and a visible `strategy_family` preset: trend-pullback SMA/VWAP, Bollinger+RSI mean reversion, confirmed squeeze breakout, and multi-day trend investment should remain `paper-only`, `research-sampler`, `not-champion` until replay + live-paper scorecards mature. - When paper learnings point toward consolidation, create a new paper-only hybrid challenger rather than mutating the current champion in place. Preserve proven exit/risk modules, add entry-quality gates for observed loss modes (for example SMA reclaim after flash-crash drops when SL hits dominate), add explicit coin-leakage controls such as `allowed_coins`, and update launcher/watchdog/review prompts. See `references/hybrid-paper-strategy-consolidation.md`. - Paper alerting must be mode-aware: `dry_run=False` + `paper_trading=True` is `[PAPER]`, never `[LIVE]`, because paper execution intentionally simulates fills without exchange orders. - When the eventual live wallet size is known, do not treat current small paper notional as future live size. Add a pure position-sizing layer and replay/live parity around `wallet_equity_usdc`, `risk_per_trade_pct`, stop distance, leverage, margin caps, and notional caps; journal `notional_usd`, `margin_usd`, `risk_usd`, `stop_distance_pct`, and `sizing_cap` on entries. See `references/risk-based-position-sizing.md`. - When adding looser samplers, keep them isolated from champion presets: tag them `paper-only`, `research-sampler`, `not-champion`, make trade size small, keep hard stops/dead-fish timers tight, label them visibly in the read-only dashboard, and treat their results as data collection only; see `references/paper-signal-samplers.md`. - When a strategy/user describes crashes or stops in ROE terms (for example "15% crash") and coins use different leverage, normalize thresholds per coin: `required_unlevered_drop = max(strategy_flash_trigger_pct, target_roe_pct / coin_leverage)`. Record near-misses with leverage, ROE-equivalent drop, required drop, distance-to-entry, and reject reason before loosening thresholds. - For paper-only signal samplers that intentionally loosen entry thresholds, verify ROE normalization does not silently re-tighten them on low-leverage coins. Set sampler-specific `crash_roe_trigger_pct` so `target_roe_pct / coin_leverage` equals the intended unlevered trigger, map that field through launch/runtime environment, and add failing tests that assert `effective_required_drop_pct()` preserves the sampler thresholds for representative low-leverage coins such as WLD/HYPE. - For crash-frequency questions, count distinct threshold-crossing events over rolling windows, report per-coin data coverage, and flag coin leakage when events cluster in one/two alts; see `references/leverage-aware-crash-telemetry.md`. - See `references/strategy-tournament-pattern.md` for the full tournament pattern. - See `references/replay-leakage-parameter-sweep.md` for replay/leakage/sweep details. - See `references/replay-data-quality-dashboard.md` for robust candle fetching and read-only dashboard patterns. - See `references/crypto-strategy-lab-and-survival-lessons.md` for independent strategy-lab screening, flash-crash survival lessons, V64-style candidate constraints, and launcher interpreter invariants. - See `references/paper-fleet-watchdog-and-strategy-lab.md` for the concrete hourly paper-fleet watchdog pattern plus the TDD/replay pattern for adding a liquidation-reversal lab archetype. - See `references/strategy-lab-expansion-archetypes.md` for adding independent side-effect-free lab families such as relative-strength rotation, risk-managed trend-following, and Donchian/volume breakout, including RED/GREEN tests, grid coverage, replay reporting, and conservative non-promotion gates. - See `references/defensive-strategy-lab-filters.md` for tightening promising replay archetypes before paper promotion: ATR/chop guards for trend-following, market-breadth/cash guards for relative-strength rotation, grid coverage tests, and replay interpretation. - See `references/relative-strength-paper-promotion.md` for promoting a cross-sectional/relative-strength replay winner into a conservative paper-only candidate, including market-history parity, process-env verification, and read-only scorecard reporting. - See `references/non-drop-strategy-samplers.md` for adding separate paper-only strategy-family samplers such as volatility squeeze breakout, including config/env mappings and replay/live parity pitfalls. - See `references/paper-dashboard-and-near-miss-telemetry.md` for Tailscale read-only dashboard serving, static refresh loops, and zero-paper-trade / near-miss diagnostics. - See `references/open-position-dashboard-restart-state.md` for open-position exposure dashboards, unrealized PnL calculation, and restart-state recovery for active positions. 14. **Verify before committing/pushing** - Run unit tests. - Run Python compile checks. - Scan for unsafe patterns such as `verify=False`, `except Exception: pass`, stale hardcoded workspace paths, and token-bearing remotes. - Commit with a conventional message. - Push with token-safe askpass handling; if PR API returns 403 but push succeeds, provide the manual PR URL. ## Pitfalls - **Live order paths hidden inside strategy code**: separate strategy decisions from execution. - **Dry-run that still calls the exchange**: dry-run must not call `create_order`, `market_open`, or `set_leverage`. - **Runtime logs committed to Git**: trading logs and journals can contain sensitive financial data. - **TLS disabled for convenience**: do not use `verify=False` or `ssl.CERT_NONE` unless explicitly configured and documented. - **Silent exception handling**: replace `except Exception: pass` with bounded logging. - **Panic-close without confirmation**: emergency scripts need explicit, wallet-specific confirmation to prevent accidental liquidation. - **Alerting as hidden side effect**: build alert plans first, then wire actual senders behind an explicit flag/adapter. - **Telegram alerts sent to the wrong place**: require explicit chat ID and topic/thread ID; fail closed when topic ID is missing. - **Multi-strategy monitors reading only root runtime paths**: tournament/paper runs store per-strategy logs, journals, PIDs, and paper state under `runtime_dir/experiments//`; cron monitors and dashboards must aggregate those experiment paths, not just `runtime_dir/Tradeanalyse`. - **Confusing dry-run with paper trading**: dry-run should not create even simulated orders; paper trading requires dry-run off and a paper exchange on. - **Context overload becomes false confidence**: collect indicators/news/listing/social context with tags and source metadata, then score reliability against actual paper/live outcomes before using it in strategy. - **Auto-adjusting strategy too early**: with fewer than ~5 closed paper trades, collect data and state hypotheses only; do not tune parameters from anecdotes. ## Reference patterns - `references/hyperliquid-bot-safety-refactor.md` — concrete pattern from a Hyperliquid bot hardening session: config, dry-run executor, runtime paths, journal metrics, risk gate, panic guard, and PR-token caveat. - `references/market-context-paper-trading.md` — pattern for adding chart indicators, funding/open-interest context, source tags, reliability tracking, and dashboard-ready runtime files during paper-trading strategy development. - `references/paper-run-supervision.md` — pattern for launching, monitoring, and analyzing managed paper-trading runs with collector/analyst cron jobs and a read-only dashboard boundary. - `references/paper-fleet-watchdog-and-focused-strategies.md` — pattern for focusing a multi-strategy paper fleet after scorecard results and adding an hourly silent script-only watchdog that restarts only safe paper processes. - `references/hybrid-paper-strategy-consolidation.md` — pattern for turning paper-trade learnings into a new paper-only hybrid challenger, including module selection, falling-knife gates, coin-leakage controls, launcher/watchdog updates, and verification. The user has provided the following instruction alongside the skill invocation: [IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.] Du bist JARVIS im Telegram Topic 'Crypto Trading Bot' (Thread 6579). Erstelle nach dem 24h fokussierten Paper-Test einen kurzen deutschsprachigen Entscheidungsbericht. Nutze /home/agent/projects/CryptoTradingBot/Crypto_Agent als Projektverzeichnis und /home/agent/.local/state/CryptoTradingBot als Runtime. Prüfe per echten Tools: 1) aktive AutoTrader.py Prozesse und CTB_STRATEGY_ID/CTB_PAPER_TRADING/CTB_DRY_RUN; erwartete Strategien sind v59_1_frequency_boost, v60_survival, candidate_v65_signal_sampler_aggressive, candidate_v66_squeeze_breakout_sampler, candidate_v69_squeeze_breakout_confirmed, candidate_v74_relative_strength_breadth_guard, candidate_v73_multi_day_trend_investment, candidate_v62_anti_chop_context, candidate_v62_deep_capitulation, candidate_v62_quality_only, candidate_v75_hybrid_survival_squeeze. 2) Führe relevante Tests aus: .venv/bin/python -m pytest tests/test_dashboard.py tests/test_dashboard_scorecard.py tests/test_paper_scorecard_report.py tests/test_strategy_expansion_pack.py tests/test_multi_strategy_launcher.py -q. 3) Erzeuge paper_scorecard_latest.txt via .venv/bin/python paper_scorecard_report.py --output /home/agent/.local/state/CryptoTradingBot/reports/paper_scorecard_latest.txt und fasse Top-Kandidaten, Verlierer, offene Positionen und WLD/Coin-Leakage zusammen; bewerte v75 separat als konsolidierte Hybrid-Strategie. 4) Gib eine konservative Empfehlung: weiter Paper, Kandidaten reduzieren, oder nur falls Gates sehr klar erfüllt sind 'Live-preview diskutierbar' — niemals Live-Go ohne ausdrückliche User-Bestätigung. Halte es kurz und übersichtlich. ## Response **JARVIS Entscheidungsbericht — fokussierter Paper-Test** **Stand:** 2026-06-05 20:32 UTC **1) Sicherheits-/Prozesscheck** - 11/11 erwartete `AutoTrader.py` Prozesse aktiv. - Alle erwarteten Strategien laufen mit: - `CTB_PAPER_TRADING=true` - `CTB_DRY_RUN=false` - Keine fehlenden, unerwarteten oder unsicheren AutoTrader-Prozesse gefunden. **2) Tests** - Relevante Tests ausgeführt: **22 passed in 4.77s** - `paper_scorecard_latest.txt` wurde erfolgreich neu erzeugt. **3) Scorecard-Kernaussagen** **Top nach Score, aber konservativ bewertet:** - `candidate_v66_squeeze_breakout_sampler`: Score 68, PnL **+15.21**, PF 99.00, 6 closed — aber **100% WLD**, Research-Sampler / nicht Champion. - `candidate_v69_squeeze_breakout_confirmed`: Score 58, PnL **+7.13**, PF 3.62, 7 closed — aber **85.7% Coin-Leakage**, stark WLD-lastig. - `candidate_v65_signal_sampler_aggressive`: Score 58, 56 closed, PnL **+4.04**, PF 1.25 — aber Drawdown > 5 USDC, >2 Verlusttrades in Folge, Research-Sampler. - `v60_survival` und `v59_1_frequency_boost`: beide **Candidate**, je 13 closed, ca. 69% Winrate, PnL **+4.02 / +3.37**, PF **1.85 / 1.72** — aktuell die saubereren Kandidaten, aber noch nicht live-reif. **Verlierer / klare Reduktionskandidaten:** - `candidate_v62_quality_only`: 2 closed, PnL **-1.52**, 100% WLD, Research. - `candidate_v62_deep_capitulation`: 2 closed, PnL **-0.21**, 100% WLD, Research. - `candidate_v62_anti_chop_context`: 4 closed, PnL **-0.74**, PF 0.76, Sample <5. - Bereits nicht laufende Blocked/negative Alt-Kandidaten bleiben keine Fokus-Kandidaten. **Offene Positionen** - Für alle laufenden Strategien mit Paper-State: **0 offene Positionen**. - Für `candidate_v73`, `candidate_v74`, `candidate_v75` existiert noch kein Paper-State; Scorecard zeigt 0 closed / 0 open-relevante Evidenz. **WLD / Coin-Leakage** - WLD dominiert weiterhin viele Ergebnisse: - `v59` / `v60`: je 8 von 13 Trades WLD, WLD-PnL leicht negativ. - `v66`: 6/6 WLD, gesamter Gewinn aus WLD. - `v69`: 6/7 WLD. - `v65 aggressive`: 32/56 WLD, WLD-PnL negativ. - Das ist ein klares Leakage-/Robustheitsproblem: Gewinne sind teils zu stark von einem Coin-Regime abhängig. **v75 Hybrid separat** - `candidate_v75_hybrid_survival_squeeze` läuft korrekt im Paper-Modus. - Bisher: **0 closed trades**, Score 20, Research. - Bewertung: noch keine Entscheidungsgrundlage. Als konsolidierte Hybrid-Strategie weiter beobachten, aber aktuell nicht promoten. **4) Konservative Empfehlung** **Weiter Paper + Kandidaten reduzieren. Kein Live-Go. Live-preview aktuell nicht sauber diskutierbar.** Empfohlener Fokus: 1. Behalten/weiter beobachten: `v60_survival`, `v59_1_frequency_boost`, `candidate_v75_hybrid_survival_squeeze`. 2. `v66` und `v69` nur als Research-Sampler weiterlaufen lassen oder drosseln, bis Coin-Leakage reduziert ist. 3. Schwache/kleine negative v62-Varianten aus dem Fokus nehmen, um API-/Scan-Kapazität zu sparen. 4. Vor jeder Live-Preview müssen Coin-Leakage, offene Exposure-Dashboarding, größere geschlossene Samples und Drawdown-Gates klar besser aussehen. **Fazit:** Paper-Fleet technisch gesund, aber strategisch noch nicht live-reif.