PythagorasGoal/Old/docs/diary/2026-06-14-timing-sweep-pairs-honest.md

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.