PythagorasGoal/docs/diary/2026-06-09-pairs15m-port06-gate.md

2026-06-09 — ETH/BTC pairs a 15m: gate PORT06 (dal gioco Blind Traders)

Origine

Il gioco "Blind Traders" (100 agenti ciechi) ha eletto come vincitore una variante ETH/BTC pairs su 15m (config #43: n=66 z_in=1.67 z_exit=1.0 max_bars=35). Domanda: e' un vero miglioramento o un duplicato piu' veloce della sleeve PR01 ETH/BTC gia' deployata a 1h? Testato sul serio con l'engine di PRODUZIONE pairs_sim + gate PORT06. Script: scripts/analysis/pairs15m_port06_gate.py.

Risultati

• Parita' OK (corr 1.00000): l'harness riproduce esattamente il sleeve canonico PR_ETHBTC → gate affidabile.
• CORRELAZIONE 1h vs 15m = 0.349 (rendimenti giornalieri). SMENTISCE la mia ipotesi iniziale "duplicato ridondante": a 15m cattura eventi di reversione DIVERSI → e' un diversificatore reale, non una doppia scommessa sullo stesso spread.
• Robustezza 15m: griglia n×z_in → 16/16 celle Sharpe>1 (9-12), plateau non picco. Non e' un punto overfit del gioco.
• Standalone: 15m fa 9388 trade (vs 1756 a 1h), Sharpe 11.7 (vs 4.36), DD 54% (vs 48%), 8/9 anni+ . (Le % FULL sono esplose dal compounding pos0.15·lev3 su 9k trade → guardare Sharpe/DD/anni, non il livello %.)

Gate PORT06 (pos0.15 lev3 canonico, OOS da 2024-10-12)

variante ETH/BTC	FULL Sh	FULL DD	OOS Sh	OOS DD
baseline 1h	6.43	3.96	8.58	1.36
SWAP 15m	7.64	3.49	10.39	1.26
BLEND 1h+15m	7.30	3.63	9.95	1.24

A fee di backtest (0.20% RT/coppia) entrambe PROMOSSE: Sharpe su e DD giu' ovunque.

Stress slippage a livello PORT06 (il vero rischio: 15m = 5× i trade)

fee_rt	RT/coppia	PORT06 FULL Sh	FULL DD	OOS Sh	OOS DD	std Sh	std oDD
baseline 1h	0.20%	6.43	3.96	8.58	1.36	4.36	16%
15m	0.20%	7.64	3.49	10.39	1.26	11.7	13%
15m	0.40%	7.04	4.08	9.78	1.45	8.5	27%
15m	0.60%	6.43	4.67	9.15	1.66	5.3	47%

Degradazione graziosa ma reale: il vantaggio di Sharpe sopravvive fino a slippage pessimista (OOS 9.15 > 8.58 anche a 0.60%), ma il vantaggio di DD si perde gia' a 0.40% (FULL DD 4.08 > 3.96 baseline; standalone oDD esplode 13→27→47%). La regola del progetto ("ri-gateare ogni filtro quando cambiano i costi") qui taglia: la frequenza 5× rende la sleeve slippage-sensitive.

Verdetto

• NON un duplicato (corr 0.35) e NON overfit (16/16 robusto) → la mia liquidazione iniziale era SBAGLIATA, lo dico chiaro.
• Passa il gate a fee di backtest, marginale sotto slippage: migliora Sharpe sempre, ma sotto slippage realistico (≥0.40% RT) peggiora leggermente il DD di portafoglio.
• Due rischi di produzione NON ancora quantificati: (a) qualita' dati ETH 15m (14-30%/anno candele flat O=H=L=C → fill non eseguibili che gonfierebbero il backtest), (b) fill/liquidita' reale a 2 gambe a 15m (5× ordini). Il worker pairs e' validato a 1h, non a 15m.

Raccomandazione: NON swap diretto in live. Candidato promettente → percorso forward: preferire il BLEND 1h+15m (tiene il DD pulito del 1h e raccoglie il rendimento decorrelato del 15m) dopo un check sull'impatto delle candele flat 15m sui pairs. Allineato a come il progetto tratta FR01 (robusto ma non deployato finche' non domina pulito). Resta come record di ricerca; deploy solo se il check flat-candle e' pulito.

CHECK FLAT-CANDLE (pairs15m_flatcheck.py) — PULITO

Rischio: ETH 15m ha molte candele flat (O=H=L=C) → close stale che gonfia z-score → reversione FINTA non eseguibile. Test:

• Prevalenza: ETH 15m 16.4% medio (fino 30% nel 2022); BTC 15m solo 3.5%. Reale.
• Fill toccati: 12.9% degli entry e 15.2% degli exit cadono su una barra flat.
• Test decisivo (entry/exit SOLO su barre pulite, non-flat in entrambe le gambe): rimuove 11.2% dei trade, Sharpe trattenuto all'83% (11.74→9.70; OOS Sharpe 18.4). Se l'edge fosse un artefatto flat, filtrando crollerebbe → NON crolla. NON e' artefatto.
• Gate PORT06 col 15m FLAT-FILTRATO (corr 1h vs 15m-flat = 0.366, ancora decorrelato):
  • SWAP 15m-flat: FULL 7.32/3.55, OOS 9.99/1.26 → PROMOSSO
  • BLEND 1h+15m-flat: FULL 7.05/3.66, OOS 9.60/1.24 → PROMOSSO

Conclusione (3 box su 4 puliti)

✅ NON duplicato (corr 0.35-0.37) ✅ robusto (16/16) ✅ NON artefatto flat (83% Sharpe) ⚠️ slippage-sensitive: a fee backtest passa pulito; a slippage ≥0.40% RT il vantaggio di Sharpe regge ma il DD-edge si assottiglia. Il BLEND mitiga (meta' allocazione resta sul 1h pulito e slippage-robusto) → e' la forma deployabile.

Realta' del deploy (perche' NON tocco ancora il live)

Il gate passa a livello BACKTEST. Ma il live NON puo' eseguire un sleeve 15m oggi:

• la live pairs gira SOLO a 1h (PairsWorker, validato da validate_worker_pairs a 1h); il runner risampla a 1h/4h/1d, non gestisce un leg pairs a 15m.
• un BLEND richiede DUE sotto-sleeve ETH/BTC (1h + 15m) dentro il cap PAIRS, e il flat-skip va replicato nel worker live (altrimenti il live tradera' le barre stale che il backtest esclude → divergenza backtest-vs-live, la classe di bug che il progetto teme). Editare _defs.py cambierebbe solo il backtest/report, NON il live → sarebbe ingannevole. Percorso deploy corretto (da confermare): (1) estendere PairsWorker/runner al 15m + flat-skip; (2) validate_worker_pairs a 15m (replay == backtest esatto); (3) aggiungere lo sleeve 15m sotto il cap PAIRS; (4) shadow su testnet prima del paper. Finche' (1)-(2) non sono fatti e validati, resta record di ricerca PROMOSSO ma non live.