Adriano Dal Pastro
14522262e6
Reset del progetto su fondamenta verificate dopo la scoperta che l'intera libreria "validata OOS" era artefatto di feed contaminato (print fantasma del feed Cerbero TESTNET + storico Binance/USDT). - Storico ricostruito da Deribit MAINNET (ccxt pubblico, tokenless) e CERTIFICATO (certify_feed.py): BTC/ETH puliti su TUTTA la storia (mediana 2-6 bps vs Coinbase USD), integrita' OHLC + coerenza resample (maxΔ 0.00) + cross-venue OK. Alt esclusi (illiquidi/divergenti: LTC/DOGE 50-82% barre flat; XRP/BNB non certificabili). - Verdetto sul feed pulito: FADE / PAIRS / XS01 / TSM01 morti (ogni portafoglio Sharpe -2.3..-3.0, DD ~40%); solo SH01 e frammenti HONEST con segnale residuo, da ri-validare in isolamento. - Cleanup "restart pulito": strategie, stack live (src/live, src/portfolio, runner/executor, yml, docker), ~100 script ricerca/gate, waste/games/ portfolios, dati non certificati + cache e 60+ diari -> archiviati in Old/ (preservati, non cancellati). Diario consolidato in un unico documento. - Skeleton ricerca tenuto: Strategy ABC + indicatori + src/fractal + src/backtest/engine + load_data; tool dati certificati (rebuild_history, certify_feed, audit_feed, multi_source_check). - Universo dati ATTIVO: solo BTC/ETH (5m/15m/1h); guardrail fisico (load_data su alt -> FileNotFoundError). Esecuzione DISABILITATA, conto flat. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
150 lines
8.3 KiB
Markdown
150 lines
8.3 KiB
Markdown
# 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.
|