Files
PythagorasGoal/docs/diary/2026-06-19-trackF-seasonality.md
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

78 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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:0022: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 8284%, 66% nel 2022 |
| DOW long-flat | +0.81 | +0.96 | DD 7578%, 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 2122 UTC positiva) è
troppo debole e non sopravvive al turnover.
- **Day-of-week:** l'unico risultato "positivo" è **long-bias mascherato** (≈ buy-and-hold,
Sharpe ~0.80.96 < trend portfolio 1.32, DD 7584% 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.