# 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**.