research: fade TF sweep 1m/2m/5m/10m/30m — 15m confermato, 10m in watchlist, 1m/2m chiusi

Frontiera Sharpe monotona al scendere del tf ma margine fee si assottiglia: MR02_BTC muore a fee2x a 5m (-1.70); MR02 sotto i 15m e' fee-death nel regime corrente (1m -64%). 1m: flat share ETH 25.6% + niente storia full -> chiuso. Corr col 15m live: 5m 0.46 / 10m 0.53. Fix resample unit-safe (pandas 2.x ms). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-12 20:56:15 +00:00
parent 378ec7fb43
commit 12e71d4c8b
2 changed files with 217 additions and 0 deletions
@@ -0,0 +1,57 @@
+# 2026-06-12 — FADE TF SWEEP: 1m / 2m / 5m / 10m / 30m (post-swap 15m)
+
+Richiesta utente: estendere l'analisi timeframe dei fade oltre il 15m appena
+deployato (v1.1.30). Script: `scripts/analysis/fade_tf_sweep.py`.
+Dati: parquet locale (5m/15m/30m full-history; 10m = resample dal 5m, unit-safe);
+1m/2m da Cerbero (120 giorni recenti — la storia 1m locale non esiste: esclusa
+dal refresh notturno per costo, 2m/10m non sono intervalli nativi del v2).
+
+## A. Storia completa (engine canonico, OOS da 2024-10, fee 0.10% RT)
+
+OOS Sharpe per timeframe (e OOS Sharpe a fee 2x del peggiore):
+
+| tf | MR01_BTC | MR02_BTC | MR07_BTC | MR01_ETH | MR02_ETH | MR07_ETH | worst f2x |
+|----|---------|---------|---------|---------|---------|---------|-----------|
+| 5m  | 3.66 | 1.90 | 4.12 | 5.31 | 6.54 | 5.52 | **MR02_BTC −1.70** |
+| 10m | 2.62 | 2.69 | 3.31 | 5.32 | 6.49 | 5.59 | MR02_BTC 0.32 |
+| 15m (live) | 1.94 | 2.30 | 2.37 | 4.94 | 6.40 | 4.44 | MR02_BTC 0.60 |
+| 30m | 1.35 | 2.32 | 1.56 | 3.25 | 5.23 | 2.81 | MR02_BTC 1.40 |
+
+**La frontiera è monotona**: più il tf scende, più Sharpe sale (MR01/MR07)… e più
+il margine fee si assottiglia. A fee 2x MR02_BTC muore a 5m e resta fragile a 10m.
+MR02 (donchian) fa 3-6x i trade degli altri: è la strategia più esposta al churn.
+
+## B. Finestra comune recente (2026-02-12 → 06-12, il regime CORRENTE)
+
+- **MR02 sotto i 15m è un disastro**: 1m −64%, 2m −44%, 5m −22% (fee-death).
+- **MR01 a 1m brilla** (ETH +60.6%, Sh 5.7; BTC +33.5%) ma **muore a fee 2x**
+  (unico sopravvissuto MR01_ETH +16.5%): margine troppo sottile per fidarsi.
+- Flat share a 1m: ETH 25.6%, BTC 13.3% → rischio stale-print alto (la lezione
+  del giorno: pairs-alt/XEX/PAXG).
+- Il regime recente è CALMO: anche il 5m vi è fiacco (+4.8/−22.9/+3.7 BTC).
+  I tf veloci pagano nella volatilità, non nella calma — il loro vantaggio
+  full-history viene dai regimi mossi (2021-22, 2024).
+
+## C. Correlazione col 15m live (daily, storia completa)
+
+5m↔15m media **0.46**, 10m↔15m media **0.53** (range 0.28-0.81). Diversificazione
+parziale: un eventuale ADD del 10m avrebbe senso ma è meno pulito del salto
+1h→15m (che era a 0.26).
+
+## Verdetto
+
+- **1m / 2m: CHIUSI.** Fee-margin nullo a stress, microstruttura flat pesante,
+  validazione full-history impraticabile. Non deployare mai MR02 sotto i 15m.
+- **5m: no-swap.** L'edge c'è ma MR02_BTC muore a fee 2x — viola il criterio di
+  robustezza fee che tutte le strategie deployate rispettano.
+- **10m: in WATCHLIST.** Quasi l'edge del 5m con più margine (f2x 0.32 resta
+  sotto la soglia di comfort per MR02_BTC; MR01/MR07 reggono bene). Possibile
+  ADD selettivo (solo MR01/MR07?) da gateare su PORT06 più avanti — NON ora:
+  il 15m è live da poche ore, un cambio alla volta e si lascia parlare il
+  ledger reale.
+- **15m: confermato** come ginocchio della frontiera margine-fee/rendimento.
+
+Collaterale tecnico: bug di resample scoperto e fixato nello sweep — pandas 2.x
+conserva `datetime64[ms]` da `to_datetime(unit="ms")`, quindi `.view(int64)//10**6`
+divide due volte e manda i timestamp nel 1970 (equity piatta silenziosa). Usare
+`(index - EPOCH) // pd.Timedelta(milliseconds=1)`.