MS-LIVE-OHLCV-BACKTEST-1 — Audit & Plan

Datum: 2026-06-04 (~18:30 UTC) Modus: READ-ONLY · Audit + Backtest-Methodologie · keine Code/Order-Aktion Quelle: MS-Dry-Run-Window 2026-05-26 06:32 UTC → 2026-06-04 ≈ 9 Tage 12 h Update: ersetzt initialen Audit nach RECON-1-Cutover + 4 P0/P1-Commits

1. Ziel

Wahre Edge der 6 MS-Strategien quantifizieren, bevor MULTI_STRATEGY_DRY_RUN=false gesetzt wird. Der bisherige final_score-Proxy ist unzureichend (siehe final_score=9.1 für 100 % stable U/USDT — Score sagt nichts über tatsächliche Profitabilität).

Hartes Akzeptanzkriterium für MS-Live-Aktivierung: je-Strategie real-data-validated Win-Rate ≥ 50 % und Expectancy > 0 USDT auf historischen Candidates.

2. Settings-Snapshot (aktuell live)

MS-Pipeline

Setting	Wert	Bedeutung
`MULTI_STRATEGY_ENABLED`	True	Pipeline läuft
`MULTI_STRATEGY_DRY_RUN`	True	nur Logging, kein `execute_buy`
`MULTI_STRATEGY_TESTNET_RELAXED`	True	niedrigere Score-Schwellen für Testnet
`MULTI_STRATEGY_DRY_RUN_MAX_SYMBOLS`	10	Top-10 Universum pro Scan
`MULTI_STRATEGY_MAX_OPEN_POSITIONS`	10	Slot-Cap
`MULTI_STRATEGY_MAX_EXPOSURE_PCT`	0.40	40 % Portfolio-Exposure-Cap
`MULTI_STRATEGY_MAX_RISK_PCT`	0.02	2 % Risk-per-Trade
`MULTI_STRATEGY_TIER_HIGH/MID/LOW_PCT`	0.09 / 0.06 / 0.03	Position-Size-Tiers
`MULTI_STRATEGY_CASH_RESERVE_PCT`	0.05	5 % Cash-Floor
`MULTI_STRATEGY_FEE_BUFFER_PCT`	0.002	0.2 % Fee-Buffer
`MULTI_STRATEGY_QUOTE_ASSET`	USDT	Spot-Quote

Regime + Stability

Setting	Wert
`REGIME_STABILITY_CANDLES`	1 (MS-RELAX-1: gesenkt von 3)
`REGIME_HIGH_VOL_ATR_RATIO`	1.5
`REGIME_RANGE_EMA_SPREAD_MAX`	0.03
`TESTNET_SCORE_THRESHOLD`	6.5 (STRAT-RECON-Phase-1: gesenkt von 7.5)

NEU seit 2026-06-04 (Commit c4651dd)

Setting	Wert	Wirkung
`MS_CANDIDATE_COOLDOWN_ENABLED`	True	Repeat-Spam-Filter aktiv
`MS_CANDIDATE_COOLDOWN_SYMBOL_MIN`	120	max 1 Candidate je Symbol pro 2 h
`MS_CANDIDATE_COOLDOWN_SYMBOL_STRATEGY_MIN`	360	max 1 Candidate je Symbol+Strategy pro 6 h
Stablecoin-Block (`STABLECOIN_BASE_BLOCKLIST`)	+ RLUSD, BFUSD, XUSD, GUSD, USDB	7+ Stables vor-Strategie-Filter

Per-Strategy Toggles

Strategy	Aktiviert?	Bemerkung
trend_follow	✓	STRONG_TREND + WEAK_TREND
breakout	✓	WEAK_TREND
mean_reversion (RangeTrading-V1)	✓	RANGE (since 2026-05-31)
vwap_mean_reversion	✓ (`ENABLE_VWAP_STRATEGY=True`)	RANGE
volatility_sweep	✓	RANGE + HIGH_VOL/RANGE-base
oversold_bounce	✓ (Shadow-V1)	WEAK_TREND + RANGE

Hard-Blocks

CHOP-Regime: alle Strategien aus
HIGH_VOL ohne sauberes base_regime: alle aus
is_stable=False: alle aus

3. Datenbestand zum Backtest

Volumen

73 418 MS-Log-Records (Decisions, Errors, Heartbeats)
646 TRADE_CANDIDATEs mit voller Trade-Spec
100 % der 646 haben entry, stop_loss, take_profit gesetzt → direkter Backtest ohne Annahmen möglich
Window: 2026-05-28 07:37 UTC → 2026-06-04 15:37 UTC (≈ 7 d 8 h aktive Candidates)

Per-Strategy

Strategy	Candidates	Anteil	Zeitspanne
trend_follow	620	96.0 %	28.05 07:37 → 04.06 15:37
breakout	23	3.6 %	29.05 06:24 → 04.06 00:59
volatility_sweep	3	0.5 %	31.05 21:54 → 31.05 21:59 (alle ICP/USDT)
mean_reversion	0	0 %	— (alter N7.1 + RangeTrading-V1 hatten keine Hits)
vwap_mean_reversion	0	0 %	—
oversold_bounce	0	0 %	— (RSI<25 / RSI<30+reversal-Gate zu strikt für den Markt)

Top-Symbole pro Strategy

trend_follow: FET ×90 · MEME ×49 · TON ×45 · WLD ×42 · HBAR ×39 · ICP ×38 · POL ×36 · NEAR ×36 · MEME-cluster ×31 (TOP 9 = 70.6 % Volumen) breakout: INJ ×15 · WLFI ×8 volatility_sweep: ICP ×3 (alle in 5-min-Window am 31.05 21:54-21:59)

Sample-Size-Bewertung

Strategy	N	Statistical-Power-Bewertung
trend_follow	620	sehr stark — 99 %-CI ± ~5 % auf Win-Rate
breakout	23	schwach — 99 %-CI ± ~25 % auf Win-Rate; nur Trend-Indikation
volatility_sweep	3	unzureichend — keine statistische Aussage möglich
mean_reversion, vwap, oversold_bounce	0	kein Backtest möglich — Strategie hatte keine Hits

4. Backtest-Methodologie

4.1 Pro-Candidate-Simulation (Hauptmetrik)

Für jeden der 646 Candidates:

OHLCV-Fetch ab candidate.ts für Window N (Vorschlag: 4 h × 5 min = 48 Bars).
Bar-Walk-Forward (chronologisch):
Wenn low ≤ stop_loss UND low ≤ take_profit (gleicher Bar): konservativ als SL-HIT werten (Worst-Case-Modell).
Wenn low ≤ stop_loss: SL-HIT → outcome = (stop_loss − entry) / entry.
Wenn high ≥ take_profit: TP-HIT → outcome = (take_profit − entry) / entry.
Sonst: nächster Bar.
Time-Out: erreicht weder TP noch SL im Window → outcome bei letzter Bar-close-price (close − entry) / entry (Mark-to-Market).

4.2 Aggregat-Metriken pro Strategy

Metrik	Definition
`win_rate`	`count(outcome > 0) / count(*)`
`avg_win_pct`	`mean(outcome \| outcome > 0)`
`avg_loss_pct`	`mean(outcome \| outcome < 0)`
`expectancy_pct`	`win_rate × avg_win − (1 − win_rate) × avg_loss`
`profit_factor`	`sum(outcome > 0) / abs(sum(outcome < 0))`
`MFE_avg`	`mean(max(high − entry) / entry)` über Window
`MAE_avg`	`mean(max(entry − low) / entry)` über Window
`time_to_tp_median`	Median-Anzahl-Bars bis TP-Hit
`time_to_sl_median`	Median-Anzahl-Bars bis SL-Hit
`timeout_rate`	`count(neither TP nor SL hit) / count(*)`

4.3 Fee/Slippage-Modell

Komponente	Wert
Entry-Fee	0.1 %
Exit-Fee	0.1 %
Slippage (konservativ)	0.05 % je Seite
Total Roundtrip-Cost	0.3 %

Netto-Outcome: gross_outcome - 0.003 für TP-Hit / SL-Hit (Time-Out: 0.002 wegen einseitiger Tighter-Modell).

4.4 Dedup-Counterfactual (zwei Läufe)

Variante A — Raw: alle 646 Candidates ohne Dedup (entspricht Pre-RECON-1-Verhalten). Variante B — Post-RECON-1: Candidates nach simuliertem SYM:{symbol} 120-min + SYMSTRAT:{symbol}:{strategy} 360-min Cooldown filtern (entspricht aktuellem Bot-Verhalten ab 15:28 UTC). Schätzung: ~110 verbleibende Candidates (aus PDF-Eval).

Vergleich beider Varianten gibt Antwort: würde Dedup die Edge-Quote verbessern oder den Sample-Pool zu stark schrumpfen lassen?

4.5 Regime-Slicing

Per-regime Outcome-Breakdown: - STRONG_TREND: erwartete Edge-Konzentration - WEAK_TREND: gemischt - RANGE: nur volatility_sweep (3 Candidates → unbrauchbar) - HIGH_VOLATILITY: separate Bewertung

5. Datenquelle OHLCV

Anonyme Binance-Spot-API

GET https://api.binance.com/api/v3/klines
?symbol=XLMUSDT
&interval=5m
&startTime={ms}
&endTime={ms+4h}

Item	Wert
Rate-Limit (anonymous)	1200 req/min · 6000 req/5min
646 Candidates × 1 Fetch	≈ 33 s @ 50% Auslastung
Datenkost	0 € (Public API)
Auth nötig	Nein
Universe	Binance-Mainnet-Public (= reale historische Preise) — kein Testnet-OHLCV (Testnet hat synthetisches Spread-Modell, unbrauchbar)
Test-Symbol	XLMUSDT live-verified

Backup-Plan

Falls Rate-Limit-Issue: lokales data-fetcher-Module mit requests_cache für 24 h Cache.

6. Implementations-Skizze (out-of-scope für Audit)

# scripts/ms_live_ohlcv_backtest.py
def backtest_candidate(c, window_hours=4, bar_minutes=5):
    bars = binance_fetch(c['symbol'], c['ts'], window_hours, bar_minutes)
    for b in bars:
        if b.low <= c['stop_loss']:
            return ('SL', (c['stop_loss'] - c['entry']) / c['entry'])
        if b.high >= c['take_profit']:
            return ('TP', (c['take_profit'] - c['entry']) / c['entry'])
    return ('TIMEOUT', (bars[-1].close - c['entry']) / c['entry'])

Output: Pandas-DataFrame mit allen 646 Outcomes, Aggregat-Report pro Strategy + Regime.

Implementations-Phase wäre separat als P3-Commit ms-live-ohlcv-backtest-impl-1 mit Plan-vor-Code.

7. Erwartete Ergebnisse (qualitative Prognose)

trend_follow (620 Candidates)

Erwartung: Win-Rate 35-50 %, Profit-Factor 1.0-1.4
Begründung: Trend-Following hat strukturell niedrige Hitrate aber höhere RR
Falls Win-Rate < 35 % UND Profit-Factor < 1.0 → MS-Live für trend_follow abgelehnt
Risk-Distribution wichtig: TON-Cluster (45 Hits in kurzer Zeit) sollte 99 %-CI nicht dominieren — Cluster-Bootstrap-CI empfohlen

breakout (23 Candidates)

Sample zu klein für harte Aussage
Direktional-Indikator: wenn alle 23 verloren hätten → klares "Nein"; wenn ≥ 15 gewonnen → "Lokales Setup gut, mehr Daten nötig"

volatility_sweep (3 Candidates)

Nicht backtestbar — alle 3 in einem 5-min-Fenster, gleicher Symbol (ICP)
Empfehlung: OFF in MS-Live bis ≥ 30 Candidates akkumuliert

mean_reversion, vwap, oversold_bounce (0 Candidates)

Strategien haben in Live-Markt nie ausgelöst
Können nicht backtestet werden
Empfehlung: OFF in MS-Live + Audit der Strategy-Logic (möglicherweise zu strikte Filter)

8. Akzeptanz-Schwellen für MS-Live

Strategy	Min-N	Min-Win-Rate	Min-Expectancy	Min-Profit-Factor
trend_follow	100	35 %	+0.3 % netto	1.1
breakout	50	40 %	+0.4 % netto	1.2
volatility_sweep	30	45 %	+0.5 % netto	1.3
mean_reversion	50	50 %	+0.3 % netto	1.1
vwap_mean_reversion	50	50 %	+0.3 % netto	1.1
oversold_bounce	30	45 %	+0.4 % netto	1.2

Ein Strategy passiert MS-Live nur wenn ALLE 4 Spalten erfüllt sind.

9. Limitierungen + Bias-Vermeidung

#	Limitierung	Mitigation
1	Survivorship-Bias (Binance delisted Pairs nicht im Backtest)	Filter: nur Pairs verwenden, die heute noch handelbar sind (übereinstimmend mit Live-Universum)
2	Look-Ahead-Bias via `take_profit` aus Strategy-Code	Candidate hat SL/TP zum Zeitpunkt `ts` berechnet — kein Lookahead. ✓ sauber
3	Slippage zu optimistisch	Konservativ 0.05 % je Seite eingerechnet; bei dünnen Pairs (BFUSD/XPL) erhöhen
4	Worst-Case-SL-vor-TP bei gleichem Bar	Modell-Default; alternativ Tick-Data-Modus (out-of-scope)
5	Cluster-Korrelation (TON 45 Hits)	Cluster-Bootstrap-CI je Symbol+1h-Window
6	Backtest-Window 4 h fix	Sensitivity-Analyse mit 2 h / 8 h / 24 h
7	Pre-Cutover-Period nicht repräsentativ	Post-Cutover (15:28 UTC am 2026-06-04) Vergleichs-Run wenn ≥ 50 neue Candidates
8	Testnet-Sandbox-Quirks	Backtest auf Mainnet-OHLCV (Public), Live-Execution dann auf Testnet — Konsistenz-Annahme dokumentieren

10. Deliverables

#	Output	Format
1	Per-Candidate-CSV (646 rows × ~15 Spalten)	CSV
2	Per-Strategy-Report-Markdown	MD
3	Aggregat-PDF mit Grafiken (Win-Rate-Histogram, MFE/MAE-Scatter, Profit-Curve)	PDF
4	Roadmap-Update MS-LIVE-OHLCV-BACKTEST-1 → status=done	ROADMAP.php Edit
5	Operator-Empfehlung pro Strategy: GO/NO-GO/DEFER	Section in PDF

11. Operator-Entscheidungen vor Implementation

Q	Frage	Default-Empfehlung
Q1	Window-Größe?	B 4 h (50/50 zwischen TP-time und SL-time)
Q2	Bar-Größe?	A 5 min (genug Auflösung, Binance liefert ≥ 1000 Bars je Request)
Q3	SL-vor-TP bei gleichem Bar?	A SL-HIT (konservativ)
Q4	Fee/Slippage?	A 0.3 % roundtrip (siehe §4.3)
Q5	Dedup-Variante A (Raw) oder B (Post-RECON-1)?	C beide für Vergleich
Q6	Akzeptanz-Schwellen wie in §8?	A ja, sonst Modifikation pinnen
Q7	Implementation-Phase als nachgelagerter GO oder nun gebündelt?	A nachgelagert — Audit hier ist Read-Only-Plan
Q8	PDF-Output auf files.gewerbespeicher-rechner.de?	A ja

12. Boundaries dieses Audits

0× Code-Touch · 0× State-Edit · 0× Bot/Worker-Recreate · 0× Env-Änderung · 0× DB-Migration · 0× MS-Live-Aktivierung · 0× Mainnet · 0× Order · 0× OHLCV-Fetch (das passiert in der separaten Implementation-Phase).

13. Bisherige Erkenntnisse aus MS-LIVE-READINESS-FULL-EVAL-1 PDF (2026-06-04)

Aus dem 222-h-Audit (Vorgänger-Phase, PDF veröffentlicht 13:00 UTC):

Befund	Konsequenz für Backtest
95.8 % aller Candidates aus trend_follow	Backtest fokussiert primär auf trend_follow
3 P0-Blocker identifiziert	2 davon gefixt (DEDUP + STABLECOIN) — Variante-B-Run zeigt Wirkung
Stable-Leakage 20 Candidates (USDE/RLUSD/BFUSD)	bereits geblockt — Variante B würde diese 20 ausschließen
Sample-Konzentration (TON 45, FET 30, HBAR 32)	Cluster-Bootstrap zwingend
MS-MTF-1 Wirkung gering (17 % statt 50-70 %)	Eigener Sub-Audit "MS-MTF wirklich nötig?" möglich

14. Empfehlung

Item	Empfehlung
MS-Live-Aktivierung heute	NEIN — kein Backtest-Beleg vorliegend
Backtest-Implementation	als separater Operator-GO-Punkt MS-LIVE-OHLCV-BACKTEST-1-IMPL (P2, ≤ 2 h Aufwand)
Backtest-Run-Cadence	erstes Run heute, weekly Re-Run mit akkumulierten Daten
MS-Live-Re-Evaluation	Nach Backtest-Ergebnis: pro-Strategy GO/NO-GO/DEFER-Entscheidung
Roadmap-Status	bleibt `planned` bis Implementation-GO; Audit-Notes erweitert (siehe §16)

15. Beobachtbarer Status post-RECON-1 (Side-Channel-Beleg)

Seit RECON-1-Cutover (17:01 UTC) bis 17:42 UTC (40 min): - 174 MS-Log-Records - 0 neue TRADE_CANDIDATEs - 18 Stablecoin-Pre-Filter-REJECTs (RLUSD 12, USDE 4, EUR 2) - 0 repeat_candidate_cooldown REJECTs (kein Repeat-Trigger weil keine Candidates)

→ Markt war im Eval-Fenster aktuell trade-arm. Backtest auf vollem 9-d-Window bleibt der primäre Hebel.

16. Roadmap-Update

ROADMAP.php Task MS-LIVE-OHLCV-BACKTEST-1 wird aktualisiert: - status: weiterhin planned (Audit ist Read-Only, Implementation ist separater Schritt) - progress: 0 → 30 (Audit + Methodologie fertig, Plan-Phase abgeschlossen) - notes: ergänzt um Datenbestand-Snapshot (646 Candidates), Methodologie-Outline (§4), Akzeptanz-Schwellen (§8), Sample-Size-Bewertung (§3) - next_action: „Implementation-Phase ms-live-ohlcv-backtest-impl-1 als separater Operator-GO mit Plan-vor-Code"

PDF veröffentlicht: files.gewerbespeicher-rechner.de/MS_LIVE_OHLCV_BACKTEST_AUDIT_{TS}.pdf

STOP

Audit abgeschlossen. Keine Implementation, kein Code-Touch, kein OHLCV-Fetch. Operator-GO für MS-LIVE-OHLCV-BACKTEST-1-IMPL erforderlich, um zur tatsächlichen Backtest-Phase überzugehen.