Datum: 2026-06-05 (~00:00 UTC) Modus: Read-only · 10 (Trigger, Buffer) × 3 Delay = 30 Varianten · MTF-D + 4h + Aggressive baseline Realistic Fill Model: SL/TP gap-down at open · 1-bar minimum latency Bootstrap: 1000 iter · 2h-Buckets
Wichtiges Finding: Die Aggressive-Combo-Empfehlung (BE-Gain 0.5 %) aus dem 4-Agent-Sweep ist NICHT robust unter realistischer Fill-Modellierung.
Unter realistischem Modell (gap-down-Fill + ≥1-bar Latency) bleibt Baseline 0.8 % / 0.8 % der Sieger:
| Konfiguration | N | WR | Exp % | PF | Total % | SL_LOSS | Bewertung |
|---|---|---|---|---|---|---|---|
| 0.8 / 0.8 / 1-bar lag ★ | 536 | 80.4 % | +0.303 | 2.05 | +163 | 36 | Sieger realistisch |
| 0.7 / 0.7 / 1-bar | 536 | 78.7 % | +0.241 | 1.88 | +129 | 47 | grenzwertig |
| 0.6 / 0.6 / 1-bar | 536 | 74.2 % | +0.194 | 1.77 | +104 | 54 | unterhalb Akzeptanz |
| 0.5 / 0.3 / 1-bar | 536 | 73.1 % | +0.166 | 1.71 | +89 | 55 | klar schlechter |
Δ vs. ursprüngliches optimistisches Aggressive (+251 %): −88 pp Edge-Verlust durch realistic-fill.
→ Die Aggressive-Combo war ein Backtest-Artefakt der optimistischen Fill-Annahme, nicht eine echte Strategie-Verbesserung.
Bisher (optimistisch): wenn low ≤ sl_now → Fill EXAKT bei sl_now.
Jetzt (realistisch): wenn low ≤ sl_now → Fill bei min(sl_now, bar.open).
- Wenn bar.open < sl_now (Gap-Down über Nacht oder zwischen Bars): Fill am Open, schlechter als SL.
- Verhindert dass das Backtest Gewinne bucht, die in Live nicht erreichbar wären.
In Live: Worker-Command + Binance-API-Roundtrip braucht ~1-5 s, plus Bot-Scan-Cycle ~2.5 min. delay=0 ist die realistic minimum-Annahme.
Buffer ≤ Trigger (mathematisch sinnvoll, sonst negative MFE-Distanz).
| Trigger / Buffer | Delay | N | WR | Exp % | PF | Total % | Δ Baseline | SL_LOSS | SL_PROFIT | TIMEOUT |
|---|---|---|---|---|---|---|---|---|---|---|
| 0.5 % / 0.3 % | 0 | 536 | 73.1 % | +0.175 | 1.75 | +94 | −92 | 55 | 452 | 28 |
| 0.5 % / 0.3 % | 1 | 536 | 38.4 % | +0.182 | 1.57 | +97 | −88 | 111 | 396 | 28 |
| 0.5 % / 0.4 % | 0 | 536 | 73.1 % | +0.175 | 1.75 | +94 | −92 | 55 | 452 | 28 |
| 0.5 % / 0.5 % | 0 | 536 | 73.1 % | +0.170 | 1.73 | +91 | −94 | 55 | 452 | 28 |
| 0.6 % / 0.4 % | 0 | 536 | 74.2 % | +0.200 | 1.79 | +107 | −78 | 54 | 449 | 32 |
| 0.6 % / 0.5 % | 0 | 536 | 74.2 % | +0.193 | 1.76 | +103 | −83 | 54 | 449 | 32 |
| 0.6 % / 0.6 % | 0 | 536 | 74.2 % | +0.194 | 1.77 | +104 | −82 | 54 | 449 | 32 |
| 0.7 % / 0.5 % | 0 | 536 | 78.7 % | +0.232 | 1.85 | +124 | −62 | 47 | 452 | 36 |
| 0.7 % / 0.6 % | 0 | 536 | 78.7 % | +0.231 | 1.85 | +124 | −62 | 47 | 452 | 36 |
| 0.7 % / 0.7 % | 0 | 536 | 78.7 % | +0.241 | 1.88 | +129 | −57 | 47 | 452 | 36 |
| 0.8 % / 0.8 % ★ | 0 | 536 | 80.4 % | +0.303 | 2.05 | +163 | −23 | 36 | 458 | 41 |
| 0.8 % / 0.8 % | 1 | 536 | 71.3 % | +0.272 | 1.74 | +146 | −40 | 90 | 404 | 41 |
| 0.8 % / 0.8 % | 2 | 536 | 67.0 % | +0.211 | 1.48 | +113 | −72 | 120 | 370 | 44 |
(Vollständige 30 Zeilen in be_matrix_results.json)
| Trigger | Total Net % (delay=0) | SL_LOSS | Insight |
|---|---|---|---|
| 0.5 % | ~+92 | 55 | Tight Trigger fires more, but tight Buffer = häufige SL-Hits mit gap-down-Fills |
| 0.6 % | ~+105 | 54 | etwas besser |
| 0.7 % | ~+126 | 47 | klar besser |
| 0.8 % | +163 | 36 | Sieger |
Erklärung: Bei tighterem Trigger fungiert die SL nahe an entry × 1.005 als "fast eingelöste Limit-Order". Wenn der Markt nur leicht zurückläuft, hit die SL → Gap-Down-Fill am Open (schlechter als SL-Preis) → mehr SL_LOSS.
Bei weiterem Trigger (0.8 %) fired die B-E-Gain erst bei höherem Gewinn → Buffer ist relativ zur Distanz größer → weniger SL-Retraces, bessere Fills.
→ Buffer ≪ Trigger bringt nichts. Tighter Buffer fängt das Risk nicht ab, weil Trigger schon zu früh fired.
Jede weitere Bar Latency reduziert die Edge um ~30 pp: - delay=0 (1-bar lag): +163 % - delay=1 (2-bar lag): +146 % (−17 pp) - delay=2 (3-bar lag): +113 % (−50 pp)
→ Realistische Live-Performance hängt stark von Worker-Reaction-Time ab.
| Metric | Wert |
|---|---|
| Effective Clusters | 53 |
| Bootstrap mean | +164.34 % |
| 95 %-CI low | +48.56 % |
| 95 %-CI high | +273.83 % |
| P(loss) | 0.3 % |
→ Untere CI ist deutlich gefallen von vorigem +157 % (optimistisches Aggressive) auf +49 %. P(loss) von 0 % auf 0.3 % gestiegen. Statistische Robustheit reduziert, aber immer noch klar positiv.
| Schwelle | Sieger 0.8/0.8/0 | Status |
|---|---|---|
| PF ≥ 2.0 | 2.05 | ✓ knapp |
| Expectancy ≥ Baseline | +0.303 vs +0.347 baseline (4-agent) | ✗ −0.044 pp |
| SL_LOSS ≤ 13 (4-agent baseline) | 36 | ✗ +23 |
| N ≥ 400 | 536 | ✓ |
| Realistische Fill-Annahme | ja | ✓ |
| Buffer ≤ Trigger | ja | ✓ |
Insight: Im Vergleich zum 4-Agent-Aggressive (optimistisch: Exp +0.468 %, SL_LOSS=6) ist der realistic Sieger deutlich schlechter auf den Akzeptanz-Metriken. Aber die 4-Agent-Akzeptanz war OPTIMISTISCH überzeichnet.
Fair-Compare: Im realistic Modell ist das relative Picture: - Sieger 0.8/0.8: Exp +0.303, PF 2.05, SL_LOSS 36, Total +163 % - Zweiter 0.7/0.7: Exp +0.241, PF 1.88, SL_LOSS 47, Total +129 % - Original-Aggressive 0.5/0.3: Exp +0.175, PF 1.75, SL_LOSS 55, Total +94 %
→ 0.8/0.8 ist robust überlegen in realistic conditions.
Kandidat: 0.7 % / 0.7 % / delay=0 - N=536, WR=78.7 %, Exp=+0.241 %, PF=1.88, Total=+129 % - Etwas tighter als baseline 0.8/0.8 — fires früher, fängt mehr Trades ab - −34 pp gegenüber 0.8/0.8 Sieger, aber wäre "konservativer" wenn man früher cashen will - NICHT empfohlen — Sieger ist 0.8/0.8
Es gibt keine "aggressive" Variante die besser ist als 0.8/0.8.
Tighter Trigger (0.5–0.7 %) ist konsistent schlechter. Das ist das wichtigste Reversal-Finding dieser Phase:
Die original 4-Agent-Aggressive-Combo war ein optimistic-fill-Artefakt.
In realistic conditions hat die Standard-Baseline (0.8 / 0.8) die beste Edge.
Teilweise. Bei Re-Bewertung im realistic Modell:
| Aggressive-Komponente | Im 4-Agent | Im realistic Modell |
|---|---|---|
| B-E-Gain Trigger 0.5 % | +45 pp Edge | −69 pp Edge (reversiert) |
| Partial-Sell 50 % | +5 pp | nicht erneut getestet |
| Trailing Trigger 1.5 % | +17 pp | nicht erneut getestet |
| Trailing Floor 0.3 % | +5 pp | nicht erneut getestet |
→ Die BE-Gain-Komponente der Aggressive ist NICHT mehr valide. → Die anderen 3 Komponenten (Partial-Sell, Trailing-Trigger, Trailing-Floor) müssten erneut unter realistic-fill getestet werden, bevor sie als robust gelten.
Vermutung: Trailing 1.5 % (statt 2.0 %) hat ähnliches Fill-Risiko wie BE-Trigger 0.5 % — weil Trailing-SL ebenfalls erhöht wird und gap-down-Fills produziert. Höchstwahrscheinlich auch overfit.
JA, dringender denn je.
Die realistic-fill-Analyse zeigt, dass die Aggressive-Combo aus dem 4-Agent-Sweep mit dem in-sample Bias gespielt hat. Walk-Forward (Train 4d / Test 3d) wäre die natürliche nächste Validation um zu prüfen:
Walk-Forward Plan: - Train-Window: 2026-05-28 → 2026-06-01 (4 Tage) - Test-Window: 2026-06-02 → 2026-06-04 (3 Tage) - Realistic fill model - Score: out-of-sample-Edge vs in-sample-Edge
BE-Gain Trigger: 0.8 % (BEIBEHALTEN, NICHT 0.5 %)
BE-Gain Buffer: 0.8 % (BEIBEHALTEN)
Partial Trigger: 1.5 %
Partial Sell-Pct: 50 % (vorerst beibehalten, separate Re-Validation nötig)
Trailing Trigger: 2.0 % (NICHT 1.5 % — separate Re-Validation nötig)
Trailing Floor: 0.5 % (NICHT 0.3 %)
MTF-D: 3-of-4
Hold-Window: 4h
Stablecoin/Dedup/etc: wie aktuell live
→ Effektiv: Aggressive REJECT, return zu Protected baseline. Bis Walk-Forward die einzelnen Hebel re-validiert.
| Reihenfolge | Phase | Begründung |
|---|---|---|
| 1 | WALK-FORWARD-VALIDATION-1 | Erfolgskritisch — bestätigt ob 0.8/0.8 robust out-of-sample ist |
| 2 | AGGRESSIVE-COMPONENTS-REALISTIC-RE-VALIDATION-1 | Partial-Sell-Pct + Trailing Trigger + Trailing Floor unter realistic-fill prüfen |
| 3 | BTC-MACRO-CONFIRMATION-1 | (war Reihenfolge #3) |
| 4 | REGIME-AWARE-PARAMS-1 | (war Reihenfolge #4) |
0× Code · 0× Trading-State · 0× Orders · 0× MS-Live · 0× Mainnet · 0× Env · 0× DB-Write · 0× Bot/Worker-Recreate · 0× Push · 0× Coin-Allowlist · 0× Coin-Denylist.
Erstellte Dateien:
- be_matrix_results.json — 30 Varianten + Bootstrap
- diese MD + PDF
Realistic-fill-Modell reversiert die Aggressive-Combo-Empfehlung. Sieger ist die Standard-Baseline 0.8 % / 0.8 % BE-Gain. Walk-Forward-Validation ist jetzt die unbedingt nötige nächste Phase.