Files

T

Adriano Dal Pastro 14522262e6 chore(reset): v2.0.0 — storico certificato Deribit mainnet, ripartenza pulita

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>

2026-06-19 15:20:59 +00:00

5.6 KiB

Raw Blame History

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.

5.6 KiB Raw Blame History Unescape Escape