# 2026-06-14 — Timing sweep: PAIRS & HONEST su 5/10/15/30m (vs live)

## Domanda (goal utente)

Dopo lo swap fade 1h→15m (v1.1.30), i **pairs** e le **honest** beneficiano dello stesso
trattamento — girare su timeframe più veloci (5/10/15/30 min)?

Script: `scripts/analysis/timing_sweep_pairs_honest.py` (riusa i motori canonici
`pairs_sim_flat`, replica DIP intrabar verificata == `dip_market_gated(market_n=0)`, gate
PORT06 == `pairs30m_gate`/`dip01`). Niente re-tuning dei parametri al cambio TF (anti-overfit,
come lo swap fade). Tutto netto, leva 3x, OOS held-out (da 2024-10).

## Vincolo dati (hard — definisce lo scope)

Solo **BTC/ETH** hanno 5m/15m/30m in locale (10m = resample causale da 5m). **TUTTI gli alt**
(ADA/BNB/DOGE/LTC/SOL/XRP) sono **SOLO 1h**. Quindi:
- **PAIRS:** solo **ETH/BTC** è sweepabile sub-orario. Gli altri 4 pair (gambe alt: LTC/ETH,
  ADA/ETH, BTC/LTC, ETH/SOL) restano 1h per sempre senza dati alt sub-orari.
- **HONEST:** solo **DIP01** (BTC, mean-reversion) ha senso + dati. **TR01** (trend EMA20/100 su
  4h, basket alt) e **ROT02** (rotazione dual-momentum 1d, momentum 60g, universo alt) sono lente
  (orizzonte multi-giorno/mese) E multi-asset-su-alt → sub-orario **infattibile** (dati) e
  **insensato** (momentum a 60 giorni su barre da 5 min). Nessuno sweep.

## Flat-share (print stale O=H=L=C, = rischio fill) — sale al scendere del TF

| asset | 5m | 10m | 15m | 30m | 1h |
|-------|----|-----|-----|-----|-----|
| BTC | 10.0% | 4.8% | 3.5% | 1.5% | 0.9% |
| ETH | **29.0%** | 17.3% | 16.4% | 9.0% | 6.7% |

ETH 5m al 29% è un allarme operativo serio. Nota: **30m ETH (9%) < 15m (16.4%)** → il 30m ha
*meno* rischio stale-print del 15m già live.

## PAIRS ETH/BTC — il vero free-lunch

Config UNIVERSALE 1h (n=50, z_in=2.0, z_exit=0.75, max_bars=72), flat_skip live-realizable:

| tf | Sharpe FULL | OOS Sh | OOS Sh fee2x | CAGR | win% |
|----|-------------|--------|--------------|------|------|
| 5m | 9.54 | 17.19 | 11.98 | 2071% | 56.0 |
| 10m | 9.26 | 16.54 | **13.03** | 1214% | 64.1 |
| 15m (live) | 8.10 | 14.40 | 11.74 | 673% | 66.7 |
| 30m | 6.20 | 11.17 | 9.59 | 312% | 71.7 |
| 1h (live) | 3.74 | 7.11 | 6.19 | 119% | 72.4 |

(I CAGR a quattro cifre sono compounding leva su singolo sleeve, irrealistici — il portafoglio
normalizza/cappa; il segnale robusto è lo **Sharpe** e il **gate PORT06**.)

- Sharpe **monotono** al scendere del TF, e **regge le fee 2x** (a differenza delle fade, dove
  MR02 muore a 5m). Pairs market-neutral: lo spread rientra più spesso ad alta frequenza, e
  ETH/BTC è la coppia più liquida.
- Corr daily fra TF: 5m↔1h 0.28, 10m↔1h 0.32, 30m↔1h 0.51; 10m↔15m 0.67 → i TF veloci sono
  **fasi diverse dello stesso edge**, diversificanti, non duplicati.

**Gate PORT06 (add half-size al BLEND 1h+15m, OOS da 2024-10):**

| config | FULL Sh | FULL DD% | OOS Sh | OOS DD% | verdetto |
|--------|---------|----------|--------|---------|----------|
| ATTUALE (1h+15m) | 8.13 | 2.47 | 10.86 | 2.09 | — |
| +30m | 8.24 | 2.28 | 10.87 | 1.97 | **MIGLIORA** (già `pairs30m_gate`, mai deployato) |
| +10m | 8.44 | 2.28 | 11.04 | **1.92** | **MIGLIORA** (domina tutto) |
| +5m | 8.52 | 2.30 | 11.00 | 1.95 | **MIGLIORA** (FULL Sh max) |

Tutte e tre dominano su FULL Sh, FULL DD, OOS Sh, OOS DD. **10m** è il candidato più pulito
(miglior OOS DD, flat-share moderato 17%); **30m** è il più sicuro (flat-share 9% < 15m live).

## DIP01 (BTC) — più veloce, ma lo swap NON domina

Engine canonico (n=50, z_in=2.5, sl_atr=2.5, max_bars=24), parità 1h verificata:

| tf | OOS Sh BTC | OOS Sh fee2x BTC | corr↔1h | OOS Sh ETH |
|----|------------|------------------|---------|------------|
| 5m | 4.91 | 2.41 | 0.13 | 8.43 |
| 10m | 3.47 | 1.99 | 0.17 | 6.51 |
| 15m | 2.40 | 1.40 | 0.22 | 4.49 |
| 30m | 1.34 | **0.77** | 0.41 | 3.54 |
| 1h (live) | 1.69 | 1.36 | — | 2.68 |

Standalone Sharpe sale al scendere del TF e i TF veloci sono **fortemente diversificanti**
(corr 0.13–0.22 con l'1h). MA: **BTC fee-fragile** (30m f2x 0.77), e il **gate-swap non domina**:

| config | FULL Sh | FULL DD% | OOS Sh | OOS DD% |
|--------|---------|----------|--------|---------|
| DIP01 1h (live) | 8.13 | 2.47 | 10.86 | 2.09 |
| DIP01 30m | 8.16 | 2.27 | 10.78 | 2.03 |
| DIP01 15m | 8.16 | 2.30 | 10.82 | 2.14 |
| DIP01 10m | 8.31 | 2.49 | 10.85 | 2.15 |
| DIP01 5m | 8.46 | 2.27 | 11.02 | 2.16 |

Tutti migliorano i FULL ma **alzano l'OOS DD** (e 30m abbassa l'OOS Sharpe) → nessuno domina
sui 4 criteri. DIP01 5m dà il miglior OOS Sharpe (11.02) ma OOS DD 2.16 vs 2.09. La bassa corr
suggerirebbe un **ADD** (DIP01 5m come secondo sleeve diversificante) più che uno swap, ma
aumenta la concentrazione BTC-rev e non è il free-lunch netto che sono i pairs.

## Caveat (perché backtest ≠ via libera a scalare)

1. **Slippage su feed flat-alto** = il vero banco di prova, già flaggato per il 15m blend
   ("il vero banco di prova è il ledger reale shadow"). A 5m/10m è peggio (ETH 5m 29% flat).
   Il backtest usa flat_skip (timing live-realizable) ma NON modella lo slippage attorno ai
   print stali. → gateare via shadow ledger PRIMA di sizing, specie il 5m.
2. **OOS = un solo regime** (2024-10→, calmo). Lo Sharpe monotono-col-TF può essere in parte
   un artefatto di regime calmo (la MR veloce prospera nel range a bassa vol; lo sweep fade
   trovò "i tf veloci pagano nella volatilità, non nella calma"). I pairs sono market-neutral
   → meno esposti dei fade ai crash direzionali, ma il caveat resta.

## Verdetto del backtest (gate full + OOS 2024→)

- **PAIRS ETH/BTC: il gate diceva SÌ.** Estendere il BLEND con TF più veloci migliorava PORT06
  su tutte le metriche (10m domina, 30m il più sicuro, 5m FULL Sh max), fee-2x robusto.
- **DIP01: marginale.** Più veloce è diversificante ma lo swap non domina e BTC è fee-fragile.
- **TR01/ROT02: NO.** Dati alt 1h-only + orizzonte lento → fuori scope per costruzione.

## Tentativo di deploy → due muri, NESSUN deploy (2026-06-14)

L'utente ha scelto di deployare un blend pairs ETH/BTC più veloce. Il wiring è stato fatto e
validato (sleeve def, backtest face, worker replay == backtest esatto, regression-lock
aggiornato) PRIMA di scoprire due blocchi che hanno ribaltato la decisione:

1. **MURO FEED (30m e 10m).** Il feed live **Cerbero v2 (`/mcp/tools/get_historical`) serve
   solo 5m/15m/1h** — il 30m e il 10m danno 400 in OGNI formato (30m/30/30min/1800), e
   l'endpoint legacy è 404 (rimosso). La voce `"30m"` in `runner._SUBHOURLY` era **speculativa,
   mai testata live**. → un blend 30m/10m NON è drop-in: richiede di derivarlo resamplando il
   feed 15m/5m nel runner (modifica al data-path live condiviso). **Lezione: il _SUBHOURLY del
   runner ≠ ciò che il feed serve davvero — smoke-testare il fetch prima di promettere un TF.**

2. **MURO REGIME (5m).** Il 5m è l'unico TF veloce nativo (drop-in), ma il gate full-history
   (Sharpe 9.54) è un **relitto dei regimi volatili vecchi**. Nel regime ATTUALE è il PEGGIORE
   (ETH/BTC pairs half-size, ret%/Sharpe/DD):

   | tf | ultimi 30g | ultimi 90g | ultimi 180g |
   |----|-----------|-----------|------------|
   | 5m | −10.5% / −11.5 / 11.6% | −2.0% / −0.2 / 14.1% | +78% / 2.93 / **19.5%** |
   | 15m | −4.4% / −6.2 / 5.8% | −3.1% / −0.9 / 5.8% | +56% / 3.80 / 7.9% |
   | 1h | −1.0% / −1.1 / 3.0% | +3.0% / +1.3 / 3.0% | +25% / **3.95** / 3.0% |

   Il 5m perde su ogni finestra recente e ha **DD 3-6× il 1h**; persino sui 180g il suo Sharpe
   (2.93) è SOTTO 15m/1h. Sommato al **flat-share ETH 5m 29%** (slippage reale, non modellato
   dal backtest) e al fatto che girerebbe **reale**, il guadagno modesto di backtest (FULL
   Sharpe +0.39) non vale il rischio. **5m: non conviene.**

**ESITO: nessun deploy. Config live invariata (19 sleeve, pairs 1h+15m).** I file tracciati
ripristinati a HEAD; restano solo questo diario + `timing_sweep_pairs_honest.py` come record.

**Lezione di metodo:** il gate PORT06 full+OOS è necessario ma non sufficiente — va incrociato
con (a) la fattibilità del FEED live e (b) il regime RECENTE. Un edge full-history può essere
un relitto di volatilità passata; "più veloce = più Sharpe storico" si rovescia in "più veloce
= più DD nel regime calmo attuale". Se in futuro si vorrà un blend più veloce: il **30m** resta
il migliore on-paper (flat 9%), ma serve prima derivarlo dal 15m nel runner + ri-verificarlo
nel regime del momento.