# 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)`.
