Files

T

Adriano eac2aa1d00 audit+fix: anti-look-ahead audit, migrate deployable config to >=12h

- trackD_lookahead_audit.py: relabel test (left==right, no labeling leak) + execution-lag
  stress -> our trend pipeline is CLEAN (4h Sharpe 1.36 robust to +1 bar lag, label-invariant)
- ADOPT conservative conclusion: deploy at 12h (sub-12h: costs/overfit dominate, slight Sharpe
  bump unreliable). 12h: Sharpe 1.32, DD 13.3%, CAGR 16.2% ~ identical and robust
- trend_portfolio: DEPLOY_TF=12h, resample_tf(rule); paper trader + tests on 12h
- calendar research (NEGATIVE, both): trackF seasonality (spurious), trackG prior-levels
  (breakouts continue, fade dead; only long-drift survivor, redundant with TP01)
- gitignore data/paper_trend runtime state

2026-06-19 21:13:57 +02:00

4.8 KiB

Raw Blame History

Track F — Calendar seasonality (hour-of-day / day-of-week) on BTC & ETH

Data: 2026-06-19 · Script: scripts/research/trackF_seasonality.py Dati: Deribit mainnet certificati, BTC/ETH 1h UTC. Fee baseline 0.10% RT (fee_side=0.0005).

Domanda

Esiste un edge di calendario sistematico e tradeable (ora del giorno, giorno della settimana, interazione ora×giorno) su BTC ed ETH, netto fee, OOS, per-anno, su entrambi gli asset?

Metodologia (anti-overfit, anti-leakage)

ret[i]=close[i]/close[i-1]-1 è noto a close[i]; una posizione decisa a close[i] guadagna ret[i+1]. La statistica che decide il trade usa solo barre ≤ i (mai la barra tradata né futuro).
Tradeable test onesto = ADAPTIVE EXPANDING sign: a close[i] guardo il bucket di calendario della barra i+1 (il clock è noto, zero look-ahead) e prendo il segno della media passata di quel bucket (espandente, warmup-gated). Long-flat o long-short. Fee solo su |Δposizione|. È l'analogo onesto di "tradare il seasonal": i dati scelgono il segno di ogni bucket dal vivo.
Tabelle descrittive per-ora/per-giorno split IS(65%)/OOS(35%) come diagnostica.
Regola discreta ottimizzata in-sample (entra a ora H, tieni W barre, dir migliore) mostrata solo per esporre il gap IS→OOS (384 celle testate/asset).
Benchmark buy-and-hold come controllo del long-bias.

Risultati

1. Descrittive (bp/barra, IS vs OOS)

Hour-of-day: sign-agreement IS/OOS solo 12/24 (BTC) e 8/24 (ETH) → caso. Le ore "US close" 21:00–22:00 UTC sono positive in entrambi gli split su entrambi gli asset (l'unico pattern con un minimo di coerenza), ma il resto è rumore che cambia segno tra IS e OOS.
Day-of-week: più stabile. Giovedì negativo su BTC ed ETH in IS e OOS; Lun/Mer positivi. Sign-agreement 6/7 (BTC), 5/7 (ETH).

2. Adaptive expanding-sign (il test tradeable)

Strategia	BTC Sharpe	ETH Sharpe	Note
HOUR long-short	−5.39	−4.04	DD 100%. Annientata dalle fee.
HOUR long-flat	−2.92	−2.09	DD 100%. Idem.
DOW long-short	+0.64	+0.83	DD 82–84%, −66% nel 2022
DOW long-flat	+0.81	+0.96	DD 75–78%, −64/−66% nel 2022
HOUR×WEEKDAY (168 buckets)	−5.05	−3.96	DD 100%. Overfit puro + fee.

3. Il controllo che smonta il DOW — buy-and-hold

BTC buy-hold: Sharpe 0.79, CAGR 34.9%, DD 77% → DOW long-flat: Sh 0.81, CAGR 34.2%, DD 77.5%.
ETH buy-hold: Sharpe 0.84, CAGR 42.4%, DD 81% → DOW long-flat: Sh 0.96, CAGR 52.7%, DD 74%.
Il DOW long-flat è long il 78% del tempo (mean_pos≈+0.78). È buy-and-hold travestito: guadagna perché crypto sale, non perché esiste un edge di giorno. Lo "skip del giovedì" aggiunge pochissimo e non giustifica un deploy.

4. Fee sweep (HOUR long-short adaptive)

A fee 0%: Sh +0.61 (BTC) / +0.80 (ETH) — solo long-drift. A 0.10% RT: −5.4 / −4.0. Turnover ~8.000 flip/anno (segno orario instabile, cambia quasi ogni barra) → morte istantanea per fee. Le strategie hour-of-day sono ad alta frequenza per costruzione: le fee sono di prim'ordine e le uccidono.

5. Regola discreta ottimizzata in-sample (trappola multiple-testing)

BTC: best IS H=05 hold=24h dir=+1 → IS Sh +4.25 → OOS Sh +1.47 (+3.7 bp/trade).
ETH: best IS H=13 hold=24h dir=+1 → IS Sh +7.35 → OOS Sh +0.90 (+3.2 bp/trade).
Collasso IS→OOS classico. Inoltre "hold 24h dir+1" = ancora long-bias (entra una volta/giorno e tiene 24h ≈ sempre long). Il margine OOS (~3 bp/trade su 10 bp RT) è marginale e fragile.

Multiple-testing

199 celle di calendario/asset (24 ore + 7 giorni + 168 ora×giorno) + 384 (H,W,dir)/asset. Con così tante celle, bucket "significativi" spuri sono garantiti. Filtri applicati: segno scelto dal vivo su soli dati passati, deve reggere OOS, per-anno, e su entrambi BTC ed ETH.

Verdetto — SPURIO / NON deployable

Nessun edge di calendario netto-fee robusto su BTC ed ETH.
Hour-of-day: morto (fee + segno instabile). L'unica regolarità (US-close 21–22 UTC positiva) è troppo debole e non sopravvive al turnover.
Day-of-week: l'unico risultato "positivo" è long-bias mascherato (≈ buy-and-hold, Sharpe ~0.8–0.96 < trend portfolio 1.32, DD 75–84% rovinoso, −65% nel 2022). Non è un edge seasonal sfruttabile; è esposizione direzionale al drift di crypto.
Hour×weekday: overfit puro (IS −3.6 → OOS −8.0).
Coerente con la lezione del progetto: dove l'unica "direzione" che funziona è essere long, non c'è alpha di timing — c'è beta. Il trend portfolio (TP01) cattura quel beta in modo vol-targeted e con DD ~12%, infinitamente meglio di qualunque regola di calendario qui.

Azione: track F chiuso negativo. Non aggiungere nulla al portafoglio. Il soffitto Sharpe ~1.3 su BTC/ETH regge.

4.8 KiB Raw Blame History Unescape Escape