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

3.9 KiB

Raw Blame History

2026-06-02 — Loss-guard per le fade: filtro Hurst (regime persistente)

Goal: limitare le perdite delle fade in "bassa vol". Diagnosi empirica + ricerca web + workflow 11 agenti + test decisivo a livello PORT06. Branch feat/fade-lossguard.

Riformulazione del problema (la premessa era imprecisa)

Diagnosi su 3022 trade fade (MR01/MR02/MR07 × BTC/ETH, 2021+): le perdite NON si concentrano in bassa vol — anzi il terzile low-DVOL è net positivo (+2,30%/trade). Il vero driver è il regime PERSISTENTE/trending, misurato dall'Hurst:

somma perdite peggiore: hurst>0,55 (−2695% in low-vol, dominante in ogni terzile vol)
stop-rate 43% per hurst>0,55 vs 21% per hurst<0,45 (anti-persistente) — 2x
peggiori 1% trade: Hurst medio 0,61 (77% con hurst>0,55, solo 13% in bassa-DVOL)

Ricerca web (confermata e smentita dai dati reali)

Hurst regime filter (MR solo H<0,45, evitare H>0,55): CONFERMATO sui dati reali. ✅
ADX (PF 1,62 sotto 20 vs −0,74 sopra 30): NON si replica — ADX-skip uccide l'edge (Sharpe 4,82→0,99) e lo stop-rate non scende. ❌
vol-expansion ATR-ratio>1,5 (−72% perdite): NON si replica — alza DD e stop-rate. ❌
time-stop ~15 barre: riduce stop-rate ma alza il DD full → non passa standalone. ❌

Workflow 11 agenti — meccanismi testati

Meccanismo	OOS Sharpe (base→filt)	DD full	Buon loss-guard?
Hurst-SKIP h<0,55	4,82→4,96 ↑	24,3→13,8% ↓	SÌ
Hurst-SIZE 1/0,5/0,25	4,65→5,32 ↑ (full)	33,6→11,3% maxDD ↓	SÌ
ADX-skip	4,82→0,99 ✗	—	NO (uccide edge)
vol-expansion vratio	4,82→4,04	24,3→27,5% ✗	NO
Kaufman ER, time-stop, vol-target, DVOL-rising, combo	tutti ↓ o DD↑	—	NO

Solo l'Hurst isola chirurgicamente il regime tossico; gli altri sono "dimmer uniformi" che tagliano winner insieme ai loser (gate FR01 fallito).

TEST DECISIVO a livello PORT06 — SUPERATO ✅

Applicato l'Hurst-skip alle 6 fade dentro il PORT06 intero (equal-weight, le altre 11 sleeve invariate):

Portafoglio	FULL Sharpe	FULL DD	OOS Sharpe	OOS DD	OOS ret
PORT06 baseline	6,62	4,10%	8,89	1,22%	+175%
+ Hurst-skip h<0,55	6,76	2,39%	9,15	1,54%	+158%
+ Hurst-skip h<0,50	6,61	2,08%	9,02	1,54%	+150%

A differenza di FR01 (che diluiva), il filtro Hurst MIGLIORA il PORT06: FULL Sharpe ↑, FULL DD quasi dimezzato (4,10→2,39%), OOS Sharpe ↑ (8,89→9,15). Costo: OOS DD +0,3pp (resta minuscolo), OOS ret −17pp. h<0,55 è il pick (0,50 taglia più ritorno). Non aumenta il profitto: è puro rischio — dimezza il DD mantenendo/alzando lo Sharpe.

Implementazione

Aggiunto hurst_skip_mask in src/strategies/fade_base.py (rolling-Hurst causale dalle SOLE close)

parametro hurst_max (default None=off) in MR01/MR02/MR07. Test: test_hurst_lossguard.py.

Vantaggio operativo decisivo vs FR01: l'Hurst si calcola dalle sole close → nessun feed DVOL/regime live necessario. Lo StrategyWorker lo computa inline dai dati che già ha → deployabile senza nuova infrastruttura, basta settare hurst_max: 0.55 nei params degli sleeve fade.

Da fare per attivarlo live (deploy)

Settare hurst_max: 0.55 nei params delle fade in _defs.py (sleeve live) + aggiornare i params fade del backtest (combine_portfolio/report_families) per PARITÀ + rigenerare il regression-lock PORT06 (i numeri canonici cambiano: DD 4,9→~2,4%).
Verificare che il rolling-Hurst live nel worker coincida col backtest (stessa finestra 100, stesso stepping causale).
Rebuild immagine Docker (up -d --build, non restart) + verifica RESUME.

Default attuale: hurst_max OFF → zero impatto su backtest/parità/live finché non lo si attiva esplicitamente. Il SISTEMA è trovato e validato; l'attivazione è una decisione di deploy.

3.9 KiB Raw Blame History Unescape Escape