Signal Service & Parity System — Design Spec

Date: 2026-03-21 Status: Implemented

Problem

Live trading produced -8.11% over 20 days while the backtester showed +164% on the same coins and period. Root causes:

1. Cooldown cascade — 1-bar exit timing difference shifts cooldown window, causing divergent trade sequences
2. Coverage gaps — Services start cold (6.7 days warmup), miss trades during restarts. 73% of backtest signals were never seen
3. Trail update asymmetry — Paper updates at 8h boundaries only; live and backtest use 1h

When paper and live DID overlap on the same bars, signal parity was 100% and PnL matched to 0.000%.

Solution: Canonical Signal Service

One brain computes signals for all 27 coins, tracks all position state, and emits instructions. Executors are stateless followers. Parity monitor continuously validates.

The brain uses the exact same code as the backtester:

• StreamingMS8hSignal for signals
• Same trail stop logic (1h candle iteration, same thresholds)
• Same cooldown logic (same bar counting)

If the code is the same and the data is the same, the output is the same. Parity by construction.

Architecture

• Signal Service (brain): single process, always on, all 27 coins, writes to signal_service.db
• Live Executor: stateless, per-coin threads, reads instructions, executes on Kraken
• Paper Executor: stateless, simulated execution
• Parity Monitor: brain vs backtester validation, compliance, quality, health checks

Key Files

• experiments/ms8h_live/signal_service.py — brain main loop
• experiments/ms8h_live/coin_state.py — per-coin logic
• experiments/ms8h_live/instruction_store.py — SQLite data layer
• experiments/ms8h_live/live_executor.py — Kraken executor
• experiments/ms8h_live/paper_executor.py — simulated executor
• experiments/ms8h_live/parity_monitor.py — validation