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>
2.6 KiB
2026-06-09 — ETH/BTC 15m: analisi di robustezza (il limite è il COSTO)
Domanda: lo sleeve PR_ETHBTC_15M (attivato in real, v1.1.16) è robusto? Risposta dai
dati: sì su parametri, tempo e qualità-dati; fragile sui COSTI — e quel limite è
strutturale (alta frequenza). Engine pairs_research.pairs_sim_flat (live-realizable).
✅ Robusto su parametri, tempo, dati
- Plateau parametrico: griglia n×z_in (40-80 × 1.5-2.5) → 16/16 celle Sharpe>1
(range 9-12). Non un picco overfit. (
pairs15m_port06_gate.py) - Consistenza temporale: 2018-2021 +1874% (3/4 anni+, solo 2018 negativo); 2022-2026 +12958% (5/5 anni+); OOS ultimo 30% Sharpe 17.6, DD 13%, +. L'edge è distribuito, non un singolo regime.
- Non artefatto dei dati: filtrando le candele flat ETH 15m (16% storico) resta
l'83% dello Sharpe (
pairs15m_flatcheck.py). - Decorrelato dal 1h (corr rendimenti giornalieri 0.37): segnale diverso, non un relabel.
❌ Fragile sui COSTI — il vero tallone (frequenza 5× il 1h)
Sharpe in funzione del costo all-in RT/coppia (fee + slippage):
| costo RT/coppia | 15m Sharpe | 1h Sharpe |
|---|---|---|
| 0.20% (reale, 1×) | 9.34 | 4.36 |
| 0.40% (2×) | 6.15 | 3.52 |
| 0.60% (3×) | 2.95 | 2.68 |
| 0.80% (4×) | −0.24 | 1.84 |
| 1.20% (6×) | −6.63 | 0.16 |
Il 1h regge ~6× i costi; il 15m va negativo già a ~4×. Tanti trade piccoli (8453 vs 1756) → margine di costo sottile. Lo Sharpe 9.34 è un numero a costo basso: appena lo slippage reale a 2 gambe porta l'all-in verso 0.40-0.60%, scende a 3-6 (ancora positivo, ma l'edge enorme del backtest è in gran parte illusione da bassi costi).
Implicazioni (coerenti con la config deployata)
- La mezza size era giusta: non si dà al 15m il peso che il backtest a costo basso suggerirebbe. È un blend-tilt, non una scommessa.
- NO allo swap (togliere il 1h, tenere solo 15m): sostituirebbe l'àncora cost-robust (1h, regge 6×) con la sleeve cost-fragile. Confronto PORT06: swap OOS 9.95 vs blend 9.66 — +0.3 di Sharpe di backtest pagati in robustezza reale. Non vale.
- Giudice finale = ledger reale shadow: misurerà lo slippage vero a 15m. Soglia di lettura: all-in <0.40% (Sharpe ≥6) → ottimo diversificatore, valutare size piena; verso 0.60%+ → vale appena la mezza-size che ha (già protetto).
In una riga: robusto come segnale, fragile come esecuzione → sta nel portafoglio a
metà size accanto al 1h, non al suo posto. Riproducibile: fee-sweep + sub-periodo +
OOS via pairs_sim_flat; plateau/flat-check negli script pairs15m_*.py.