Files
PythagorasGoal/CLAUDE.md
T

294 KiB
Raw Blame History

PythagorasGoal — Istruzioni per agenti

Stato del progetto — v2.0.0 RESET (2026-06-19)

LEGGERE PRIMA DI TUTTO. Il progetto è stato resettato dopo aver scoperto che l'intera libreria di strategie "validata OOS" (FADE, PAIRS, DIP01, TR01, ROT02, TSM01, XS01, SH01) era artefatto di uno storico contaminato — print fantasma del feed Cerbero testnet + storico Binance/USDT. Ri-testate sul feed reale, tutte perdono ogni anno (vedi docs/diary/2026-06-19-deribit-history.md, il documento di fondazione).

Cosa è cambiato:

  • Lo storico è stato ricostruito da Deribit mainnet e certificato. Universo affidabile = solo BTC/ETH (tutti i TF). Gli alt sono esclusi (illiquidi/divergenti/non certificabili).
  • Tutto il codice vecchio (strategie, stack live, ~100 script di ricerca/gate, dati non certificati, 60+ diari) è archiviato in Old/ (preservato in git, non cancellato).
  • L'esecuzione è DISABILITATA, il conto mainnet è flat. Non c'è trading live attivo. AGGIORNATO 2026-06-20: l'esecuzione di TP01 è ARMATA e LIVE su Deribit mainnetconfig/live.json execution_enabled=true + cron giornaliero live_execute.py --execute (cablato in scripts/cron_daily.sh). Guardrail: cap $300 notional/asset, min order $5, disaster-SL on-book 30%, alert Telegram su esecuzione/errori. Capitale reale ≈ $600 (NON i €2000 nominali del paper trader). Stato corrente: flat (target TSMOM risk-off → BTC/ETH 0.0x, nessun ordine). Solo TP01 è eseguito; XS01/VRP01 restano paper/STAT-MODE.
  • Si riparte dalla ricerca di strategie NUOVE, su dati certi, con la metodologia qui sotto.

Ricerca post-reset (2026-06-19) — esito

Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condiviso src/backtest/harness.py). Sintesi in docs/diary/2026-06-19-research-synthesis.md.

  • TP01 Trend Portfolio — strategia DIFENSIVA robusta (non alpha)src/strategies/trend_portfolio.py. TSMOM multi-orizzonte (1-3-6 mesi) vol-targeted, long-flat, 50/50 BTC+ETH. Config canonica PORT LF1d (>=12h, 1d raccomandato, vol-target 20%, leva cap 2x): FULL Sharpe ~1.30, maxDD ~14%; HOLD-OUT 2025-26 Sharpe ~0.31 / +3.5% mentre il buy&hold 50/50 faceva 39%/DD60%. Verificata indipendentemente col gauntlet onesto (hold-out + cross-asset + plateau + deflated-Sharpe 0.999): regge. Valore = taglio del drawdown ~6× vs buy&hold, NON generazione di ritorno (CAGR ~16% vs ~48% del buy&hold sul toro). ⚠️ LOOK-AHEAD (2026-06-19): un ffill MIXED-TIMEFRAME su barre open-labeled gonfiava il 4h (~1.60 → reale ~1.1). Il calcolo per-singolo-TF è leak-free, ma NON scendere sotto le 12h: costi+overfitting dominano senza vantaggio (FULL Sh piatto ~1.3 da 12h a 4h; hold-out migliore a 1d). Deploy/paper a 1d. Diari 2026-06-19-tp01-verification.md / -tp01-lookahead-fix-lf.md. Paper/forward: scripts/live/paper_portfolio.py (TP01+XS01, 1d). Test: tests/test_trend_portfolio.py. (Il vecchio paper_trend.py standalone TP01 è RITIRATO in Old/scripts/live/ 2026-07-17 — inerte dal 2026-06-19, non in cron, sostituito da paper_portfolio.) Ri-verifica: scripts/analysis/{verify_tp01,stress_tp01,tp01_lowfreq}.py. ⚠️ ANCHOR TIMING-LUCK (2026-07-02, confermato da scettico): l'hold-out 0.31 è calcolato sull'ancora daily 00:00 UTC, che è la migliore delle 24 possibili (mediana ancore 0.04, banda [0.13,+0.30]; P0.86 che una qualsiasi ancora mostri uno spike così per puro caso) → l'hold-out 2025-26 NON risolve l'edge di ritorno di TP01; ciò che regge a OGNI ancora è il taglio del DD (7-10% vs ~60% B&H). FULL/plateau/deflated-Sharpe/gate INVARIATI (h=0 al 31° pctl su FULL). Regola: i futuri numeri hold-out di strategie a ribilanciamento ancorato si citano con la banda d'ancora. Diario 2026-07-02-timing-crt-wave.md; script scripts/research/r0702_tp01_offset.py

    • r0702_skeptic_offset.py.
  • XS01 Cross-Sectional Momentum (Hyperliquid) — DIVERSIFICATORE che migliora il portafogliosrc/portfolio/sleeves.py:_xsec_returns. Market-neutral su 19 alt liquidi major Hyperliquid (1d, dal 2024): ogni 10g long i 5 più forti / short i 5 più deboli, vol-target 20%. Scorrelato a TP01 (~0.12). Affinato (2026-06-19): (a) blend di lookback [30,90] (z-score cross-sectional mediato, come il multi-orizzonte di TP01); (b) gate di dispersione p30 (entra solo se la dispersione cross-section del momentum supera il percentile espandente causale, altrimenti flat — XS è rumore in regime compatto). Standalone FULL Sh 1.50 / HOLD 1.71 / DD 11%, plateau robusto (lookback, gate p15-35). Caveat: storia ~2.5 anni; STAT-MODE (book a 19 gambe non eseguibile a 2k, serve ~20k) → monitor forward. NB il gate concentra XS nei regimi dispersi (2025-26 = hold-out alta-dispersione). ⚠️ PHASE TIMING-LUCK (2026-07-02): i numeri headline sono sulla fase 0 del ciclo H=10, che è al 15° pctl di DD (10.8% vs ~15.5% fase tipica, 29% peggiore) e 85° di FULL fra le 10 fasi (HOLD solo 65°, non estremo); P(spike per caso)≈0.91-0.94. Lens onesta = ensemble di fase: FULL 1.25 / HOLD 1.31 / DD 10.9%; a fase mediana FULL 1.08/HOLD 1.10/DD 21%. La decisione di ammissione @15% regge (0 fasi negative, 8/10 FULL≥1.0), i numeri 1.50/1.71/11% no → citarli con banda di fase. Ora-del-giorno NON testabile (solo 1d HL). Script scripts/research/r0702_anchor_xs01.py; diario 2026-07-02-anchor-audit-xs01-skh01.md. Ricerca scripts/portfolio/{xsec_research,xsec_blend,xsec_dispgate}.py. Diari 2026-06-19-hyperliquid-xsec / -xsec-blend / -xsec-dispgate / -xsec-universe-expansion / -trend-multiasset.

  • PORTAFOGLIO ATTIVO = TP01 (33%) + XS01 (15%) + VRP01 (12%) + SKH01 (20%) + GTAA01 (20%) (src/portfolio/sleeves.active_sleeves): TP01+XS01 combinato FULL Sharpe 1.55, HOLD-OUT 1.55, DD 4.4%. Aggiunto VRP01 (options short-vol, sotto): TP01+VRP01 da solo fa FULL Sh 1.30→1.44 / HOLD 0.31→0.40 a peso 20%. Aggiunto SKH01-V2-DD @25% effettivo (2026-06-23, sotto): 4-sleeve FULL Sharpe 1.68→2.13, HOLD-OUT 1.63→2.30, DD full 14.3%→7.8% (Skyhook quasi-ortogonale, corr ~0.09). Aggiunto GTAA01 @20% effettivo (2026-07-01, i 4 preesistenti scalati ×0.80): trend difensivo equity 6-ETF su IB (src/portfolio/gtaa.py, ~30 anni storia, validato 2026-06-22 su OOS equity 2015+ INDIPENDENTE dall'hold-out crypto, corr al book ~+0.10) → 5-sleeve FULL Sharpe 2.12→2.24, HOLD-OUT 2.21→2.46, DD full 7.8%→6.2% (costo dichiarato: CAGR full 23.3→18.8%; 2022 unico anno con dSh). Uplift positivo in-sample E su tutte le finestre disgiunte (vs EW-STR refutato lo stesso giorno). Convenzioni: weekend/festivi equity = 0.0 (capitale IB fermo, non riciclato); attivazione nel book all'era crypto 2019-03; il book live Deribit (deribit_book_sleeves TP01+SKH01 75/25) NON lo include (GTAA in paper_combo dal 2026-06-23). Test tests/test_gtaa_sleeve.py; diario 2026-07-01-strategy-wave-6threads.md (addendum GTAA). Report scripts/portfolio/run_portfolio.py. Sleeve a date d'inizio diverse → outer-join con pesi rinormalizzati (TP01/SKH01/GTAA dal 2019*, VRP dal 2021, XS dal 2024; *GTAA troncato all'era book). ⚠️ ANCHOR-LUCK del book — MISURATO 2026-07-26 (la stima del 02/07 era ottimista su 3/3). I numeri canonici sono calcolati con TUTTI e cinque gli sleeve alla loro ancora canonica. Il 02/07 la correzione fu stimata a occhio sommando le fortune marginali (HOLD ~1.9-2.1, FULL ~2.0-2.2, "DD ~6% invariato"); il 26/07 è stata misurata sullo spazio congiunto (24×10×7×23×5 = 193.200 configurazioni, 2000 estrazioni uniformi indipendenti, r0726_loo_deluck.py):

    canonico pctl stima onesta = mediana banda p10-p90
    Sharpe FULL +2.222 97.0° +1.95 [1.81, 2.12]
    Sharpe HOLD-OUT +2.364 99.6° +1.54 [1.11, 1.91]
    maxDD FULL 6.07% 12.0° 6.85% [5.99, 7.94]
    Solo 9 estrazioni su 2000 battono l'hold-out canonico. Il book resta positivo e diversificato
    a ogni ancora, ma i numeri da citare sono 1.95 / 1.54 / 6.85%, non i canonici.
    ⚠️ Lezione: la somma delle fortune marginali NON è la mediana congiunta — sbagliava di +0.82
    di Sharpe hold-out, più di quasi tutti gli uplift per cui in questo progetto si è discusso se
    ammettere uno sleeve. Quando serve la banda di un AGGREGATO si campiona lo spazio congiunto; gli
    audit uno-sleeve-alla-volta (02/07, 03/07) restano validi per giudicare quello sleeve.
    Diari 2026-07-02-anchor-audit-xs01-skh01.md (originale) e 2026-07-26-loo-deluck.md (misura).
    🚨 **«POSITIVO IN N/N ANCORE» NON E' N OSSERVAZIONI — misurato 2026-08-23, e tocca OGNI bullet
    di questo file che cita una banda d'ancora.** Correlazione media fra le **24 ancore di TP01
    0,631 → N_eff 1,55**; fra le 10 fasi di XS01 0,790 → N_eff 1,23. **E non si salva sulla
    differenza appaiata:** la componente comune non si cancella (corr 0,593 → N_eff 1,64-2,24) —
    era l'attesa a priori del critico ed e' stata REFUTATA. Sulla stessa grandezza, la **banda
    d'ancora e' 4,3x piu' stretta dell'IC95 bootstrap, che CONTIENE LO ZERO** (su XS01 il rapporto e'
    3,8x: due misure indipendenti, stesso fattore ~4).
    ⚠️ Cio' che NON significa: che i verdetti cadano. Le decisioni prese con l'audit d'ancora
    poggiano anche su iso-vol, maxDD, selection-on-holdout ed edge lordo. **Cade la PRECISIONE dei
    numeri, non la DIREZIONE delle decisioni.**
    REGOLE: (a) «N/N ancore» si cita come robustezza alla SCELTA dell'ancora, ~2 osservazioni
    indipendenti — non come N prove; (b) la banda d'ancora NON e' un intervallo di confidenza
    e non va usata al posto di uno; (c) **non attaccare un p-value a un conteggio di ancore o di
    finestre sovrapposte** (caso preso in fallo: un «test dei segni 12/12, p=0,0005» su finestre 30g
    sovrapposte e selezionate come le peggiori).
  • SKH01-V2-DD "Skyhook" — DIVERSIFICATORE quasi-ortogonale (research)src/strategies/skyhook.SKH01_V2_DD, sleeve src/portfolio/sleeves._skyhook_returns. Sistema dual-TF (segnale 690m / exec 230m) regime (BuzVola/BuzVolume tipo-Chande) AND pattern (Donchian breakout), NON trend-follower, L/S. Vincitrice di 2 onde multi-agente (la 2ª = DD-reduction): exit a percentuale fissa ASIMMETRICA (long sl4%/tp10%, short sl2%/tp8% più stretto) → standalone maxDD BTC 21% / ETH 27% (<30%), minFull +0.99, minHold +1.26, causale (0/400), fee-surviving 0.40%RT. Marginal vs TP01 ADDS (corr 0.09, has_insample_edge, robust_oos multicut 7/7, is_hedge=False); blend 0.75·TP01+0.25·SKH hold-out 0.31→1.17. Verificato leak-free + 2 scettici. CAVEAT: equity daily-step (Sharpe lens), ETH DD margine sottile, book 230m (costi ribilanciamento da verificare a deploy) → research win, forward-monitor. Diario 2026-06-23-skyhook.md. ⚠️ GRID TIMING-LUCK (2026-07-02, più forte di TP01): i numeri headline sono sull'offset 0 della griglia 230m/690m, al 93-98° pctl dei 23 offset a priori — minHold +1.26, blend 1.17 e book HOLD 2.44 sono il MASSIMO dei 23 (mediane: minHold +0.39, blend 0.72, book 1.96); spike, non plateau (±30m crolla); P(spike)≈0.70. Il gate DD<30% (criterio di selezione di V2-DD) fallisce in 15/23 offset (mediana ETH 29.2%). Regge de-luckato: uplift blend positivo a TUTTE le 23 fasi (min +0.18, med +0.42) + corr 0.05-0.11 → ADDS sopravvive ridimensionato. LIVE (SKH=25% del book Deribit): path reale cron orario + exit software → book 50/50 FULL 1.46→1.19 / HOLD 1.64→1.15 / DD 18→25%; nei crash gap-through-stop reale (sl2% modellato → 11/23% realizzato). Pesi/book INVARIATI (ogni cambio passa weights_tilt_null). Follow-up CHIUSO 2026-07-24 (scripts/research/r0724_skh_live_weight.py): sul path live (lente hourly, 23 offset) il peso ottimale de-luckato È 0.25 (argmax mediana-IS di banda, plateau 0.20-0.30; w=0.30 passa il gate solo a off0 = ancora fortunata, fallisce a offset mediano) e la cadenza 230m vale ~+0.01/+0.02 Sh mediano (rumore: il degrado live è il fill-al-livello, ~+0.35 Sh, che nessun cron recupera) → book 75/25 e cron orario CONFERMATI; diario 2026-07-24-skh-live-weight.md. Script scripts/research/r0702_anchor_skh01.py; diario 2026-07-02-anchor-audit-xs01-skh01.md.

  • VRP01 Options Short-Vol — DIVERSIFICATORE da FinanceOld/OptionsAgentsrc/portfolio/sleeves._vrp_combo_returns. Put credit spread settimanale (vendi put -0.28, compra put -0.10) gated su IV-rank. Idee portate da ../FinanceOld/OptionsAgent (Bear Call Spread + gate d'ingresso). Migliora il lead VRP nudo (options_vrp_lab): (a) defined-risk taglia la coda (worst-week -16.6%→-7.4%, DD 33%→14%); (b) gate IV-rank>0.30 = vendi vol solo ricca → ribalta HOLD-OUT da -0.25 a +0.28 (l'alpha è il filtro di regime). Standalone FULL Sh 1.10, HOLD 0.60, DD 12%, positivo/piatto ogni anno (2022 crash incluso). Scorrelato a TP01 (+0.01-0.07). CAVEAT: premio MODELLATO su DVOL ATM (skew non esplicito), book a 1d, f di stress reale non catturato → LEAD robusto, non deploy pieno. Ricerca scripts/research/options_vrp_v2.py (vs baseline options_vrp_lab.py). Test tests/test_vrp_sleeve.py. ⚠️ ANCHOR-AUDIT CHIUSO + ondata "migliora e proteggi" (2026-07-03, 7 filoni + 2 lenti + scettico): VRP01 NON è migliorabile e la protezione DD si compra SOLO con la size. (a) Anchor-luck (ciclo settimanale, 7 fasi): PRIMO sleeve SENZA firma di luck — la fase canonica è la PEGGIORE delle 7 su FULL (1.09 = 7° pctl) e su DD (11.8% = 93° pctl), mediana su HOLD (0.59); spike bootstrap NEGATIVO → i numeri di ammissione FULL 1.10/HOLD 0.60/DD 12% sono CONSERVATIVI, non gonfiati. Da ora si citano con banda: ShFULL [1.09,1.83], ShHOLD [0.03,1.11], DD [5.7,11.8%]; edge OOS f-dipendente (f=0.8 → HOLD0). Con questo l'audit anchor è completo su 4/4 sleeve ancorati. (b) Griglia 288 strutture: nessuna batte VRP01 (DSR 0.000; metà griglia = 3ª occorrenza "0-perdite/Sharpe implausibile" dopo CC01/ALB-A → gate implausible_sharpe alzato di priorità). (c) 4 overlay DD (exit-spike/SL-MTM/ ala-coda/cooldown): 4/4 REFUTED dal null de-levering — la protezione crash vive già nel gate d'ingresso IV-rank. (d) Gate nuovi: 4° fallimento su 4 (l'alpha è il binario IV-rank>0.30). (e) Sizing: 12% deploy ≈ 0.27 Kelly onesto (anti-rovina); ⚠️ NON confondere col 12% di PESO del book (~0.014 Kelly, fattore 19x). (f) Gate term-structure VIX/VXV su SPX (ΔSh +0.90, DSR 0.992) = confound di modello al 100% (la var del gate coincide con l'errore BS-flat vs term-structure) → nuova regola: riprezzare term-structure-consistent prima di credere a un gate vol su strutture BS-flat. Book/pesi INVARIATI. Diario 2026-07-03-vrp-improve-dd.md; script scripts/research/r0703_vrpimp_*.py (7 file). Diario 2026-06-20-financeold-analysis-vrp-v2.md. ⚠️ f MISURATO SULLE QUOTE REALI = 0.73, NON 1.0 (2026-07-30) — i numeri di ammissione vanno citati col f. Primo confronto del prezzatore del sleeve con la catena Deribit mainnet vera (scripts/research/r0730_vrp_real_quotes.py, dati cerbero-bite). Su 8/8 scadenze settimanali con ENTRAMBE le gambe quotate (delta realizzati 0.270/0.099 contro target 0.280/0.100), agli STESSI strike: f del credito NETTO 0.73 (IC95% bootstrap [0.698, 0.780], 0/15 osservazioni ≥1.0; 0.80 a mid). Meccanismo, non rumore: IV(corta)DVOL +0.8pp ma IV(lunga)DVOL +7.5pp → il modello prezza a vol ATM anche l'ala che si COMPRA, che costa ~2.3× il modello → il credito netto si comprime del 27%. Il difetto non è nel premio incassato ma nella protezione comprata, cioè proprio il "(a) defined-risk" per cui v2 fu promosso. Conseguenza standalone (solo f cambiato): f=1.00 → FULL 1.08 / HOLD +0.58; f=0.80 → 0.51 / 0.02; f=0.73 → 0.31 / 0.23. Book 5-sleeve (VRP01 12%, ancore canoniche): FULL 2.215→2.146 (Δ−0.069), HOLD 2.347→2.244 (Δ−0.103), DD invariato → dentro la banda d'ancora, ma il LOO del 26/07 dava a VRP01 +0.122 di FULL: ~metà era il prezzo che il modello si faceva da solo (l'audit d'ancora corregge la fortuna di calendario, non l'ottimismo di prezzo). ⚠️ La calibrazione del 20/06 NON è contraddetta, è replicata: misurava la sola gamba corta (qui 1.02, implementazione indipendente). REGOLA: il f di una struttura multi-gamba non è il f di una sua gamba — misurare la sola gamba venduta dà la risposta sbagliata con segno rassicurante. Congelata in tests/test_cb_chain_vrp.py. PROFIT-TAKE al 50% del credito — REFUTED (2026-07-30, 3° filone). scripts/research/r0730_vrp_profit_take.py, test tests/test_vrp_profit_take.py (16), diario 2026-07-30-vrp-profit-take.md. Book/pesi/cron/config INVARIATI. VRP01 tiene FINO A SCADENZA (S1 = px[i+tn], nessuna gestione infra-settimana) e il profit-take era l'unico grado di liberta' non misurato: gli overlay del 03/07 erano tutti sul lato del RISCHIO. Replica del sleeve bit-exact (max|diff| = 0.0) prima di ogni delta. Esito con fee reali per gamba: canonico ShFULL 1.32 → PT25 0.22 / PT50 0.18 / PT75 0.45; null del de-levering REFUTED 6/6 (a PT25 basta k=0.818 per lo stesso DD con Sharpe 1.32 invece di 0.22). Meccanismo (confronto appaiato per ingresso): scatta sull'86-91% dei VINCENTI e sul 19-25% dei perdenti → tronca i vincenti del 27% e salva un perdente su cinque; la peggior settimana e' IDENTICA (7.27%) in ogni variante = pura troncatura dell'upside. Ipotesi mia refutata in sessione: "su 7g chi tocca +50% e' chi sarebbe scaduto senza valore, quindi a scadenze lunghe paga" — testata su 7/10/14/18/21/28g, ΔSh negativo a tutti e sei (a 18g, il tenore di cerbero-bite, il DD migliora 7.1→3.8% ma lo Sharpe crolla = firma del de-levering). ⚠️ La colonna Sh hold di quello sweep NON e' un risultato (6 celle sul campione pieno); il tenore >10g resta un buco reale della griglia 03/07, da chiudere con study_family_honest, non con uno sweep. Con questo gli overlay refutati su VRP01 sono 5/5. ⚠️ CORREZIONE a un numero pubblicato lo stesso giorno: il sleeve modella le fee come 12.5% del credito NETTO, il listino vero e' 0.03% del sottostante per gamba (cap 12.5% del premio della singola opzione, che quasi mai morde) → il modello sovrastima le fee di ~2x. Sleeve ufficiale 1.08/0.58/DD 11.8% vs fee reali 1.32/0.82/DD 10.5%. Quindi il numero onesto di VRP01 con f=0.73 e' ShFULL 0.47 / DD 14.5%, non 0.31 (che era calcolato col forfait). fee_frac NON cambiato: il forfait e' conservativo e questo progetto tiene i numeri di ammissione conservativi. Rientro immediato dopo l'uscita: Sh 1.19 < 1.32 canonico; il suo ShHOLD 2.42 non e' selezionabile in-sample → non e' un lead. BUCO DEL TENORE CHIUSO col gate onesto (2026-07-30, 4° filone) — nessun cambio. scripts/research/r0730_vrp_tenor_gate.py, test tests/test_vrp_tenor_gate.py (12), diario 2026-07-30-vrp-tenor-gate.md. La griglia 03/07 si fermava a 10g; qui la famiglia e' stata dichiarata prima di guardare: 8 tenori (5-35g) x 3 delta corti x 3 lunghi = 72 celle (riaprire il tenore riapre la struttura → i trial si contano al RIALZO). ⚠️ study_family_honest e' cablato sui candidati DIREZIONALI (factory -> target_fn via candidate_daily), quindi sono stati usati i suoi tre componenti reali: selezione in-sample-only → altlib.deflated_sharpealtlib.marginal_vs_tp01 (importati, non riscritti; c'e' un test d'identita'). Esito: earns_slot_honest = False. Cella scelta al buio 10g 0.28/0.05 (Sh IS 1.75 / FULL 1.55 / HOLD 1.01 / DD 9.6%) contro il canonico 7g (1.50/1.32/0.82/10.5%; rango 17/72 in-sample, 26/72 full) → batte il canonico, ma DSR 0.948 < 0.95 FAIL (il canonico stesso fa 0.885 dentro questa famiglia). marginal_vs_tp01 = ADDS per entrambe → il verdetto non e' "VRP01 e' rotto", e' che il vantaggio non sopravvive al conto dei trial. 📌 Il buco si chiude meglio sul contenuto che sul gate: la regione MAI esplorata PERDE. Miglior cella >10g = 18g 0.28/0.05, rango 8/72, e solo 3/10 della top-10 stanno oltre i 10 giorni → lo studio conferma il 03/07 invece di ribaltarlo. "Il vincitore sta dove il modello sbaglia di piu'" — MIO ARGOMENTO, MISURATO E REFUTATO LO STESSO GIORNO (5° filone, sotto): l'ala a δ−0.05 e' molto piu' mispriced in RELATIVO (f_long 5.85 contro 2.23) ma pesa il 3.2% del premio corto invece del 18.4%, quindi sul credito NETTO l'effetto e' MINORE → f_net 0.852 contro 0.718: il candidato ha un f migliore, non peggiore. Meccanismo giusto, conclusione rovesciata. La decisione (nessun cambio) regge, ma su tre gambe invece di quattro: gate DSR, regione nuova perdente, ineseguibilita' sotto ~$2.6k. ⚠️ Robustezza del verdetto, pubblicata: DSR 0.983 PASS a N=8 / 0.948 FAIL a N=72 / 0.909 a N=360 → il verdetto si ribalta col conteggio. La griglia era dichiarata in anticipo e il conto fatto al rialzo, ma fallisce per 0.002: si cita come tale, non come refutazione netta. Congelato in test_il_verdetto_dipende_dal_numero_di_trial_dichiarati. Seguito giusto = una MISURA, non un altro backtest: quanto vale f sul 10g/0.05 sulle quote vere (la catena ora la raccogliamo noi ogni ora; oggi 15 osservazioni sul solo canonico). REGOLE: (a) quando si riapre un parametro si riapre la sua famiglia, e il deflated-Sharpe e' l'unico posto dove barare e' indolore e invisibile; (b) dichiarare la griglia prima e pubblicare la sensibilita' del verdetto al conteggio; (c) un buco si chiude meglio mostrando che dentro non c'e' niente che bocciando il candidato; (d) se la selezione converge dove un difetto di modello e' gia' misurato, il sospetto vale piu' del numero — e si dice che e' un sospetto. f MISURATO SULLE STRUTTURE, e sorvegliante cablato (2026-07-30, 5° filone). scripts/live/vrp_f_watch.py (in cron_daily.sh), test tests/test_vrp_f_watch.py (11), diario 2026-07-30-vrp-f-strutture.md. Book/pesi/config INVARIATI. Il campione c'era gia': 8 scadenze utilizzabili per asset su 8, entrambe le strutture, 16 osservazioni ciascuna.

    struttura f_short f_long quota ala/corta f_net
    canonico 7g δ−0.10 1.013 2.233 18.4% 0.718
    candidato 10g δ−0.05 0.972 5.846 3.2% 0.852
    Aritmetica che rende ovvio l'errore: f_net = (f_short k·f_long)/(1 k) con
    k = premio_lungo/premio_corto → **un f_long grande fa danno solo moltiplicato per un k
    grande**. ⚠️ Artefatto di tick ESCLUSO prima di crederci: l'ask dell'ala sta a 22 tick
    mediani (min 15, 0% a ≤2 tick).
    La DIFFERENZA non e' stabilita: appaiata per (asset, scadenza) fa **+0.109 IC95
    [0.047, +0.193]**, 11/16 positive → contiene lo zero. Replica indipendente del canonico
    (0.718 per un percorso con finestra DTE e pairing diversi da quello che dava 0.73).
    Al proprio f: canonico 0.43, candidato 1.18.
    **CRITERIO PRE-REGISTRATO (dichiarato prima del campione pieno, congelato in un test):
    ≥40 coppie E ampiezza IC95 ≤0.12** (oggi 16 e 0.241) → prima gamba verso fine ottobre 2026;
    il sorvegliante rifa' la misura ogni giorno e notifica una volta sola quando basta (lezione
    DVOLSPREAD: un lead senza sorvegliante e senza data e' un lead perso).
    ⚠️ Calibrazione della soglia verificata prima di fidarsene: con differenza vera nulla lo
    zero e' escluso nel 5.0/4.0/3.0% dei casi a n=16/40/60 = il 5% atteso. (Il test iniziale su
    seed fisso falliva perche' quel seed era uno dei 5% legittimi → sostituito con un test sulla
    PROPRIETA', 100 estrazioni.)
    NON promuove nulla: il candidato resta bocciato sul deflated-Sharpe, che non dipende da f.
    REGOLE: (a) un fattore di errore si giudica moltiplicato per il suo peso — 5.85 al 3%
    fa meno danno di 2.23 al 18%, e guardare il fattore senza il peso da' la conclusione opposta a
    quella vera; (b) prima di credere a un rapporto estremo su un prezzo piccolo, contare i tick;
    (c) una soglia sull'ampiezza di un IC richiede di verificare la copertura di quell'IC;
    (d) "non abbastanza campione" non e' "nessuna differenza" — si aspetta con una data.
    💰 A $3.000 la domanda non e' il rendimento (min_trade_amount letti dal venue il 30/07):
    BTC min 0.1 = $6.210 di collaterale/lotto → FUORI; ETH min 1 contratto = $1.832 → 1 lotto.
    🚨 **CORRETTO 2026-08-23 (§50): misurato sulla famiglia INVERSE, che un conto USDC non puo'
    marginare.** Sulla USDC-lineare il lotto ETH e' $242 e il BTC $772 (7,5x piu' piccoli)
    ⇒ 1 lotto ETH copre il peso di book 12% gia' da ~$2.000, e il BTC da ~$6.440.
    CADE IL LOTTO, NON LA REGOLA: niente short-vol da modello in deploy non ha mai avuto
    bisogno di un muro di taglia. 5ª occorrenza dello schema fee_watch — un numero misurato su
    una configurazione diversa da quella che gira.
    Il sleeve 50/50 diventa ETH-only, e al peso di book (12% = $360) sono 0 lotti — servirebbe
    il 61% del conto su un solo sleeve. REGOLE: (a) un'uscita si giudica su un confronto
    appaiato per INGRESSO, mai allineando le serie sulla data di USCITA — e' proprio quella che
    la variante cambia, e l'inner-join tiene solo i casi in cui non e' successo niente (errore
    commesso e corretto in sessione, 3ª occorrenza della trappola dopo venue-watch e GTAA; congelato
    in un test); (b) **una regola d'uscita che scatta piu' spesso sui vincenti che sui perdenti non
    e' protezione, e' troncatura** — si vede in una riga, la peggior settimana non cambia; (c) prima
    di misurare il rendimento a un capitale dato, misurare il lotto minimo del venue.
    VRP_CFG["f"] NON cambiato (15 osservazioni, 7 settimane, e per giunta **0/8 settimane
    passano il gate IV-rank>0.30**: il f è misurato nel regime in cui il sleeve sta FLAT, DVOL max
    raccolto al 24°/28° pctl della storia) → caveat quantificato, non nuovo parametro; il criterio
    del 19/06 ("rivalutare quando cerbero-bite cattura un crash") è intatto.
    ⚠️ Il DD 12% è un DD di CHIUSURE settimanali: con le standing quotes (~164 riquotazioni/trade)
    il peggior mark INFRA-settimana è mediana 6.9% / minimo 81.7% del capitale su un trade finito
    in utile, e il 50%-profit-take sarebbe scattato in 13/15 settimane. Stessa classe della lente
    wick accoppiata (25/07): un rischio valutato sul minimo non si misura sulle chiusure.
    Diario 2026-07-30-vrp-quote-reali.md.
  • Universo Hyperliquid: ESPANDERLO NON aiuta XS01 (provato): 52-asset / top-liquidità dinamico / trend-multi-asset → tutti peggiori (small-cap/memecoin diluiscono il momentum relativo; il trend multi-asset è ridondante con TP01, corr 0.74). I margini su XS sono nella STRUTTURA DEL SEGNALE (blend + gate), non nel numero di asset. I 51 parquet certificati restano per ricerca futura. ⚠️ Il test "52-asset = negativo" era in parte inquinato dal backfill sintetico (AXS 83%, ALGO/SAND 37% di barre vol=0) poi rimosso — vedi correzione estrazione 2026-06-20 sotto; resta comunque vero che il long-tail diluisce XS01, ma il numero netto post-fix è 51.

  • Lead OPZIONI VRP (income short-vol) — quantificato, NON deployscripts/research/options_vrp_*.py. Vendita put settimanali che incassa il volatility risk premium (IV>RV), scorrelato al trend (~0.07). Premio prezzato BS su DVOL reale (fetch_dvol.py) + calibrato su quote REALI cerbero-bite mainnet (options_vrp_calibrate.py): f reale ≈ 1.0 (non 1.29) → Sharpe ~0.71, DD 33%, coda severa (settimane 15..26% su LUNA/FTX). Diversificatore DEBOLE a premio reale, e short-vol da modello. Regola: niente short-vol da modello in deploy. Rivalutare quando cerbero-bite cattura un crash (per il f di stress reale). Diari 2026-06-19-options-vrp-lab / -eval-crypto-backtest-options.

  • Edge deboli/scartati: ML walk-forward BTC (Sh ~0.57), trend 1h L/S (~1.0), RV ETH/BTC (Sh 0.27, regime-luck), calendar/seasonality (buy&hold travestito), volume/vol e momentum-reversal (negativi).

  • MORTO/confermato artefatto: mean-reversion / fade (negativo anche a fee zero — la vecchia libreria +201%/+1238% era contaminazione); trend 5m/15m (fee).

  • GAMMA SCALPING (long-vol) "scalping BTC/ETH con copertura in opzioni" — SCARTATO (2026-06-26)scripts/research/options_gamma_scalp.py, test tests/test_gamma_scalp.py. È lo specchio esatto del VRP01 (long straddle ATM + delta-hedge: incassa RVIV, dove VRP01 incassa IVRV). Perde ogni anno, ogni variante, ogni frequenza (Sharpe 3 a 6; nudo/cheap-gated/rich-skip; rehedge 1d e 1h). Diagnostica strutturale: a 1d IV≈o>RV (BTC +4.9pp) → paghi il VRP; a 1h RV>IV gross ma (a) gonfiata da microstruttura, (b) il rehedge orario paga 24× la fee di hedge → variante peggiore (6). Marginale vs TP01 = DILUTES, non è nemmeno hedge (perde sia TP01-up sia TP01-down). Muro eseguibilità: opzione BTC min $5.968 ≫ $600. Schiacciato tra due muri: rehedge lento = premio, veloce = fee → nessuna frequenza vince. Regola gemella del VRP: niente long-vol scalp da modello in deploy. Il VRP01 (lato short, gated) resta l'unico edge opzioni — funziona perché sta sul lato giusto dello stesso premio. Diario 2026-06-26-gamma-scalp-options.md.

  • CASH-AND-CARRY (basis trade) "CC01" — premio REALE, Sharpe ARTEFATTO, NON deployabile (2026-06-26)scripts/research/cash_carry_hl.py, test tests/test_cash_carry.py. Diverso da FC01 (funding cross-sectional, già scartato): qui delta-neutral long-spot/short-perp sullo stesso asset → ritorno ≈ +funding (zero esposizione prezzo). Il premio di funding è reale (~+8-14%/anno aggregato, positivo ogni anno in-sample, ortogonale a TP01 corr ~0.05). MA lo Sharpe modellato 11-13 (DD 0.3%) è un ARTEFATTO: il modello cattura solo il cashflow liscio del funding e i rischi di coda sono strutturalmente fuori dal dataset — (1) storico funding dal 2023-05 → manca il 2022 (deleveraging, funding , basis blow-out); (2) procyclico (carry +23% toro 2024 → +1.7% bear 2026, si comprime quando servirebbe); (3) liquidazione short/slippage non modellati. Il mark-to-market della base (premium col → r=funding−Δpremium) sgonfia lo Sharpe solo 13→11 → il basis-from-data NON è il rischio vero. Sharpe reale di un basis-trade ~1-3 con code brusche. NON eseguibile a $600 (spot+perp = 4-38 gambe, funding HL non Deribit) → STAT-MODE. LEAD da rivedere a scala (~20k+ e venue con funding eseguibile), non uno sleeve. Sottoprodotto: CC01 passa OGNI gate del marginal scorer → punto cieco (manca un gate "Sharpe implausibile → rischio nascosto"; prossima indurita raccomandata). Diario 2026-06-26-cash-carry-hl.md.

  • TP01 × DVOL vol-targeting — NON migliora (2026-06-26)scripts/research/tp01_dvol_overlay.py, test tests/test_tp01_dvol_overlay.py. Angolo ESEGUIBILE (tocca il book live, non STAT-MODE): usare il DVOL (vol implicita forward-looking) come denominatore del vol-target di TP01 invece della vol realizzata. Su finestra comune 2021-2026: le varianti DVOL abbassano il DD (12.3%→9.2%) ma anche Sharpe FULL (0.75→0.70) e CAGR (8%→6%). Controllo decisivo: il realized a target_vol RIDOTTO (15%) eguaglia quel DD (9.4%) a Sharpe più alto (0.75) → il taglio di DD del DVOL è solo de-levering, replicabile meglio con un semplice target_vol più basso. L'unico residuo (hold-out +0.06) è single-window (storia DVOL <5 anni) → sotto la soglia multi-cut. Il gate DVOL-spike de-risk è ridondante col trend (TP01 già flat nei crash, Δ 0.00). Lezione: per meno DD sul live la leva è target_vol, non un overlay DVOL (20% resta canonico). Diario 2026-06-26-tp01-dvol-overlay.md.

  • Filoni 2026-06-29 (1ª ondata) — tutti scartati/forward. (A) DVOL-DIREZIONALE standalone BTC/ETH (buy-the-fear / IV-RV come segnale di livello): l'unico edge è un HEDGE (is_hedge=True, paga solo quando TP01 è debole), non alpha → earns_slot=False, forward-monitor come DD-dampener (diario 2026-06-29-dvol-directional.md). (B) INTRADAY ERM (efficiency-ratio regime momentum sub-daily): falso positivo da selezione-sull'hold-out → SCARTATO (vedi gate SELECTION-ON-HOLDOUT; 2026-06-29-intraday-regime.md). (C) XSEC-V2 NON-MOMENTUM su HL (reversal/idio-reversal/low-vol/BAB): solo LOWVOL 19-major regge standalone (FULL/HOLD 1.07) ma deflated-Sharpe 0.13 + storia 2.5a → DEBOLE/ forward STAT-MODE (2026-06-29-xsec-v2-nonmom.md). (D) MACRO regime-gate (equity/credito/oro/tassi → de-risk crypto): RIDONDANTE col trend (corr→TP01 0.989; il gate lavora solo nel 2-3% dei giorni, TP01 già flat nei crash) → SCARTATO (2026-06-29-macro-regime-gate.md).

  • Sweep strategie a 5 thread (2026-06-29) — 0 nuovi sleeve, 1 LEAD che rompe 2 muri su 3. Ricerca parallela onesta su aree inesplorate (harness altlib+xsec_v2_nonmom, tutti i gate incl. il nuovo study_family_honest): (1) low-risk cross-sectional, (2) momentum-structure vs XS01, (3) meta-allocazione dinamica, (4) segnali ortogonali ETH/BTC, (5) 1-gamba a segnale. Esito: soffitto ~1.3 riconfermato; ogni candidato ucciso dal gate giusto (deflated-Sharpe, is_hedge, selection-on-holdout, sostituzione-XS01, multi-cut). Niente batte/diversifica XS01 (varianti = REDUNDANT); meta-allocazione < pesi fissi (i 4 sleeve già quasi-risk-parity); 1-gamba a segnale = TP01 travestito (trend) o hedge a DSR<0.95. LEAD forward-monitor: STATARB-RESID (relative-MOMENTUM del residuo ETH−β·BTC, β OLS rolling, 2 gambe, cella vincente sgn=+1: le dislocazioni ETH-vs-BTC CONTINUANO a 1d, la MR pura sgn=1 perde) — primo stream insieme ortogonale (corr→book 0.027, β-mkt 0.013) ED eseguibile a $600 (haircut ~0, NON STAT-MODE come XS01/opzioni): marginal ADDS, robust_oos, fee-survive 0.30%/gamba; resta sotto soglia solo sull'edge (Sharpe 0.84, DSR 0.929 same-sign <0.95). CABLATO in forward-monitor PAPER: scripts/live/paper_statarb.py (W=45/sgn=+1 congelati, doppio libro MODELED/REAL-$600), nel cron giornaliero accanto a paper_prevday; test tests/test_paper_statarb.py. Se la finestra forward conferma l'edge è deployabile (2 gambe BTC/ETH perp). Altri LEAD: IVOL (idio-vol XS, STAT-MODE), DVOLSPREAD (storia DVOL corta). Diario 2026-06-29-strategy-search-5threads.md. Script scripts/research/{xsec_v3_lowrisk,xsec_v3_momstruct,meta_allocation,orthogonal_signals,signal_inout_1leg}.py.

  • Ondata 2026-07-01 (6 filoni multi-agente + scettico) — 0 edge nuovi dai filoni, 1 gate nuovo, e 1 sleeve promosso DALL'ARCHIVIO (GTAA01, sotto nel bullet portafoglio). Filoni su angoli non coperti dalle ondate precedenti: (1) funding time-series BTC/ETH (posizionamento) = SCARTATO — FOLLOW è trend-beta ritardato, FADE shorta il toro, il gate è TP01 travestito (DSR 0.215); il filone funding è chiuso su 3 lati (FC01 carry, price-clock, TS). (2) breadth/internals alt (51 HL) = SCARTATO ma unico NON-ridondante col trend (corr→TP01 0.40); muore su jackknife (uplift su 1 mese) + DSR 0.433 con ~8 mesi IS → rivisitabile tra 1-2 anni di storia HL nativa. (3) residual momentum XS (β-hedged, 19 major) = REDUNDANT — cross-section la residualizzazione è un no-op (lo z-score di XS01 rimuove già il mercato); l'edge resta solo nella coppia ETH/BTC (STATARB-RESID). (4) ri-ottimizzazione pesi + guardia-DD: il candidato EW-STR (TP30/XS25/VRP15/SKH30, HOLD 2.21→2.35) refutato dallo scettico come selezione-sull'hold-out di 2° ORDINE — SKH01/XS01 furono ammessi/affinati perché forti su quell'hold-out; pre-2025 ΔSh 0.05, finestre disgiunte 0.12/+0.06/+0.14, percentile 94-100° fra 500 tilt casuali ≈ firma best-of-15. Guardia-DD 5%/0.5: inerte OOS (la diversificazione fa già il lavoro; solo circuit-breaker d'emergenza). (5) affinamento VRP01 = NON MIGLIORA (l'alpha è tutto nel gate binario IV-rank; gate TP01 = trappola in-sample; 3° fallimento → filone "VRP dentro il modello" esaurito fino a f di stress reale). (6) stagionalità cross-sectional HL = morta allo step statistico (null permutato). GATE nuovo codificato: weights_tilt_null in src/portfolio/portfolio.py (+ combine_outer riusabile): ogni proposta di CAMBIO PESI si giudica vs il null dei tilt casuali cap-respecting — gate_pass solo se delta_insample≥0 E percentile < firma best-of-k (necessario, non sufficiente); test tests/test_weights_tilt_null.py. ⚠️ Lezione tecnica: DatetimeIndex.view("int64") su indici tz-aware non-ns (pandas 2.x) → scala sbagliata → merge_asof broadcasta = look-ahead che causality_ok non vede; usare epoca esplicita in ms (altlib verificato pulito). Diario di sintesi 2026-07-01-strategy-wave-6threads.md + 6 diari di filone; script scripts/research/r0701_*.py.

  • Ondata 2026-07-02 (TIMING + CRT, 8 filoni multi-agente + scettico) — 0 nuovi sleeve, 1 finding strutturale (anchor timing-luck di TP01, vedi ⚠️ nel bullet TP01). Goal: "strategie con timing differenti". (1) Event-clock bars (volume/vol/range da 5m, TSMOM/Donchian/EWMA in tempo-informazione): batte il wall-clock a pari segnale/frequenza solo in 4/45 coppie; cella best IS 1.45 → HOLD 0.46, NEUTRAL (corr 0.74 = trend travestito) → SCARTATO: il clock non è dove vive l'edge. (2) Calendario scadenze Deribit (expiry weekly/monthly/quarterly ven 08:00 UTC): 0/24 celle a Bonferroni; il drift post-expiry monthly fallisce placebo-weekday e permutation e si INVERTE sul quarterly (dove l'OI massimo dovrebbe amplificarlo); unico pattern robusto = gio→ven negativo, ma è day-of-week (SEA morta) a Sharpe netto ~0 → SCARTATO. (3) Anchor timing-luck TP01 + tranching: finding confermato (dettagli nel bullet TP01); tranching K=2/4 = sola riduzione della varianza della STIMA (ΔSharpe n.s., ΔDD ~0.5pt), NO deploy a $600 (il min-order lo degenera in K=1; serve feed intraday fuori path certificato) — rivalutare a ≥5-10k. Audit d'ancora ESEGUITO su XS01 e SKH01 (stesso giorno): il finding si replica su 3/3 sleeve ancorati — vedi ⚠️ nei rispettivi bullet e la stima de-luckata del book nel bullet portafoglio; diario 2026-07-02-anchor-audit-xs01-skh01.md. (4) Clock lenti (2-7g) + bande isteresi: fee drag di TP01 = ~0.4%/anno = tetto di ogni risparmio; il lag costa più del risparmio (HOLD ensemble 0.34→0.11 da N=2 a 7); a $600 il min-order $5 è GIÀ la banda ottimale (ordini 74% a costo ~0) → nessun cambio al book. (5) Velocità trend regime-condizionata (pesi tra orizzonti 30/90/180g vs percentile vol RV/DVOL): pctl 0.71 vs null pesi-statici-casuali = tilt-30d statico travestito (trappola EW-STR); pesi canonici 1/3 confermati → SCARTATO. (6-8) CRT "Candle Range Theory" (sweep-and-reclaim 3 candele, mai coperto da MRV/MIC): base 864 trial DSR 0.000 + anchor-flip + short "smart-money" negativo perfino in-sample; multi-TF (4h→15m, 1h→5m, ~10k trade) expectancy negativa ovunque anche a fee zero, e il ritest è informazione negativa (pattern con-ritest 40bps vs senza +52bps: aspettarlo seleziona i peggiori); contesto (FVG/equal-highs/sessioni, 22 trial) non salva il fade, cella "Asia" = artefatto anchor-flip → SCARTATO 3/3. Sottoprodotto: sugli stessi livelli prior-day FOLLOW > FADE ogni anno 2019-26 (conferma indipendente del lead prevday in forward-monitor). Lezione: il timing-luck d'ancora è multiple-testing che il deflated-Sharpe NON conta (candidato gate futuro anchor_luck_band). Diario 2026-07-02-timing-crt-wave.md; script scripts/research/r0702_*.py (9 file).

  • Ondata 2026-07-02-bis ("video claims": Elliott 3 filoni + Albimarini 2 + capital scaling) — 0 nuovi sleeve, 0 forward-monitor, 1 azione config pendente sul deposito. Meccanizzazione onesta di claim da video didattici: (1) Elliott range-cycle (onda1 compressa→onda3 ampia): rumore, 0/24 celle a Bonferroni, nessuna cella weekly regge a tutte le 7 ancore → SCARTATO. (2) Confluenza Fibonacci: vs null ingenui sembra buona (pctl 0.82-1.00), vs null location-matched (Fib±jitter: "0.618 vs 0.58?") crolla a 0.39-0.68 = l'apparente edge è la POSIZIONE dei livelli, non i numeri; confluenza FAIL 4/4 → SCARTATO (il null location-matched è IL test per ogni claim su livelli "speciali"). (3) Tecnica del canale Elliott: Donchian travestito — non batte il Donchian a pari geometria (corr 0.43-0.53), DSR 0.685, cella in-sample collassa in hold-out (1.40→−0.87), target 1.618 = caso (5/6 celle), anchor-luck di nuovo (4h banda hold [0.35,1.54], 00:00 la migliore) → SCARTATO. (4) Albimarini double-diagonal (short T + long T+1, deep OTM, via motore DVOL di VRP01): il condor stessa-scadenza la batte a ogni f (la long T+1 = assicurazione di coda +12/33bps nel tail, ~1bps costo medio, non dominanza); senza gate IV-rank TUTTE le strutture perdono (3ª conferma: l'alpha del VRP è il gate); su Deribit fee-negativa a QUALSIASI size (fee 8 gambe = 194-221% del theta); celle deep-OTM 0-perdite/142 trade = 2° caso "Sharpe implausibile" dopo CC01 → gate implausible_sharpe raccomandato con più forza. VRP01 resta superiore su tutta la banda skew → nessun LEAD. (5) Audit claims (28 trade, 82% win, PF 5.16, "420%/anno"): consistente con ZERO skill (P=20-45%; il 78.6% delle finestre 6-mesi 1996-2026 lo produce); replay con code reali = rovina 1998/2002/2020 col sizing dichiarato; la diagonale lascia passare il 12-40% della perdita naked. (6) Capital scaling 600→2-5k (r0702_capital_scaling.py): l'unico vincolo binding è max_notional_per_asset_usd=300 (a 5k il book live girerebbe al 49% del target) → al deposito alzare il cap a equity/2 ($1000/$1750/$2500 a 2k/3.5k/5k); min_order $5 da LASCIARE; tranching K=2 non cablare (blocco feed intraday); opzioni ETH eseguibili da ~2.6k ma la regola no-short-vol- da-modello non decade col capitale; XS01 ~20k confermata, CC01 fuori per struttura. Aspettativa onesta col CAGR de-luckato (10-15%): 2k ≈ €0.6-0.8/g, 5k ≈ €1.4-2/g (€50/g resta ≈130k). ⚠️ Lezione pandas: resample("7D", origin=...) IGNORA origin (pandas 2.x, solo RuntimeWarning) → bande d'ancora weekly finte; usare "168h". Diario 2026-07-02-elliott-albimarini-capital.md; script scripts/research/r0702_{ell_*,alb_*,capital_scaling}.py (6 file).

  • Video-claim "CRT top-down multi-TF, 74% win rate" — SCARTATO (2026-07-07): il 74% è un KNOB, non un edge. scripts/research/r0707_crt_topdown.py. Metodo ICT/SMC top-down (H1 setup CRT → M15 struttura/FVG → M5 conferma → M1 entry) con uscita parziale-70/80%-a-1.5R + break-even + runner verso prev-daily high/low. Il setup H1 CRT è già triplo-refutato (onda 2026-07-02: base DSR 0.000, MTF expectancy neg. ovunque "il ritest è informazione negativa", contesto/FVG peggiora, fade<follow) → qui testato l'UNICO angolo nuovo: la gestione d'uscita e il claim 74%. Su BTC/ETH certificati (H1→5m/15m; M1 non nel feed): WR reale 3037% a RR 1.52 (SOTTO il null gambler's-ruin 40% = P(+1.5R prima di 1R)=1/(1+1.5) → il ritest tocca il target MENO di una moneta), expectancy R negativa a ogni schema/fee/finestra/asset (1.2…−3.3R netto). Il 74% si fabbrica avvicinando il target: sweep rr1 0.5→2.0 mostra WR salire (51→32%) con expectancy R INVARIANTE (WR alto = target vicino, non direzione). DSR 0.000 (48 trial); a fee 0 expR 0.10/Sh 0.63 → non è morte-per-fee, l'edge lordo non c'è (residuo = beta di trend dei time-exit); parziale+BE+runner = 3-4 ordini/trade, alcuni sub-min-order a $600. Regola candidata: il win-rate di uno schema parziale+BE non è merito (≈1/(1+rr1)); convertire ogni claim "WR X%" in expectancy R netto fee prima di crederci (helper winrate_is_a_knob()). Diario 2026-07-07-crt-topdown-74winrate.md. Book/pesi INVARIATI.

  • Ondata WEEKEND ven→lun (2026-07-17, 4 agenti) — SCARTATO 4/4; famiglia CALENDARIO dichiarata SATURA; 1 fatto strutturale difensivo sul book. Goal "strategie che lavorino solo ven→lun a timing diversi". (1) WK-DRIFT (144 trial, griglia ore ven×lun × L/S × asset): il drift weekend è beta B&H a esposizione ridotta — null weekday: Fri = 71° pctl, sotto Mon e Sun (nessuna specialità); DSR 0.001; hold-out negativo anche a fee zero; boundary ARTIFACT-RISK. (2) WK-COND (5 gate causali × 9 timing = 99 combo): 5/5 earns_slot=False, boundary ARTIFACT-RISK 5/5; il gate TSMOM è TP01-in-weekend (β 0.67, re-timing del trend); FOLLOW-del-venerdì si inverte OOS (il lead prevday NON si trasferisce al weekend); l'unica variante HOLD+ (vol HIGH70) non è selezionabile in-sample = trappola selection-on-holdout. (3) WK-INTRA (132 celle 1h/15m: Donchian weekend, gap "CME" dom22, magnete-livelli-venerdì): ~50% celle LORDE positive = moneta simmetrica (diagnostica nuova di famiglia-rumore); il claim CME-gap è morto anche lordo; magnete del venerdì inesistente; FOLLOW>FADE riconfermato (3ª volta); a $600 l'esecuzione non è il vincolo. (4) WK-OVERLAY (lato eseguibile): il weekend porta il 38% del gross di TP01 nel 31% del tempo (positivo ogni anno) → TP01-weekend-flat è attivamente dannoso (ΔSh 0.46, P(danno)=1.000 bootstrap, banda 6/6 negativa, non-fee); half = de-levering pagato con fee (k=0.755 lo domina); boost ×1.5 n.s. → regola: non de-esporre il weekend del book; ogni futura proposta "risk-off weekend" parte REFUTED salvo null de-levering superato. Chiusura di famiglia: SEA + expiry + event-clock + 375 trial weekend ⇒ su BTC/ETH nessun edge di calendario/finestra oraria; riaprire solo con meccanismo non-calendario. Book/pesi INVARIATI. Diario 2026-07-17-weekend-window.md; script scripts/research/r0717_wk_{drift,cond,intra,overlay}.py.

  • Ondata 2026-07-25 (MAT01 + generalizzazione STATARB) — 0 sleeve nuovi, 1 DIFETTO DI DATO sul libro live trovato e riparato. Diario 2026-07-25-mat01-statarb-generalization.md. (1) MAT01 (r0725_mat01_multiasset_trend.py, r0725_mat01b_regime.py): allargare il trend difensivo da 6 a 18 ETF multi-asset-class (i 12 su disco dal 22/06, mai usati per un trend) a meccanismo GTAA CONGELATO = SCARTATO. MAT18 perde 3/4 finestre disgiunte; a PARI VOL il suo minor DD si inverte (20.6% vs 15.4%) → era solo de-levering (3ª occorrenza del null de-levering dopo VRP-DD e TP01×DVOL: e' il primo test da fare su ogni claim "meno drawdown"); corr→crypto invariata (0.110 vs 0.116) → zero guadagno di diversificazione; book 2.22→2.19. Risultato positivo da conservare: la curva d'ampiezza e' monotona (mediana OOS 0.44 a k=1 → 0.80 a k=18, DD 16.0%→−6.9%, satura a k≈10-12) — l'ampiezza E' un meccanismo reale, ma GTAA6 sta gia' al 95° pctl dei 6-subset casuali (e non e' cherry-picked: contiene TLT, il peggiore dei 18) → niente piu' ampiezza da raccogliere su questo sleeve. (2) STATARB-MULTI (r0725_statarb_multi.py): meccanismo congelato (W=45, sgn=+1) su tutte le 50 coppie alt/BTC HL, out-of-pair-sample. REGGE: 82% Sharpe>0 (media 0.38), 0/50 degeneri (mono 53% → non e' la statica short-alt travestita), perm p<0.05 nel 18% (atteso 5%), paniere Sharpe 0.82 / DD 6.0% / corr XS01 0.207. E ETH/BTC e' al rango 22/50 (58° pctl): la coppia scopritrice NON e' un outlier → per il gate 27/09 l'ipotesi "fortuna di una coppia" e' refutata. NON e' uno sleeve: ampiezza effettiva ~4.5 (corr media 0.204, gamba BTC condivisa), paniere IC95% [0.12,1.72], t 1.31 (non distinguibile da zero a 2.6 anni), uplift 0.11 vs il null a priori "sempre short alt vs BTC", 51 gambe = STAT-MODE. ⚠ Errore di metodo corretto in-sessione: il primo null statico usava sign(mean(segnale)) sull'intero campione = look-ahead; rifatto causale (media espandente) + a priori. (3) STATARB-EQ (r0725_statarb_eq.py): stesso meccanismo su 12 coppie ETF a priori, 28.5 anni, ampiezza effettiva 9.9 = SCARTATO. Paniere Sharpe 1.00 (IC95% [1.36,0.64], t 5.33), negativo in 4/4 decadi, 0% coppie a perm p<0.05. Ma la lettura sta nel LORDO (0.17, non 1.00): due terzi sono drag di turnover (0.40/g)non esiste strategia specchio (sgn=1 sarebbe lorda +0.17, netta 0.16). Il segno lordo dice che sulle azioni il residuo REVERTE debolmente mentre sul crypto CONTINUA → il meccanismo e' plausibilmente crypto-specifico. Inferenza onesta: non prova che il crypto sia falso, ma il gate 27/09 non puo' appoggiarsi all'argomento "fenomeno universale". (4) Addendum PRE-REGISTRATO al gate STATARB (registrato a forward-day 26/90, 64g prima della decisione): r0724_statarb_deploy_gate.py riporta ora anche lo Sharpe della statica sempre-short a pari vol-target sulla stessa finestra. Soglie del 24/07 NON toccate (diagnostica non binding; renderla binding e' decisione dell'operatore). Lettura odierna (26 barre): STATARB +5.70 vs benchmark 4.98, e la posizione corrente e' LONG lo spread = opposta alla statica → la finestra forward non e' spiegata dal beta di regime.

  • XSR01 "Cross-Sectional Residual" — CANDIDATO NUOVO in forward-monitor (2026-07-25). scripts/live/paper_xsr.py; scoperta r0725_statarb_basket_gate.py, scettico r0725_statarb_demean_skeptic.py, gate r0725_xsr_deploy_gate.py, test tests/test_paper_xsr.py. Cos'e': il meccanismo congelato di STATARB-RESID (W=45, sgn=+1, residuo OLS causale su BTC, z-score, tanh, vol-target 20%) applicato ai 50 alt HL, con posizioni DEMEANATE cross-sezionalmente ogni giorno. Il demeaning annulla ALGEBRICAMENTE la gamba BTC comune (sum(p_ip̄)(r_ir_btc) = sum(p_ip̄)r_i) → non e' un paniere di coppie ma una strategia cross-sectional dollar-neutral, e l'ampiezza effettiva passa da 4.5 a 37.4. Numeri (2.6 anni): Sharpe netta 1.82 (lorda 2.70), maxDD 2.6%, vol 2.3%, ret 4.2%/a. Gate superati: marginale ADDS (robust_oos + beats_noise_null + non-hedge + has_insample_edge); deflated-Sharpe 0.985 PASS; corr ~0 a TUTTI e 5 gli sleeve (TP01 0.060, XS01 0.019, VRP01 0.001, SKH01 0.001, GTAA01 0.071); book a w=15% HOLD 2.36→2.51, DD invariato. Scettico superato: 3 null a fee-neutrale (permutazione cross-sezionale / casuale / temporale a blocchi) centrati a 0.01, candidato lordo 2.70 sopra il massimo di 300 estrazioni (p<0.004); lag 1.82/1.19/0.81/0.51 a +0/1/2/3g = decadimento dolce di segnale lento, NON firma di look-ahead; non ridondante con XS-momentum semplice (corr 0.17-0.29). NON nel book, 3 motivi dichiarati: (a) storia 2.6a monoregime e crescente (Sh 2024 1.03 / 2025 1.98 / 2026 3.11) → l'edge e' recente; (b) weights_tilt_null FALLITO (gate_pass=False a 10% e 15%, delta_insample 0.004/0.007: effetto della storia corta, ma un gate fallito resta fallito); (c) margine di costo sottile — 1.82 a 0.05%/gamba, 0.93 a 0.10%, NEGATIVA a 0.20%, con turnover 38.5% del lordo/g su 50 alt anche illiquidi e slippage NON modellato (rischio #1). Eseguibilita': ticket/gamba $1.73 a $600 (sotto min-order $5 → STAT-MODE oggi), $5.76 a $2000, $14.41 a $5000 → diventa reale a **$5k**, non ai ~$20k di XS01. Gate pre-registrato 2026-10-23 (forward-day 0): deploy solo se Sharpe≥1.0 E haircut di eseguibilita' a $5000 ≤40% (se l'haircut sfonda → RITIRO a prescindere dallo Sharpe), poi weights_tilt_null e capitale ≥$5k. Monitor in cron_daily.sh, 3 libri (MODELED $2000 / REAL $600 / REAL $5000). ⚠ Lezione: XSR01 non e' nato da un'idea nuova ma dalla DIAGNOSI di un fallimento (ampiezza effettiva 4.5 → c'e' un fattore comune da togliere); e i suoi null vanno confrontati a fee zero, perche' permutare un segnale ne fa esplodere il turnover e il null perderebbe per costo invece che per assenza di informazione (p-value trionfale e falso).

  • SPLIT NON AGGIUSTATI nel feed equity — difetto sul LIBRO LIVE, riparato (2026-07-25). data/raw/eq_iwm_1d.parquet ed eq_efa_1d.parquet avevano uno split non aggiustato il 2005-06-09 (IWM 2:1 = 49.5%; EFA 3:1 = 66.5%); IB ADJUSTED_LAST non li aveva aggiustati. La certificazione non li vedeva per un punto cieco strutturale: l'unica guardia era maxret > 50% → SPIKE? e uno split 2:1 fa esattamente 50% → IWM passava a 49.5% con status OK. IWM e' una delle 6 gambe di GTAA01 in produzione. Impatto: GTAA6 FULL Sh 0.61→0.64, IS 0.49→0.54, OOS 2015+ e maxDD INVARIATI (artefatto nel 2005, fuori hold-out) → il difetto SOTTOSTIMAVA lo sleeve, nessuna decisione presa va rivista. Discriminante split-vs-crollo (riusabile): non il rapporto (SLV 2026-01-30 ha rapporto 1.3994, a 4bps da 1.4, ma e' un crollo vero: GLD 10.3% lo stesso giorno) ma il RANGE INTRADAY — lo split apre gia' al nuovo livello con range normale (IWM: open 47.00, range 1.7%), il crollo si muove DENTRO la barra (SLV: range 33%). Modulo src/data/eq_splits.py (detect_unadjusted_splits a 3 condizioni congiunte + repair_splits componibile), riparazione in lettura in src/portfolio/gtaa.py::_close e scripts/research/eqlib.py::load_eq, status SPLIT-NON-AGG in fetch_ib_equities.certify(), test tests/test_eq_splits.py (8 casi). Regola nuova: ogni soglia di certificazione tarata su un valore tondo va controllata contro il difetto che genera esattamente quel valore (una soglia a 50% non puo' sorvegliare gli split 2:1).

  • RENDITA / CURVA CAPITALE (2026-07-25, 2° filone del giorno) — il muro del 24/07 era ottimista 2-4x, e 1 DIFETTO DI ESEGUIBILITA' su GTAA01. Script r0725_capcurve.py + r0725_prop_config.py, test tests/test_capcurve.py (10 casi); diario 2026-07-25-rendita-capcurve-prop.md. Book/pesi/cron INVARIATI. (1) GTAA01 non e' eseguibile come codificato. gtaa.py modella 2bps proporzionali e lo sleeve e' documentato "switch mensile/basso turnover": FALSO — il vol-target e' continuo giornaliero su 6 gambe, e IB ha un pavimento FISSO min(max($0.35, $0.0035/az), 1% valore) per ordine = ~$530/anno indipendenti dal capitale. A $600: CAGR 3.5% / Sh 0.55; negativo fino a ~$3k; a $50k 0.59. La banda lo salva: plateau robusto weekly x banda $25-100 → Sh 0.45-0.64 a ogni capitale (a $600: Sh 0.52 / CAGR 3.0%). ⚠ Correzione a un errore MIO: la prima stesura citava il modello vecchio a "0.77/5.5%" — era un artefatto di annualizzazione (metricavo la serie GTAA grezza a ~252 barre/anno con metrics() che annualizza a 365 → Sharpe ×1.20, CAGR ×1.45). Valore vero del modello vecchio: 0.64/3.8%. Quindi il difetto NON e' "sovrastimava di 0.13": alla taglia grande il modello vecchio era GIUSTO (0.64 vs 0.59-0.66 reali). Il difetto e' che era CIECO AL CAPITALE — dava 0.64 sia a $50k sia a $600, dove la realta' e' 0.55. Lezione: una serie su giorni di borsa (~252/anno) non si passa a metrics() (che annualizza a 365) senza to_daily() — il Sharpe esce ×1.20 e il CAGR ×1.45. FIX CABLATO (stessa sessione, src/portfolio/gtaa.py): costo IB reale (ib_commission), esecuzione a banda+cadenza (settimanale, $50/gamba), gtaa_returns(capital=...) capital-aware, soglia GTAA_MIN_CAPITAL=$3.000 + gtaa_is_deployable, e gtaa_rebalance_plan(held, capital) per l'esecutore (salta le gambe sotto banda). sleeves.py dichiara il capitale assunto (GTAA_DEFAULT_CAPITAL=$10.000 ≈ book $50k al peso 20%). Impatto book misurato: FULL 2.22→2.22, HOLD 2.36→2.38, DD 6.2→6.0% = trascurabile alla taglia assunta; il fix conta per il DEPLOY (a $600-2k: da 3.5%/anno a +3.0%/anno). Pesi INVARIATI. Test tests/test_gtaa_sleeve.py (+4). REGOLA NUOVA: il costo di un venue va modellato nella sua FORMA (fisso vs proporzionale), non solo nel livello — due venue a pari "costo medio" danno esiti OPPOSTI al variare del capitale (il pavimento fisso e' una tassa regressiva). Controprova: su Deribit (proporzionale, senza pavimento) lo Sharpe realistico di TP01 = modellato da ~$500 in su → conferma indipendente di "a $600 il min-order $5 e' gia' la banda ottimale". (2) La rendita NON e' capitale x CAGR. Il 24/07 calcolava capitale = target/CAGR (€122k a CAGR 15%), ignorando il rischio di sequenza. Bootstrap a blocchi sui ritorni REALI (SKH01 su path live): rendita perpetua (= prelievo con P(cap a 20a >= cap iniziale) >= 90%) del book de-luckato ×0.6 = 5.98% → $497k; SWR-20a 7.31% → $406k; lente modellata 13.57% → $219k. ~Il muro vero e' una BANDA $232k-$497k, stima centrale $300-400k. ⚠️ AGGIORNATO 2026-07-26 — il ×0.6 era MISURATO troppo severo del 31-34% → il muro scende del ~45%. Il fattore d'ancora onesto sul drift e' ×0.89 per il book live (misurato, non a occhio) e ogni componente del path live e' non-negativa (bullet in fondo). Ricalcolo con la STESSA macchineria (r0726_capwall_refresh.py): perpetua 6.00% → 10.91%, muro $494.758 → $272.061 a leva 1.0 (a leva 1.5: $366k → $200k). Il ×0.89 e' un limite inferiore del fattore, quindi il muro vero sta fra la riga ×0.89 e la riga ×1.00 ($233k). La conclusione STRUTTURALE non cambia: $272k restano ~453× il conto di oggi → i €600 come CAPITALE restano refutati, come BIGLIETTO (prop) no. Rendita a $600: €0.12/g → €0.18/g (centesimi: il fattore conta per il MURO e le soglie prop, non per il conto attuale). Cio' che NON dipende dalla lente: la rendita perpetua vale ~45-55% del CAGR, quindi ogni muro calcolato come target/CAGR sbaglia di un fattore ~2. TRAIETTORIA da $600, ricalcolata col fattore corretto (26/07). Il fattore agisce due volte: alza il drift (si accumula prima) E abbassa il bersaglio (serve meno capitale), e i due effetti pesano quasi uguale. Mediana degli anni per toccare il capitale-rendita:

    dep./mese ×0.60 muro $495k (25/07) ×0.89 muro $495k (solo drift) ×0.89 muro $272k (26/07)
    €0 mai mai mai
    €250 22.4a (8% entro 20a) 19.6a (53%) 16.2a (91%)
    €500 19.6a (48%) 15.7a (94%) 12.4a (100%)
    €1000 14.8a (95%) 12.0a (100%) 9.0a (100%)
    €2000 10.0a (100%) 8.5a (100%) 6.0a (100%)
    **QUESTA TABELLA E' AL LORDO del fisco d'accumulo — la versione NETTA e' nel bullet "IL FISCO
    DURANTE L'ACCUMULO" (r0807_piano_netto, 07/08) e cambia la riga di testa: €250/mese passa da
    P(20a) 92% a 52%.** Le colonne qui restano perche' sono la replica di controllo del fattore
    d'ancora, non perche' siano il piano.
    La colonna ×0.60 riproduce esattamente i numeri del 25/07 (19.6a / 14.8a) = validazione
    indipendente della replica. ⚠️ **Cio' che NON cambia col fattore: senza depositi il
    capitale-rendita non si raggiunge mai** (0% dei path a 20 anni a OGNI fattore) — l'accumulo
    viene dai versamenti, non dal rendimento; e la mediana e' una MEDIANA (meta' dei path arriva
    dopo, una quota non arriva affatto).
    QUANTO VERSARE PER UN ORIZZONTE DATO (bersaglio $272k, ×0.89; "arrivarci in N anni" non e'
    un numero: dipende dalla confidenza):
    orizzonte P=50% P=75% P=90%
    --- --- --- ---
    10 anni €806/m €995/m €1.178/m
    15 anni €313/m €408/m €509/m
    20 anni €129/m €180/m €237/m
    AL LORDO: i numeri da usare sono quelli NETTI (€1.323 / €672 / €371 a P=90%, bersaglio
    $258k) nel bullet "IL FISCO DURANTE L'ACCUMULO" — il fisco costa **+12% al mese a 10 anni, +32%
    a 15, +57% a 20**.
    ⚠️ Comprimere l'orizzonte da 20 a 10 anni costa 2.5× al mese E 2.5× in totale: a 10 anni
    versi $155k per arrivare a $272k (il rendimento fa il 43%), a 20 anni ne versi $63k (il
    rendimento fa il 77%). **A orizzonti corti non fai lavorare la strategia, COMPRI il
    capitale coi bonifici** — il confronto onesto e' sempre totale versato vs bersaglio.
    Drill-down €250/m (5000 path): traguardo p10 13.4a / mediana 16.2a / p90 19.7a;
    P(entro 15a) 31% → P(entro 20a) 92% (la curva non da' segnali per un decennio e poi si
    muove tutta insieme: chi giudica al 5° anno giudica nel punto peggiore); al traguardo hai
    versato ~$54k su $272k → 80% viene dal rendimento. ⚠️ Bug catturato in sessione: il
    contatore paid si congelava al traguardo mentre cap continuava a ricevere i depositi →
    rapporto capitale/versato gonfiato (46× invece di 25× a 30 anni); test di regressione cablato.
    (3) Diversificare NON crea reddito a pari nozionale — libera BUDGET DI RISCHIO. Per tier:
    iso-nozionale 2 sleeve 5.98% → 4 sleeve 6.35% (nulla, il diversificatore a basso CAGR toglie vol e
    ritorno insieme); a ISO-RISCHIO (vol 15%) 7.51%/$395k → 9.25%/$321k (19% di muro).
    REGOLA: un diversificatore a basso CAGR si giudica a ISO-RISCHIO, mai a iso-nozionale (e' il
    null de-levering al contrario). L'ipotesi "piu' capitale → piu' sleeve → CAGR super-lineare" e'
    REFUTATA nella forma forte: la curva Sharpe del book eseguibile e' PIATTA da $600 a $200k.
    (4) ASIMMETRIA CAPITALE-PROPRIO vs FUNDED (risultato strategico). Il 24/07 valuto' il fronte
    prop solo col book a 2 sleeve; ma su un conto funded il capitale e' $100k → **gli sleeve STAT-MODE
    per taglia (XS01, ~$20k) diventano eseguibili**, e le regole prop passano sul **DRAWDOWN, non sul
    CAGR**. Finestra comune 2024+, de-luck, crypto-only: P(pass) HYRO 1.0x 44.4%→54.7%, FTMO 1.5x
    51.9%→70.0%; funded HYRO 1.0x P(vivo 1a) 18.9%→57.6% (3x), FTMO 1.0x 58.8%→92.0%,
    E[payout] $8.7k→$9.3k (~€15.7/g atteso). Si RIBALTA la raccomandazione "funded a 0.75x": col book
    diversificato 1.0x e' sostenibile. **In una riga: sul capitale proprio diversificare non aumenta il
    reddito; su un conto funded si', perche' li' il vincolo binding e' la regola di DD, non il capitale
    → gli sleeve "inutili a $600" sono gli asset di maggior valore sull'unico canale che scala.**
    ⚠ CAVEAT: MC close-only (C-bis 24/07: i wick tagliano 6-37pp) → livelli assoluti = TETTO, il
    DELTA e' la misura onesta ed e' conservativo (B ha vol minore); la finestra comune 2024+ e' quella in
    cui XS01 e' stato scoperto/affinato → la TAGLIA del guadagno e' ottimista (finestra piena: 56.9%→58.5%),
    il MECCANISMO (corr bassa → meno DD → piu' sopravvivenza sotto vincolo di DD) e' robusto.
    (5) LA VIA: i 600 euro come BIGLIETTO, e il problema della correlazione fra conti
    (r0725_prop_ladder.py). I €600 come capitale sono refutati; come biglietto no: si compra
    un'eval, il funded moltiplica il NOZIONALE senza possedere capitale, i payout comprano altri
    biglietti. Il 24/07 si fermava a UN conto (cap $200k/firm → ~€15-30/g); **50 EUR/g richiede piu'
    conti**, e li' il problema mai studiato: N conti sullo STESSO book bustano INSIEME (corr 1.0)
    → la diversificazione fra conti e' illusoria salvo sleeve diversi su conti diversi. E' un
    problema di portafoglio sotto barriera di rovina PER-CONTO. Sim 36 mesi, €600, max 6 conti,
    2 firm, regole vere, payout mensile prelevato subito, fisco 33%, morte-firm 10%/anno,
    bootstrap CONGIUNTO (corr reali). Vince il MISTO, non gli estremi (close-only, leva 1.0x):
    MISTO mediana €10.70/g, P(≥50/g) 20.7%, P(zero) 33.4% > CONC-DIV 5.70/17.8%/33.4% > SPARSO
    0.00/16.8%/66.0% > CONC-2SL (= il book live attuale) 0.00/13.1%/55.6% = la PEGGIORE.
    Logica: ogni conto serve Sharpe per sopravvivere alla PROPRIA barriera (uccide SPARSO), ma i
    conti servono decorrelati fra loro (penalizza CONC). Con lente INTRADAY (wick) tutto crolla:
    P(≥50/g) 1.6-2.5%, P(zero) 78-90%. ⚠ Il mio wick e' un PAVIMENTO: gap estratto INDIPENDENTE
    dal rendimento del giorno → breach spuri → **follow-up dichiarato, poi CHIUSO lo stesso giorno
    (bullet successivo): la stima onesta e' P(≥50/g) ~6%, P(zero) 52-65%.** Il confronto fra POLITICHE
    e' robusto (stessa lente per tutte) — **verificato a posteriori sulla lente accoppiata: l'ordine
    MISTO ≥ CONC-DIV > CONC-2SL ≈ SPARSO regge a tutte e 3 le lenti** → **se si apre il fronte prop,
    NON mandarci il book live attuale**.
    (6) ADDENDUM "e se metto 10K su IB?" (r0725_ib10k.py): allocazione fra venue, non domanda su
    GTAA01. Deribit = motore (CAGR ~11% de-luck), IB/GTAA01 = diversificatore (CAGR ~3.9%).
    A $11.5k totali: 0% su IB → €2.16/g; 50% → €1.54/g (Sharpe migliore 1.13, DD 15.3→11.2%);
    94% (= i 10k su IB) → €0.93/g = REDDITO PIU' CHE DIMEZZATO. La via d'uscita (levare per
    convertire lo Sharpe in reddito) e' chiusa dai costi: su ETF a IB con €10k c'e' Reg-T 2x max
    (portfolio margin da ~$110k) e il margine costa ~5.5%/anno → contando il finanziamento vince
    tutto-Deribit a 1.33x (rendita €1.33/g vs €0.92/g a 50/50). **REGOLA: l'argomento iso-rischio
    (punto 3) vale solo se la leva e' (a) disponibile e (b) a costo < uplift — su un retail da €10k su
    ETF non lo e'.** Confronto che ridimensiona GTAA01: €10k nello sleeve = €0.93/g con maxDD 10.5%,
    gli stessi €10k FERMI a ~2% = €0.54/g con maxDD ~0% → premio ~€0.50/g pagato con un DD del 10%.
    Raccomandazione: i depositi vanno su Deribit; al massimo 25% su IB (costa ~€0.08/g di
    rendita, taglia il maxDD 15.3→12.0%, unico split che regge coi costi). ⚠ Il confronto FAVORISCE il
    crypto per costruzione (7 anni con 2 bull vs 30 anni di GTAA); tassi e aliquote (26%/33%) sono
    assunzioni dichiarate, da confermare col commercialista (non un parere fiscale).
    (7) HYROTRADER nello specifico (r0725_hyro.py): la firm meglio classificata per questo book
    (API reale da funded, nessun limite di tempo, weekend consentito — e il weekend porta il 38%
    del gross di TP01). Ipotesi REFUTATA: la regola di consistency 40% NON morde (costo ≈0pp a
    ogni leva/lente) perche' il book accumula il 10% in 130-300 giorni → nessun giorno si avvicina al
    40% del cumulato; ⚠ prima di dichiararlo ho dovuto provare che il controllo funziona (un
    "costo 0" puo' essere un bug): su un book con profitto concentrato in 1-2 giorni la regola porta
    P(pass) da >90% a <5% (test cablato). Il vincolo vero e' il maxDD 6% STATICO: config A (book
    live) ha maxDD 9.5% > 6% = strutturalmente incompatibile a leva piena — intraday a 1.0x
    sopravvive l'1.4%; config B (+XS01) ha maxDD 6.2%, Sharpe 1.13. ~~**Funded consigliato: config B
    a 0.50x**~~ → CORRETTO a 0.75x dalla lente accoppiata (bullet successivo): il 0.50x era scelto
    perche' il wick indipendente dava a 0.75x P(vivo) 55%; la lente onesta da' 76%, e 0.75x
    massimizza il payout atteso su 3 anni ($2.674 vs $1.230 a 0.50x e $1.992 a 1.00x). L'argomento
    "la sopravvivenza COMPONE su piu' anni" resta valido: si sposta il punto in cui morde.
    EV del biglietto $100k positivo in entrambe le lenti (+$6.789
    close-only, +$1.166 intraday), ma ~69% di perdere la fee nella lente pessimista. Cap $200k/trader
    ⇒ ~€15-30/g max → per €50/g servono piu' firm (punto 5). Discrepanza col 24/07 (P(vivo) A@0.75x
    58% vs 10% mio) RISOLTA: non era la finestra, era la lente — sulla stessa finestra piena la
    lente accoppiata da' 63.2% vs il 58% del 24/07 (accordo entro 5pp, implementazioni separate).
    ⚠ Bug catturato in sessione: base di prelievo funded aggiornata giornalmente come HWM mobile →
    guadagno al checkpoint ≈ 0 → payout $230/anno invece di ~$7.000; regole vere = max-loss STATICO
    dal saldo iniziale + base ripristinata dopo il prelievo. Test di regressione cablato.
  • LENTE WICK ACCOPPIATA (2026-07-25, follow-up del bullet precedente — CHIUSO). Script r0725_prop_coupled.py, test tests/test_prop_coupled.py (13 casi), diario 2026-07-25-prop-wick-accoppiato.md. Book/pesi/cron INVARIATI. Generalizza il recon MTM di r0724_goal50_intraday_mc.py: (a) sleeve TP01/SKH01 separati a risoluzione oraria → il minimo intraday si compone ESATTO per QUALSIASI vettore di pesi (prima erano cablati 75/25); (b) XS01 accoppiato dagli OHLC giornalieri HL (4 checkpoint, ordine condiviso avverso; recon = sleeve ufficiale a max|Δ|=0.0). ⚠️ IL FINDING: la CALIBRAZIONE del wick era giusta, l'errore era l'INDIPENDENZA. Le marginali coincidono quasi (p50 0.17pp identico, p90 1.03 vs 0.90, p99 2.70 vs 3.50) — sbagliava su quali giorni cadono i tuffi. E la dipendenza va nel verso inatteso: il gap e' ~3× piu' profondo nei giorni che finiscono BENE (1.58pp nel decile migliore vs 0.48pp nel peggiore), perche' un giorno brutto scende tutto il giorno e chiude sul minimo (m==R nel 26% dei giorni). Il breach si valuta sul minimo → l'estrazione indipendente carica i giorni brutti con la coda dei giorni buoni e raddoppia i breach da daily-loss (2.0-2.9×, misurato sui giorni storici). close-only non e' conservativa, e' CIECA: 0.00% di breach da daily-loss su OGNI configurazione (la regola non scatta mai sulle chiusure) → usarla come controllo, mai come stima. Verifiche (un "nessuna differenza" va provato): (1) 1h vs 5m sulla gamba TP01 = identici (p99 3.06 vs 3.14pp) → il caveat di risoluzione portato avanti dal 24/07 e' quantificato e trascurabile, l'ora cattura gia' il minimo del giorno; (2) riconciliazione col 24/07 (sopra); (3) bound severo su XS01 (ogni gamba al proprio peggio insieme): config B resta sopra config A (P(vivo) 57.6% vs 39.4%) → la conclusione non dipende dalla convenzione. Decisioni: funded 0.75x (non 0.50x, vedi sopra); scala di conti P(≥50/g) ~5.6-6.5% in 3 anni (non 1.6-2.5% ne' 20.7%) con P(zero) 52% a 0.75x / 65% a 1.00x, e P(≥10/g) massima a 0.75x (29.7%) = stesso ottimo di leva del conto singolo. Ordine fra politiche INVARIATO a tutte e 3 le lenti. Verdetto ristretto: €600→€50/g ≈ 6% in 3 anni, P(perdere i €600) ≈ 52-65% — resta coda destra, ma con probabilita' conoscibile invece di una banda di un ordine di grandezza. REGOLA NUOVA: un modello di rischio intraday NON si valida sulla marginale del wick ma sul suo ACCOPPIAMENTO al rendimento del giorno — qui un test "i percentili coincidono" sarebbe PASSATO con la stima sbagliata di 2-3×. Ogni regola valutata sul minimo (daily-loss, trailing DD, stop di conto) va misurata su tuple accoppiate, mai su un wick estratto a parte.

  • Ondata 2026-07-26-bis (TP01 su barra parziale + i 2 gate mai costruiti) — 0 sleeve nuovi, 1 audit sul libro live, 2 gate codificati, 1 falso positivo MIO su uno sleeve in produzione. Script r0726_tp01_partial_day.py + r0726_gates_retro.py, test tests/test_gates_implausible_anchor.py (13), diario 2026-07-26-wave-tp01-partial-gates.md. Book/pesi/cron/config INVARIATI. (1) T1 — anche TP01 legge una barra giornaliera PARZIALE nel live, ma non conta. Stesso fatto strutturale di SKH01: resample_tf non scarta il giorno in corso e current_target prende [-1]; il feed si ricostruisce alle 00:30 UTC → tutto il giorno il book vede oggi come 1 barra oraria su 24 (verificato barre1h=1/24). Docstring "ultima barra CHIUSA" falso, corretto (3ª volta in 2 giorni che un docstring di produzione dichiara una causalita' che il codice non ha). Tre path a un grado di liberta' per volta, 24 ancore, differenze appaiate: barra parziale ΔFULL 0.031 (pos. 7/24) / ΔHOLD +0.118 (pos. 19/24); ritardo d'esecuzione 1h 0.004 (11/24 = moneta); leva gonfiata +0.4%. → trascurabile, nessun cambio al live. ⚠️ All'ancora canonica sembra peggio del vero: a offset 0 la parziale costa 0.230 di hold-out = il minimo dell'intera banda (mediana +0.118) → guardando solo l'ancora canonica avrei concluso "il live degrada TP01": speculare alla lezione del 26/07 (li' l'ancora canonica nascondeva un vantaggio, qui inventa un danno). REGOLA NUOVA (il risultato trasferibile): la parzialita' dell'ultima barra conta in proporzione a quanto il segnale pesa la barra piu' recente. SKH01 = Donchian breakout su 230m, la barra corrente E' il segnale → +0.38; TP01 = TSMOM 30/90/180g, l'ora mancante e' 1/24 di UNA osservazione su 30-180 → ±0.03. La conclusione non si trasferisce fra sleeve. (2) T2 — implausible_sharpe e anchor_luck_band CODIFICATI in altlib.py (debito raccomandato 3 volte — 26/06 CC01, 02/07 Albimarini "con piu' forza" — e mai scritto). implausible_sharpe: Sharpe>3, perdite/attive<2%, Calmar>20 o maxDD~0, regola del tre (0 perdite su N → tasso vero fino a 3/N: e' perche' "0/142" non si legge "senza rischio"). anchor_luck_band: la griglia d'ancore NON e' una griglia di parametri → il deflated-Sharpe non la conta; riporta stima onesta = mediana della banda e fortuna = canonica mediana. anchor_luck_delta: mediana delle differenze appaiate (codifica l'errore del 26/07). ⚠️ Il gate ha segnalato VRP01 e il difetto era MIO: perdite contate su TUTTE le barre, ma VRP01 e' settimanale su griglia giornaliera = 94.2% di zeri → "0.96%, coda assente" su uno sleeve in produzione; sulle barre ATTIVE e' 16.5%, la forma giusta di un credit spread a rischio definito. E la lezione era gia' cablata il giorno prima nel monitor DVOLSPREAD ("barre attive, non giorni di calendario") — imparata in un contesto, non applicata nell'altro. Zeri per sleeve: VRP01 94.2 / SKH01 87.6 / XS01 39.6 / GTAA01 31.9 / TP01 30.7%. Applicazione retroattiva 7/7 — tutti ok: TP01 1.29, XS01 1.36, VRP01 1.08, SKH01 1.45, GTAA01 1.01, **XSR01 1.79 (DD 2.5% ma 47.8% di barre attive in perdita → il DD basso e' vol bassa

    • dollar-neutrality, NON una coda mancante: per il gate del 23/10 il rischio #1 resta lo slippage)**, DVOLSPREAD 0.68. Controlli positivi obbligatori superati (firme CC01 e deep-OTM segnalate, rumore Sh 0.62 no) — un gate che non segnala nulla puo' essere semplicemente rotto. Replica indipendente del finding d'ancora del 02/07: il gate applicato alla cieca a TP01 ritrova canonica +0.237 = 92° pctl delle 24, mediana onesta +0.056, banda [0.087,+0.247], fortuna +0.182 — contro mediana 0.04 / banda [0.13,+0.30] misurate il 02/07 con implementazione SEPARATA. L'hold-out onesto di TP01 e' ~+0.05, non 0.31 (il valore del sleeve resta il taglio del DD ~6× vs buy&hold, che non e' ancorato). (3) NON fatto e perche': il book sul path live e' bloccato da una incompatibilita' di lenti — il simulatore SKH01 compone per-trade a nozionale unitario, lo sleeve e' vol-targeted. Follow-up dichiarato: serve la versione vol-targeted del path live di SKH01. CHIUSO 2026-07-26 — E IL BLOCCO NON ESISTEVA: la premessa era FALSA. Lo sleeve SKH01 non e' vol-targeted (backtest_signals(..., leverage=1.0, position_size=1.0), nessun target_vol nel sorgente, e sim_equity(canonical) riproduce backtest_signals a max|diff| = 0.0): le due lenti erano gia' la stessa cosa. Il 20.7% di vol realizzata dello sleeve — probabilmente cio' che aveva suggerito "vol-target 20%" — e' un prodotto della strategia (uscite % asimmetriche + poco tempo a mercato), non un parametro; SKH01 e' l'unica delle 5 a NON essere vol-targeted, il contrario di quanto si credeva. Vedi bullet dedicato in fondo e diario 2026-07-26-skh-live-book-deluck.md. REGOLA: un blocco dichiarato e' un'ipotesi, non un fatto — si ri-verifica prima di costruirci sopra o di rimandare (qui: tre sessioni di follow-up rimandato contro due minuti di verifica).
  • Ondata 2026-07-26 (3 filoni: esecuzione SKH01 / DVOLSPREAD / XSR01 fuori dal crypto) — 0 sleeve nuovi, 1 raccomandazione operativa aperta, 1 lead promosso, 1 falsificazione. Script r0726_{skh_onbook,dvolspread_gate,xsr_equity}.py, test tests/test_wave_0726.py (11 casi), diario 2026-07-26-wave-esecuzione-dvolspread-xsr-equity.md. Book/pesi/cron INVARIATI. (1) ⚠️ T1 — IL DEGRADO D'ESECUZIONE DI SKH01 ERA ANCH'ESSO FORTUNA D'ANCORA. Testato l'unico meccanismo che non e' un cron (ordini resting on-book: TP = limit al livello per costruzione + fee maker; SL = stop-market). A offset 0 l'on-book recupera il 94% del degrado — ma l'audit 02/07 aveva de-luckato i numeri headline di SKH01 e NON il degrado, misurato solo a off0. Sulla banda appaiata dei 23 offset il degrado massimo recuperabile e' +0.054 Sh di book, non 0.35 di sleeve. ⚠️ Errore di metodo mio, corretto in sessione: mediana(A)mediana(B) fra offset e' sbagliato (confronta offset diversi) → serve la mediana delle DIFFERENZE appaiate; con quella il verdetto si RIBALTA. Esito: solo TP a limite = +0.054 FULL / +0.061 HOLD, positivo in 19/23 (FULL) e 21/23 (HOLD) offset; lo SL on-book PEGGIORA (contributo mediano 0.010, positivo in 11/23 = moneta) perche' cristallizza la perdita al livello mentre l'exit software ritardata incassa il rimbalzo — e sopra 0.50% di slippage l'on-book e' peggio del live. Meccanismo misurato: sulle uscite TP il fill orario batte il livello nel 42% dei casi (vantaggio medio 0.035%) → il limit TP converte una lotteria in certezza piu' che aggiungere ritorno; solo l'1% degli SL gappa davvero a 5m. RACCOMANDAZIONE NON ESEGUITA (decisione dell'operatore): TP come limit resting reduce-only, SL strategico NON on-book. E' un cambio di esecuzione (non passa weights_tilt_null) ma piccolo, da pesare contro ordini orfani/doppio fill. Il disaster-SL 30% on-book resta com'e'. T1 NON IMPLEMENTATO — e il perche' e' una CORREZIONE DI MODELLO (2026-07-26, diario 2026-07-26-t1-esecuzione-skh-live.md). Leggendo il codice di produzione: TP01 e SKH01 tradano lo stesso strumento con una sola posizione netta Deribit → un ordine on-book al livello di SKH chiuderebbe anche quota TP01. Misurati i 2 ostacoli: (A) segno compatibile nel 97% dei trade che escono in TP (long 100%, short 94%) = risolvibile; (B) divergenza modello/live che sembrava bloccante (ritardo mediano 115 min, 70% dei TP con ≥1 cron dentro la finestra). ⚠️ MA (B) NON ESISTE: resample_5m NON scarta il bin 230m in corso (verificato: 21 barre 5m su 46 nell'ultimo bin) e _skyhook_positions ci itera dentro → il live rileva gia' SL/TP intra-barra, entro ~1h dal tocco. I docstring che dicevano "usa solo barre chiuse" / "latenza fino alla chiusura della barra 230m" erano FALSI e hanno guidato 3 analisi (02/07, 24/07, T1) — corretti sul posto. Conseguenza: la lente hourly sottostima il path live di +0.081 Sharpe FULL di book (23/23 offset, banda appaiata), il live vero sta sopra il canonical sul FULL, e il fix richiesto sarebbe un DECLASSAMENTO (+0.054 vs +0.081) in cambio di ordini parziali sul netto in un percorso con soldi veri. → non fatto, per misura, non per difficolta'. CABLATO INVECE il problema vero trovato per strada: fresh_5m fallisce in SILENZIO (fallback al feed certificato, rigenerato 1x/giorno) → la latenza d'uscita di SKH01 passa da ~1h a ~1 giorno senza che nulla lo segnali (conto online, posizione leggibile, e il gate di staleness guarda il feed di TP01: nessun controllo esistente scatta). Stesso schema del feed-freeze del 14/07, su un altro feed. Aggiunti: livefeed.feed_age_minutes (pura, eta' dalla CHIUSURA della barra, None=non misurata, clamp sugli skew), book_report.skh_feed_age_min (max fra gli asset), allerta Telegram in book_execute sopra skh_feed_max_age_min=30 min. Scelta dichiarata: ALLERTA, NON blocca — bloccare fermerebbe anche TP01 (nettato sullo stesso strumento) per un guasto di rete, e forzare SKH flat chiuderebbe posizioni buone su un glitch. Test tests/test_skh_feed_freshness.py (11 casi). Strategia/pesi/cadenza INVARIATI. ⚠️ SEGUITO 2026-07-29 — l'allerta ha funzionato, la sua CAUSA era una riga CABLATA. Diario 2026-07-29-feed-skh-causa.md; test 11 → 16. Book/pesi/config/strategia INVARIATI. Il 29/07 (dopo il riavvio VPS delle 04:11) il feed e' ricaduto sul certificato in 6 giri orari su 8 fra le 05:00 e le 12:00: eta' 265→685 min (+60 a ogni giro = firma esatta del fallback) → latenza d'uscita SKH01 da ~1h a ~11h; book flat, nessuna posizione esposta. L'allerta ha segnalato 6/6 — poi ha stampato un perche' che non aveva misurato: la nota "fetch pubblico KO" era cablata, identica in ogni caso, compreso quello in cui la coda fresca E' attaccata e il vecchio e' il certificato stesso (= feed-freeze 14/07 in altra veste). E la causa vera non era recuperabile a posteriori per costruzione: _fetch_recent_5m ingoia l'eccezione di pagina con un break e a prima pagina fallita ritorna un frame vuoto, indistinguibile da "il venue non ha barre"; alle 12:14, a mano, fresh_5m rispondeva in 1.7s senza errori. Cablato: livefeed.last_fetch_error() (+_note_error, registra E logga nel punto in cui l'errore viene ingoiato) → book_report.skh_feed_errors (per asset) → allerta con la causa; e stesso buco chiuso sul ramo gemello "conto offline", che aveva gia' la ragione in mark_src e non la stampava mai. Tre guasti ora distinti: eccezione / risposta vuota / certificato vecchio con coda attaccata. Blindati anche il caso a meta' paginazione (coda parziale attaccata: la paginazione va in avanti → mancano le barre PIU' RECENTI) e la non-sopravvivenza della causa a una chiamata riuscita. ⚠️ La causa del 29/07 resta IGNOTA, e va citata cosi'. Solo circostanziale: giri falliti lunghi quanto i riusciti (16-46s → errore immediato, non timeout); finestra aperta col riavvio ma non chiusa da esso (11:00 ok, 12:00 no); stesso giorno il percorso del conto (rete diversa via cerbero-mcp, stesso venue a valle) dava ReadTimeout/404/502; i due percorsi falliscono in alternanza, non insieme. Una prima stesura scriveva nei commenti "rate limit Deribit per-IP saturato da un altro progetto sulla stessa VPS" come fatto: rimossa — sarebbe stato lo stesso difetto che stavo correggendo, scritto meglio. Cron spostato 0 * * * *7 * * * * (ipotesi contesa al minuto tondo): ripiego da UNA osservazione, costo zero, dichiarato tale in testa a cron_book.sh perche' la riga di crontab vive fuori dal repo. SEGUITO 2026-07-30 — il MECCANISMO ipotizzato e poi rimosso e' ora MISURATO; il "perche' adesso" NO. Analizzando /opt/docker/cerbero-bite (stessa VPS, stesso IP pubblico): il suo collettore full-chain gira al minuto :00 e produce 12.186 risposte 429 in 26 ore, di cui 11.700 (96%) nel minuto :00 — ~770 chiamate ticker + ~770 orderbook in ~26s da un IP solo, senza backoff → si auto-satura il rate limit Deribit per-IP (ticker: 5.738 respinte su 20.029). Co-timing esatto con l'incidente: le sue quote passano da ~0.4% a ~50% vuote alle 05:00 del 29/07 e non sono ancora rientrate. ⚠️ Ma la stessa disciplina vale due volte: il carico di bite e' INVARIATO da settimane (6.100-6.400 righe BTC/giorno prima e dopo, immagine ferma al 09/06) e i log MCP non precedono il riavvio → le 429 spiegano come si perdono le chiamate, non perche' proprio quel giorno. La causa del cambiamento resta ignota. Nessuna azione: cron_book e' gia' a :07, fuori dalla finestra di ~26s. Diario 2026-07-30-vrp-quote-reali.md. REGOLE: (a) una nota di diagnosi cablata e' peggio di nessuna nota — nessuna manda a guardare i dati, una sbagliata manda sulla pista sbagliata e sembra una misura; (b) se un errore si ingoia per non bloccare, si registra nel punto in cui lo si ingoia (non c'e' un secondo momento buono: quando la diagnosi serve, il guasto e' rientrato); (c) un'allerta risponde a due domande — cosa (decide) e perche' (ripara): misurare solo la prima costa un'intera occorrenza del guasto; (d) distinguere guasti diversi anche quando l'azione e' la stessa (tre cause → tre riparazioni); (e) una mitigazione da un'osservazione sola si applica pure, ma si scrive che lo e'. FOLLOW-UP CHIUSO 2026-07-26 — la misura dedicata sugli INGRESSI e' fatta: NON e' un difetto, il verso e' LASCIARLO. scripts/research/r0726_skh_partial_entry.py, test tests/test_skh_partial_entry.py (10), diario 2026-07-26-skh-partial-entry.md. Confronto di due path identici in tutto (livelli, uscite intra-barra, cap, fee) tranne quando si valuta l'ingresso: LIVE = a ogni confine orario dentro il bin 230m (cio' che il cron fa oggi), BACKTEST = solo a chiusura di bin. ΔSharpe su 3 offset x 2 asset: 0.01/+0.04/+0.44/+0.32/+0.59/ +0.98 → 6/6 non negativi, mediana +0.38. All'offset 0 (l'ancora fortunata del backtest, 93-98° pctl) l'effetto e' ~0 sul FULL ma l'hold-out BTC fa 1.12 live vs 0.71 backtest. I falsi ingressi (segnale che evapora) sono ~5/anno/asset, e cannibalizzano il cap max_per_day solo 2-3 volte in 7 anni (0.6-0.9% degli ingressi veri). Meccanismo: SKH01 e' un Donchian breakout — aspettare fino a 230 min la chiusura del bin fa pagare il movimento gia' avvenuto (ingresso 0.25-0.26% peggiore in media); e siccome i livelli sono percentuali sull'ingresso (long sl4%/tp10%, short sl2%/tp8%), lo stesso 0.26% vale il 6-13% della distanza dallo SL contro il 2.6-3.3% di quella dal TP → vantaggio asimmetrico a favore della sopravvivenza del trade (win rate +8pp ETH/+2pp BTC). Due attacchi superati: (a) il divario NON e' concentrato — togliendo i 5 giorni migliori si ALLARGA (ETH@460 35.6x vs 3.0x); e' il backtest il path concentrato (~39% del log-equity in 5 giorni contro 17-22% del live); (b) nessun look-ahead intra-bin — troncando i 5m alle sole barre gia' chiuse la risposta e' identica in 289/289 osservazioni intra-bin e il prezzo d'ingresso e' sempre l'ultimo close 5m disponibile (test permanente test_nessun_lookahead_intra_bin; serviva perche' il self-check valida solo a chiusura di bin → un leak solo-intra-bin gli sarebbe invisibile per costruzione). ⚠️ La lettura che conta e' la seconda: live e backtest girano due strategie DIVERSE e la differenza non e' neutra. Ogni numero di SKH01 nel progetto (Sharpe standalone, peso 25%, audit d'ancora 02/07, conferma peso/cadenza 24/07) e' calcolato sul path a chiusura di bin, che non e' quello che gira. Sommato alla misura del 26/07 sulle uscite (+0.081 Sharpe FULL di book sottostimato), il path live di SKH01 e' stato modellato in modo sistematicamente pessimistico su ENTRAMBI i lati. Cio' che NON si conclude: che l'ingresso intra-bin sia un miglioramento validato — e' stato misurato sugli stessi 7 anni su cui SKH01 e' stato selezionato, non e' passato per study_family_honest ne' per un deflated-Sharpe, e la taglia varia molto fra ancore. Ma non serve promuoverlo: e' gia' cio' che il live fa; l'azione e' smettere di trattare il numero del backtest come l'aspettativa del live, NON "riparare" il live verso un backtest peggiore. Book, pesi, cron, config INVARIATI. ⚠️ Regole nuove (due errori catturati in sessione, entrambi del tipo che passa i test pigri): (i) un self-check su eventi rari si campiona sugli EVENTI, non sulla popolazione — la prima stesura stampava "BTC 80/80 OK" mentre la ricostruzione era rotta da un off-by-one di confine (obs//MS_LTF a chiusura cade nel bin successivo, vuoto → segnale 0): con gli ingressi al ~2% dei bin confrontava zeri con zeri, potenza zero, e le 2 sole divergenze ETH erano gli unici 2 bin con segnale vero. (ii) un conteggio di eventi su segnale GREZZO non e' un conteggio di trade — la prima scansione dava 1361 falsi ingressi e un costo inventato di 3%/anno di sleeve perche' ignorava cap+non-overlap del live (sovrastima ~20x); la spia era 305 giorni con un falso ingresso a fronte di 663 "eventi", impossibile con cap 1/giorno. (2) T2 — DVOLSPREAD ESCE DAL LIMBO (era fermo dal 21/06, unico sopravvissuto del marginal scorer indurito, mai ripreso: non nel book, non in monitor, non rifiutato). Passato ai due gate che nel giugno NON esistevano. ⚠️ La griglia dichiarata dall'agente ("72 celle") ne contiene 729 (6 assi x 3) → valutate tutte, scelta conservativa (piu' trial = DSR piu' basso). Plateau REALE e larghissimo: 729/729 celle con hold-out positivo, FULL [0.60,0.71]. Selection-on-holdout confermata ma mite: la cella pubblicata e' 83ª/729 sull'hold-out ma 471ª/729 in-sample. Scegliendo onestamente in-sample: FULL 0.68 / HOLD 0.69 (non il 0.93 pubblicato — citare 0.69) e DSR 0.953 PASS, mentre la cella pubblicata FALLISCE (0.947). Marginale ADDS + robust_oos + multicut + non-hedge + insample_edge + beats_noise; corr +0.11, alpha +7.4%/a, dSharpe book +0.08 FULL / +0.17 HOLD a w=15%. PROMOSSO a forward-monitor con i parametri ONESTI (zwin=180 k=2.0 lw=0.6 zw=1.1 tgt=0.17 svw=60), NON nel book: campione ATTIVO 1949/2691 g (prima del 2021-03 non c'e' DVOL, book flat) con hold-out attivo 1.6 anni, margine DSR sul filo, e weights_tilt_null mai affrontato. MONITOR CABLATO (stessa sessione): scripts/live/paper_dvolspread.py in cron_daily.sh dopo fetch_dvol.py, stato data/paper_dvolspread/ (gitignored), test tests/test_paper_dvolspread.py (10 casi). Inception 2026-07-25, apertura +0.184 = $111/gamba (cap $300), 2 libri MODELED $2000 / REAL $600. ⚠️ Strumentazione specifica: il book va flat quando manca il DVOL → un feed rotto produrrebbe zeri che, contati come evidenza, direbbero "nessuna perdita" invece di "nessuna misura". Contabilita' a 3 stati (ATTIVE / flat-da-segnale / flat-senza-dato) e finestra misurata in barre attive, non giorni di calendario; guardia sulla config che esce 1 se FROZEN diverge dallo stato salvato. GATE PRE-REGISTRATO: kill 2026-10-24 se Sharpe forward < 0.50; decisione 2027-01-24 solo se TUTTE — (a) Sharpe>0 [debole di proposito: con ~180 barre SE(Sharpe)≈1.4, una soglia alta sarebbe finta precisione] (b) marginale ancora ADDS+robust_oos+insample_edge (c) deflated-Sharpe ricalcolato ≥0.95 [e' qui il peso: se lo 0.953 gia' sul filo NON migliora con piu' dati, l'edge non c'e'] (d) weights_tilt_null; veto d'integrita' se barre attive <80% → si ESTENDE, non si decide su dati mancanti. (3) T3 — XSR01 NON GENERALIZZA fuori dal crypto (meccanismo CONGELATO W=45/sgn=+1 su 9 settoriali SPDR 1998+ / 28 ETF 30 anni, residuo vs SPY, demean giornaliero, split IWM/EFA riparati, annualizzazione √252). Diverso dal test del 25/07: quello era a coppie, questo e' la versione DEMEANATA (quella vera di XSR01). Lordo +0.24 (SECT9, p=0.193) e 0.14 (ALL28, p=0.747) vs null di permutazione a fee zero; netto 1.6/1.8 ovunque; per decennio stesso profilo nei 2 universi (neg. 1998-2005, debolmente pos. poi) = piu' cambio di regime che edge. Il risultato che conta non e' lo Sharpe ma l'AMPIEZZA: il demeaning porta l'ampiezza effettiva 4.5→37.4 (8x) sul crypto ma solo 5.3→6.2 / 8.4→11.3 (1.2-1.35x) sulle azioni. Spiegazione strutturale (e migliore descrizione di XSR01 di quella della sua scoperta): il residuo OLS rimuove gia' il beta al fattore comune; sul crypto alle gambe RESTA un enorme fattore comune (ampiezza 4.5 su 50 gambe) ed e' quello che il demean toglie — sulle azioni il residuo-vs-SPY e' gia' quasi indipendente, quindi non c'e' niente da togliere. Per il gate del 23/10: conferma e CHIUDE la scappatoia lasciata aperta dal test a coppie; XSR01 e' crypto-specifico. NON prova che sia falso. Soglie del gate NON toccate: resta appoggiato interamente su finestra forward + haircut di eseguibilita' a $5.000, come pre-registrato. LEZIONI: (a) se si de-lucka una strategia va de-luckato anche il suo DEGRADO — ogni Δ fra due varianti misurato su griglia ancorata eredita la fortuna dell'ancora; (b) su offset appaiati la statistica e' la mediana delle differenze, non la differenza delle mediane; (c) un lead "in forward-monitor" senza monitor e senza scadenza e' un lead perso (DVOLSPREAD: 35 giorni di limbo) → applicare ai lead la stessa disciplina dei candidati (config congelata + gate pre-registrato + cron); (d) il claim di multiple-testing di un agente va ricontato, non creduto (72 dichiarate, 729 reali); (e) quando un meccanismo non generalizza, chiedersi PERCHE' vale piu' del fatto che non generalizzi.

  • ⚠️ LEAVE-ONE-OUT DEL BOOK DE-LUCKATO (2026-07-26, 3° filone del giorno) — la classifica dei contributi si RIBALTA su 2 metriche su 3, e la stima de-luckata del book era ottimista. Domanda: "quale sleeve terrei?". Script scripts/research/r0726_loo_deluck.py, test tests/test_loo_deluck.py (9), diario 2026-07-26-loo-deluck.md. Book/pesi/cron/config INVARIATI (non è un gate sui pesi: quello resta weights_tilt_null). (1) Il metodo: un leave-one-out è un Δ, quindi eredita la fortuna d'ancora come ogni Δ (lezione 26/07). Con 4 sleeve su 5 ancorati il problema è congiunto → 2000 estrazioni uniformi indipendenti sullo spazio 24×10×7×23×5, book completo + 5 LOO alla stessa configurazione, statistica = mediana delle differenze appaiate. Sanity bit-exact 5/5 (max|dif| = 0.0) sulle repliche ancorate — quattro riusate dagli audit 02/07-03/07, solo la fase di GTAA01 è nuova. (2) Contributi de-luckati (mediana, e frazione di estrazioni positive — che conta più della mediana): TP01 +0.390 FULL (100%) = quasi 3× il secondo, e il canonico lo SOTTOSTIMAVA (+0.280 al 5.8° pctl); SKH01 +0.142 (91%), XS01 +0.125 (99.9%), VRP01 +0.122 (100%), GTAA01 +0.115 (100%). (3) Due giudizi ribaltati rispetto alla lente canonica. SKH01 non è il motore del book: l'ancora regala 2/3 del FULL (+0.43→+0.14), 70% dell'hold-out (+0.65→+0.19), 80% della protezione DD (+1.64pp→+0.32pp) → de-luckato è il meno affidabile dei cinque. GTAA01 è l'unico positivo nel 100% delle estrazioni su TUTTE E TRE le metriche e il miglior protettore di DD (+2.0pp, doppio del secondo), senza fortuna da restituire (canonico sotto la mediana su FULL e DD). ⚠️ Ma attribuzione ≠ eseguibilità: sotto GTAA_MIN_CAPITAL $3k resta non deployabile, e la nota del 25/07 (€0.50/g sopra il risk-free con maxDD 10% a $10k) è intatta. (4) TP01: hold-out negativo 0.200, e NON è artefatto d'ancora (negativo nel 99.1% delle configurazioni) — mentre sul FULL è il maggior contributore. È la firma dell'assicurazione, misurata: paga premio negli anni senza incendio, riprende tutto sul campione che contiene il 2022. Regola: uno sleeve difensivo si giudica sul sinistro, non sul premio — l'hold-out negativo non è un argomento per ridurlo. XS01: protezione DD ESATTAMENTE ZERO (mediana 0.000, positiva nel 43% = moneta) → è un diversificatore di rendimento, non di rischio; conta perché sul canale funded il vincolo binding è il DD (25/07 §4). VRP01: 2ª conferma di zero fortuna (canonico al 1.8° pctl sul FULL = numeri di ammissione conservativi). (5) Contrappeso dovuto a SKH01: il de-luck lo penalizza sul path backtest, ma il path live è misurato migliore su entrambi i lati (ingressi +0.38, uscite +0.081) → vale meno dei suoi numeri di ammissione e più di questa tabella; quantificarlo resta il follow-up bloccato (serve la versione vol-targeted del path live). ⚠️ Errore di stampa catturato: il primo output dava pctl 100% per l'hold-out del book — arrotondamento di 99.55% con %.0f. Un percentile stampato a 0 decimali mente esattamente agli estremi, che sono l'unico posto dove lo si legge. Verificato a mano (9 estrazioni su 2000 battono la canonica), formato portato a 1 decimale.

  • FOLLOW-UP SKH01 "vol-targeted" CHIUSO (2026-07-26, 4° filone) — il blocco non esisteva, e il fattore de-luck ×0.6 era troppo severo del 31-34%. Script r0726_skh_sigcache.py (cache), r0726_skh_live_book.py (misura), r0726_deluck_factor.py (decomposizione), r0726_capwall_refresh.py (muri); test tests/test_skh_live_book.py (8); diario 2026-07-26-skh-live-book-deluck.md. Book/pesi/cron/config INVARIATI. (1) La premessa era falsa — vedi il bullet dell'ondata 26/07-bis: SKH01 non e' vol-targeted, le due lenti erano gia' identiche (sim_equity(canonical) == backtest_signals a max|diff| = 0.0). Test permanente test_lente_sleeve_uguale_a_quella_del_simulatore: se qualcuno aggiunge un vol-target allo sleeve, la premessa torna vera e il test deve rompersi invece di far passare numeri non piu' validi. (2) Ingressi live vs backtest, de-luckato a 8 offset (sottocampione uniforme a priori: la griglia piena a 23 costa ~9 min per asset×offset, fuori portata su 2 core col cron live). Sanity 120/120 bin con ingresso ricostruiti. Il numero del 26/07 era ~4× troppo grande: like-with-like (mediana PER-ASSET) +0.38 su 3 offset → +0.097 su 8, e "6/6 non negativi" → 13/16. A livello di sleeve 50/50 la mediana appaiata e' +0.112, positiva 8/8. ⚠️ Le due grandezze (per-asset e sleeve 50/50) non sono la stessa cosa — nel book entra la seconda, dove la diversificazione BTC/ETH cambia il denominatore. (3) A livello di BOOK: Sharpe ≈ monetina, drift certo. dSh FULL +0.048 (>0 nel 79.3%), dSh HOLD +0.051 (51.2%), d drift +0.73pp (>0 nel 100.0%). Meccanismo: l'ingresso intra-bin prende un prezzo migliore ma i falsi ingressi aggiungono churn (530-605 trade live vs 411-484) → vol e ritorno salgono insieme. REGOLA: chiedersi QUALE grandezza entra nella decisione prima di misurare — qui il ×0.6 e' sul drift, quindi lo Sharpe non era la metrica. (4) Il ×0.6 decomposto e misurato. (a) fortuna d'ancora sul drift: ×0.874 (5-sleeve) / ×0.890 (book live) — e la vol e' invariata fra le ancore (7.80→7.76%), la fortuna sta tutta nel drift; (b) path live: non-negativo ovunque (uscite +0.081 Sh, ingressi +0.73pp, TP01 trascurabile). Il ×0.6 implicava un residuo ×0.687 attribuito al live oltre l'ancora, che nessuna misura sostiene → FATTORE ONESTO ×0.87-0.91 (5-sleeve), ≥×0.89 (book live). Il sospetto registrato il 25/07 ("conta due volte la degradazione SKH01") e' confermato quantitativamente. REGOLA: un fattore correttivo scelto a occhio va DECOMPOSTO prima di accettarlo o rifiutarlo — il ×0.6 non era sbagliato, era due fattori moltiplicati insieme di cui uno contato due volte. (5) Ipotesi MIA nata e refutata nella stessa sessione: che la grid timing-luck di SKH01 (audit 02/07) fosse un artefatto della lente a chiusura-di-bin, perche' il live valuta ogni ora e non e' ancorato al confine del bin. Dispersione fra gli 8 offset: LIVE/CANONICO = 1.59×, cioe' il live e' piu' disperso, non meno → l'audit del 02/07 resta valido com'e'. L'ipotesi nasceva da 2 offset, si e' incrinata a 4 (1.24×), chiusa a 8. REGOLA: due punti non fanno una tendenza nemmeno quando la meccanica sembra spiegarla. (6) ⚠️ Trovato per strada: simulate() in r0726_skh_partial_entry.py non e' mai chiamata da main() — i numeri headline del diario del 26/07 vennero da una corsa ad hoc mai committata. Ora il driver e' committato (r0726_skh_live_book.py). Un numero pubblicato in un diario deve avere uno script committato che lo riproduce.

  • ⚠️ RISCHIO DI VENUE — mai prezzato in 2 mesi, e non e' diversificabile dagli sleeve (2026-07-26). Script r0726_venue_risk.py, test tests/test_venue_risk.py (13), diario 2026-07-26-venue-risk.md. Book/pesi/cron INVARIATI. (0) Il buco: il progetto ha prezzato fee, slippage, min-order, pavimento IB, haircut small-cap, fortuna d'ancora, degrado d'esecuzione, look-ahead, backfill, split — mai la probabilita' che l'exchange sparisca col saldo dentro. E TP01+SKH01+VRP01 stanno tutti sullo stesso conto Deribit: tre sleeve quasi-ortogonali sui ritorni, perfettamente correlati sul fallimento del venue — cosa che la matrice di correlazione del book non vede per costruzione. (0-bis) ⚠️ Limite dei muri del 25-26/07: book_series gira a alloc=$600 col book a 2 sleeve → portarlo fino a $272k assume (a) che a $272k si giri ancora il book da $600 e (b) "tutto su Deribit" per 10-20 anni, senza dirlo. (a) MISURATO e REFUTATO il 26/07 — vedi bullet "MURO COME PUNTO FISSO": il muro non scende, $273.900 vs $272.061 (+1%). (1) La misura (accumulo da $600, €250/m, 20a, bersaglio $272k, ×0.89, jump di venue a probabilita' annua p; CONC = 100% Deribit vs SPLIT = Deribit 65 / HL 15 / IB 20; bersaglio identico → conservativo CONTRO lo split):

    p annua P(arrivare) CONC SPLIT P(perso TUTTO) CONC SPLIT
    0.5% 87% 90% 10% 0%
    1.0% 81% 83% 18% 0%
    2.0% 69% 71% 34% 4%
    5.0% 42% 45% 64% 27%
    Capitale mediano CONC a 20a: $544k (p=0) → $0 (p=5%).
    (2) La colonna che conta non e' la prima. Sulla probabilita' di ARRIVARE la concentrazione
    costa 1-3pp; sulla ROVINA costa fino a 64pp. Motivo strutturale: **con un conto solo "almeno
    un fallimento" COINCIDE con "perso tutto"**. ⚠️ Lo SPLIT viene colpito 2.5× piu' spesso (26%
    vs 10%) ed e' molto piu' sicuro → "quante volte vieni colpito" NON e' una misura di rischio.
    (3) Onesta' obbligatorie: p non e' stimato (sensibilita', non previsione — la sceglie
    l'operatore e va dichiarata); i fallimenti sono assunti indipendenti, ottimistico per
    Deribit-HL (crisi sistemica) → la parte solida dello split e' IB, altra classe di rischio;
    a $600 lo split e' impossibile, la concentrazione e' forzata.
    (4) RISPOSTA: no, ma la domanda ha una DATA. Oggi concentrazione forzata; **~$3k = prima
    riduzione vera** (GTAA01 su IB, 20-25% fuori dal rischio-exchange); ~$20k (XS01/HL) aggiunge
    poco perche' e' ancora crypto. Convergenza che rafforza il 25/07: r0725_ib10k disse
    "max 25% su IB, costa ~€0.08/g" su basi di solo RENDIMENTO; sull'asse della ROVINA quello
    stesso 25% e' la mossa principale → **€0.08/g non e' il prezzo di un peggioramento, e' il premio
    di un'assicurazione contro il modo piu' probabile di perdere tutto.**
    ⚖️ (5) DECISIONE DELL'OPERATORE 2026-07-26: TUTTO SU DERIBIT FINO A $20k. Presa DOPO aver
    visto la tabella della rovina, e con la controparte esplicitata. Cosa e' stato accettato:
    P(perso TUTTO) resta 10/18/34/64% a p=0.5/1/2/5% invece di 0/0/4/27%; in cambio si evita il
    costo (~€0.08/g di rendita, commissione fissa IB, un secondo venue da gestire) di proteggere
    $750 alla soglia dei $3k. L'argomento a favore, che regge: sull'asse su cui l'operatore
    ottimizza — P(ARRIVARE al capitale-rendita) — lo split vale solo +1-3pp (81%→83% a p=1%),
    ed e' un fatto misurato, non una concessione. L'argomento contro, che resta vero: zero e'
    assorbente (andare a zero all'anno 10 di un piano da 16 anni significa non arrivarci piu',
    perche' si riparte da €0 + versamenti), quindi il valore del non-andare-a-zero NON e'
    proporzionale alla frazione salvata. Cosa NON si ri-discute: la soglia $3k. **Cosa si
    ri-apre a $20k:** lo split, che a quella taglia protegge ~$5k e ha senso anche solo per
    eseguibilita' (XS01/HL, GTAA01/IB). ⚠️ Nota per il futuro-me: questa e' una decisione presa
    con l'informazione completa, non una svista da correggere — se a $3k qualcuno propone lo split
    "come da CLAUDE.md", la risposta e' che la data e' $20k. Se cambia il piano (orizzonte, importo
    dei versamenti) o p diventa stimabile invece che assunto, si riapre PRIMA.
    REGOLE: (a) un rischio non-diversificabile dagli sleeve va prezzato a parte; (b) P(successo)
    puo' nascondere P(rovina) — per una rendita la metrica e' la seconda; (c) una raccomandazione
    presa su un asse solo va ricontrollata sugli altri prima di considerarla stabile; (d) quando una
    raccomandazione viene respinta con motivo, si registra cosa e' stato accettato in cambio
    altrimenti la stessa analisi la ripropone fra tre mesi come se fosse nuova.
  • VENUE WATCH — tripwire di fallimento exchange, CABLATO LIVE (2026-07-26). Risposta alla domanda "trova un sistema di protezione da fallimento exchange" sotto il vincolo della decisione appena presa (100% Deribit fino a $20k): se non si puo' ridurre l'ESPOSIZIONE, l'unica leva e' il TEMPO. Script r0726_venue_tripwire.py (segnale) + r0726_venue_response.py (costo della risposta); produzione src/live/venue_watch.py + scripts/live/venue_watch.py in cron_book.sh; test tests/test_venue_watch.py (37); diari 2026-07-26-venue-tripwire.md, 2026-08-19-venue-watch-disciplina-allarmi.md, 2026-08-21-venue-taratura-tre-referenze.md. Book, pesi, config INVARIATI. (1) Il segnale: un venue che gata i prelievi rompe l'arbitraggio → il suo prezzo si stacca dal consenso e ci RESTA. Il segnale e' |scarto|, non il segno (Mt.Gox andava a premio, un venue in fuga a sconto: dicono la stessa cosa). Consenso = mediana di venue USD indipendenti (Coinbase, Bitstamp, e Kraken dal 19/08 — vedi sotto); mai USDT (depeg 2022 → falsi allarmi giganti). Deribit sta a 3 bps dal consenso in mediana su 8 anni — fondo di rumore bassissimo, ed e' cio' che rende possibile una soglia con margine. ⚠️ Le "65.043 ore BTC" citate qui fino al 21/08 erano le ore del consenso con bitfinex dentro, che la produzione non ha mai avuto: sull'insieme reale sono 69.633 (ETH 64.541 invariato). (2) Taratura CONGELATA = 100 bps persistenti 4h a segno costante. Criterio dichiarato prima, perche' i due ovvi sbagliano in versi opposti (provati entrambi): minimi bps → 25bps/24h consuma 24 delle ~72h che diede FTX; minime ore → 500bps/2h manca FTX (margine 0.6x). Regola adottata: (a) zero falsi allarmi su entrambi gli asset in 8 anni; (b) margine ≥3x sul caso storico piu' debole (FTX ~300bps) → soglia ≤100bps; (c) a quei vincoli, minima latenza. Margine finale 3x FTX / 5x QuadrigaCX / 10-20x Mt.Gox. ⚠️ CORREZIONE 2026-08-21 — la gamba (a) NON e' soddisfatta dalla configurazione che gira, e la frase "zero falsi allarmi inclusi crash COVID 2020-03" era FALSA: il falso allarme E' il COVID. Vedi il blocco (8) in fondo. Il punto (100 bps, 4h) resta, per economia e per la gamba (b). (3) CONTROLLO POSITIVO superato (obbligatorio: un rilevatore tarato per non segnalare e' indistinguibile da uno rotto). Puntato su Bitfinex 2018-19 (problemi bancari/Tether): 22 episodi, il piu' lungo 2.324 ore consecutive a +447bps di picco, altri a 1.151h/+663bps e 496h/+1136bps. 22 scatti dove il problema c'era, 1 solo su Deribit in 8 anni (era dichiarato 0 — vedi (8)). E la DURATA risponde alla domanda vera: un venue gated resta dislocato per settimane → 4h di latenza costano una frazione trascurabile del preavviso. (4) Economia della risposta: costo ATTESO di un falso allarme (flat 3 giorni, misurato sul book reale a ogni data d'inizio) = 0.248% di equity (coda p5 2.065%); guadagno di un vero positivo = 100%. Break-even: p_annua > (falsi allarmi/anno) × 0.00248 → a 1 ogni 8 anni serve p > 0.031%, a 12/anno servirebbe p > 2.97%. Il valore sta nella SPECIFICITA', non nella sensibilita'. ⚠️ Errore mio corretto: il break-even si calcola sulla media, non sul p5 (con la coda esce 8.3x piu' severo e la conclusione si ribalta). (5) Tre stati, e il terzo NON e' il primo: OK / ALERT / BLIND (referenze irraggiungibili o in disaccordo fra loro → dopo 12h e' un allarme suo). "Non vedo" non e' "va tutto bene" — stessa lezione della contabilita' a 3 stati di paper_dvolspread. ALLERTA, NON BLOCCA: l'azione a un vero positivo e' prelevare (manuale — una chiave API con permesso di prelievo sarebbe essa stessa un rischio), e bloccare non protegge il saldo, che e' a rischio anche stando flat. Runbook pre-deciso nel docstring del modulo (escludere guasto referenze → public/statusprelievo di prova, unica evidenza diretta → flat + prelievo totale). (6) ⚠️ Cio' che NON copre, e non e' un argomento per riaprire il 26/07: un fallimento senza finestra (furto di chiavi, sequestro, exit-scam notturno) non lo prende nessun tripwire; quella parte di p resta scoperta e la sola difesa e' lo split. E il preavviso di 200-2.300 ore viene da un caso osservato: e' un'ancora, non una distribuzione. REGOLE: (a) un rilevatore tarato per non segnalare va validato su un controllo positivo; (b) una soglia si sceglie con un criterio dichiarato prima (i criteri ovvi sbagliano in versi opposti); (c) la persistenza richiesta e' latenza e va confrontata con la durata del fenomeno da rilevare; (d) un break-even si calcola sulla media, non sulla coda; (e) ⚠️ una diagnostica STAMPATA non e' un controllo — la prima corsa tronco' il campione da 8 anni a 29 giorni per un inner-join con Kraken (che serve solo ~700 candele) e la copertura era gia' a video: ora c'e' una guardia che ferma lo script (2ª occorrenza in un giorno dopo GTAA01 — l'outer-join con referenze di lunghezza diversa e' una trappola ricorrente); (f) un controllo positivo finito dentro il ramo else non gira mai (trovato in sessione: era esattamente il difetto che doveva prevenire). (7) DISCIPLINA DEGLI ALLARMI + TERZA REFERENZA + SPECIFICHE CONTRATTO (2026-08-19)(bullet scritto il 21/08: la sessione era in un diario e in un commit e NON in memoria operativa, 2ª occorrenza dopo edge_watch). Nato da 4 🚨 identici il 18/08 per una manutenzione Deribit annunciata (14/08 per il 18/08 09:00 UTC, downtime dichiarato 15-30 min) che ha sforato fino alle 14:07 UTC. Il book si era comportato bene (astensione alle 09:07 e 10:07, "conto non leggibile → non eseguo a cieco"): il difetto era negli allarmi. (a) Il blocco piattaforma era un if secco senza memoria, accanto a un rilevatore che allerta una volta per streak → ora passa da lock_step() pura: manutenzione entro MAINT_GRACE_HOURS=2 → ⚠️ una volta; che sfora → 🚨 una volta («ha SFORATO»); blocco senza manutenzione dichiarata → 🚨 subito; rientro annunciato una volta; public/status illeggibile → NIENTE (dichiarare «e' rientrato» perche' non si e' riusciti a guardare sarebbe la bugia peggiore). Un allarme massimo speso per un evento atteso e' un allarme che non verra' letto il giorno che e' vero. (b) Il messaggio stampava locked=true cablato mentre il parser accetta anche partial → dichiarava un valore che non aveva letto, e il runbook manda a controllare proprio quel campo; ora stampa e salva il grezzo. (c) ⚠️ Il difetto che poteva costare: il 18/08 Deribit ha cambiato tick e size dei perpetual lineari USDC (BTC tick 0.5→0.1, ETH 0.05→0.01, ETH min/step 0.001→0.0001) e la tabella _CONTRACT di deribit.py, cablata a mano, non se n'e' accorta. Nessun ordine rifiutato e non per merito nostro: erano riduzioni, e un valore piu' grosso resta conforme (costo effettivo: granularita', incremento minimo ETH $1.92 invece di $0.19). Il giorno che Deribit ALZA un minimo la stessa cecita' fa rifiutare gli ordini. Cablato check_specs() nel venue_watch orario, fuori dal percorso ordini: la tabella dichiarata resta l'AUTORITA' per costruire un ordine, il venue e' il controllore (prendere i valori dall'API dentro l'esecuzione renderebbe l'ordine dipendente da come ha risposto una GET = non ricostruibile). Verdetti: granularita' (dichiarato piu' grosso → conforme, ⚠️) vs rifiuto (dichiarato piu' fine → 🚨). Uno strumento non letto finisce in non_letti, non conta come «combacia». (d) Aggiunta Kraken come terza referenza: Coinbase ha comprato Deribit e una referenza che e' la casa madre non misura piu' se Deribit scolla dal mondo. ⚠️ (8) LA TARATURA RI-MISURATA (2026-08-21) — «zero falsi allarmi in 8 anni» non ha mai descritto la produzione, e il falso allarme e' il COVID. Script r0821_venue_refs.py, diario 2026-08-21-venue-taratura-tre-referenze.md. Soglie, book, config INVARIATI. (i) Il numero pubblicato veniva dal consenso Coinbase+Bitstamp+Bitfinex dello script di ricerca; il sorvegliante live girava su Coinbase+Bitstamp. Due liste di referenze in due posti diversi, e nessun test poteva accorgersene. Sull'insieme reale: 1 falso allarme in 8 anni, il 2020-03-13 07:00-10:00 UTC, 4 ore a 418 bps di picco su BTC — cioe' proprio l'evento che questo bullet elencava come esempio di cio' su cui NON scattava. La soglia minima a zero falsi allarmi a 4h e' 150 bps (BTC), non 100. (ii) Kraken non lo ripara: su 8 anni porta un mese (tetto ~700 candele dell'endpoint pubblico, ri-verificato oggi: 704 barre su 70.286 richieste = 1,00%) → LIVE-post ≡ LIVE-pre sulla storia lunga, numeri identici. (iii) Perche' spariva a 3 referenze, ed e' il punto trasferibile: con bitfinex dentro 1 delle 4 ore diventa BLIND → lo streak si azzera e l'episodio non esiste, ma la dislocazione e' ancora li' (mediana 343 bps). Lo zero non veniva da un consenso piu' accurato, veniva da un'ora buttata (ore utilizzabili 93,4% contro 100,0%). (iv) La direzione dichiarata il 19/08 e' confermata, la sua TAGLIA dipende dal venue (confronto appaiato, stesse ore): con bitfinex le ore non-BLIND passano 99,95% → 86,04% = 13,91 pp; con kraken +0,00 pp (|scarto| mediano appaiato 0,04 bps). Non e' una proprieta' del numero tre: e' quanto la terza referenza e' d'accordo con le altre. (v) Controllo positivo intatto: Bitfinex 2018-19 → 22 episodi, il piu' lungo 2.324h, picco 1.136 bps = 11,4x la soglia. (vi) DECISIONE: (100 bps, 4h) NON si tocca, ma la giustificazione cambia. 1 falso allarme in 8 anni = 0,125/anno × 0,248% = 0,031%/anno di equity attesa contro il 100% che un vero positivo evita, e ogni p plausibile (0,5-5%) e' 16-160x sopra il break-even; alzare a 150 bps porterebbe il margine su FTX da 3,0x a 2,0x, sotto la gamba (b) dichiarata prima di guardare i dati. Il numero da citare e' «1 in 8 anni» — che e' esattamente l'esempio gia' usato al punto (4): la memoria si contraddiceva da sola e la meta' giusta era quella dell'economia. REGOLE NUOVE: (g) un numero di taratura si etichetta con la CONFIGURAZIONE, non solo con la finestra — «zero falsi allarmi in 8 anni» era vero e inutile perche' descriveva un consenso che la produzione non ha mai avuto; (h) uno "zero" si legge accanto alla quota di campione utilizzabile: meno falsi allarmi perche' si vede meglio e meno perche' si vede di meno hanno lo stesso valore stampato e valore opposto; (i) quando due affermazioni della stessa memoria si contraddicono, la contraddizione e' informazione — una delle due e' stata scritta guardando i dati; (j) una nota che dichiara un debito puo' sottodimensionarlo: il 19/08 diceva «il numero non e' ri-misurato», e il numero era sbagliato prima della modifica che lo aveva fatto dichiarare. RESTA APERTO: il Rulebook Deribit del 12/08 (ADL, perdita socializzata, emergency powers, conti dormienti) non lo sorveglia nessuno; MAINT_GRACE_HOURS=2 presume gli annunci invece di leggerli (due locked=true in 4 giorni: 18/08 ~4h, 21/08 ~1h); la terza referenza non e' validabile sulla storia.

  • 🌊 QUARTA ONDATA 2026-08-23 (5 filoni, research/wave-0822) — 0 candidati, 1 lead RIDEFINITO, 1 premessa MIA falsificata, e la scorta di DATI dichiarata esaurita. Registro docs/research/RESULTS-0822.md §41-45. Libro, pesi, cron, config INVARIATI. 🚨 (1) §41 TP01-SIZE — in questa famiglia la selezione in-sample e' ANTI-correlata col futuro. Esiste una size che risponde alla CONVINZIONE, a pari vol realizzata? 60 celle dichiarate prima, 24 ancore. Spearman(ShIS, ShHOLD) = 0,527 (p<0,001): scegliere in-sample e' peggio di una moneta, ed e' meccanismo, non rumore — Spearman(rho, ShHOLD) = +1,000 a tutti e sei i q (in hold-out l'ottimo e' al bordo) mentre in-sample la curva e' a gobba con ottimo interno. La convinzione e' informativa in-sample e ANTI-informativa in hold-out (BTC hold-out: convinzione debole Sh +2,20 contro piena 0,06) → l'unica cella con guadagno hold-out robusto e' esattamente quella selezionabile solo guardando l'hold-out. Non esiste una cella proponibile. Il meglio della griglia vale +0,30pp di CAGR iso-vol e il maxDD di libro peggiora a 24 ancore su 24 — cioe' proprio cio' per cui TP01 esiste. 🚨 CORREZIONE A UNA MIA PREMESSA, verificata al sorgente: il bucket di convinzione 2/3 NON ESISTE. tsmom_blend media tre np.sign(...) → direzione in {1,1/3,+1/3,+1}, dopo il clip long-flat in {0, 1/3, 1} (BTC 44,2/24,7/31,1%). Trovato da due agenti indipendenti. Conseguenza: potenza c^p, floor affine e soglia sono la stessa cella riparametrizzata — la famiglia della convinzione ha UN grado di liberta', non tre. 📌 Null del RE-LEVERING, forma piu' pura mai misurata (6ª occorrenza, prima col segno rovesciato): togliere il vol-targeting fa CAGR 16,32% → 46,75% (+186%) e a iso-vol 2,40pp. Era tutta leva. ⚠️ Fatto sull'harness: altlib.tp01_baseline_daily() NON e' bit-exact col sleeve — 1 ulp su 68,5% dei giorni, perche' _to_daily fa (1+r).resample("1D").prod()-1, no-op algebrico ma non in virgola mobile. "Bit-exact vs altlib" non e' un controllo ottenibile. (2) §42 TP01-LS — la short del trend a 1d SCARTATA, e piu' nettamente dell'attesa. Meccanismo congelato, un solo grado di liberta' (floor da 0 a 1); replica bit-exact a 4 vie (floor=1 == CANONICAL(long_only=False), max|diff| = 0.0). Esito: 1,91%/anno di drift in 0/24 ancore, gate iso-vol FAIL 3/3 (non e' leva travestita: alza la vol e abbassa il ritorno), maxDD +8,80pp in 24/24, NEUTRAL con alpha 2,60%/anno, e a fee ZERO 1,338 contro 0,904 → non e' morte-per-fee, l'edge lordo non c'e'. L'attesa a priori ("sara' il 2022") e' confermata e superata: 2/8 anni positivi, e SENZA il 2022 il divario RADDOPPIA (dShFULL 0,406, iso-vol 7,44%) — il 2022 non e' l'anno che regge la tesi, e' l'unico che la tiene a galla a meta'. Non selezionabile: select_cell_insample sceglie il canonico. ⚠️ L'unica cosa a favore (dShHOLD +0,292 in 23/24) all'ancora canonica vale 0,008 = caso speculare della lezione del 26/07 (li' l'ancora canonica inventava un danno, qui ne nasconde un vantaggio). 📌 Trovato per strada: src/live/book.py contiene max(tp_frac, 0.0) — il long-flat e' cablato anche nell'ESECUTORE, non solo in CANONICAL. 🚨 (3) §43 DATA-UNUSED — LA SCORTA DI DATI DEL PROGETTO E' ESAURITA. Inventario su 647 file .py (Old/ escluso): ogni dataset con storia vera e' gia' stato analizzato almeno una volta; cio' che resta non letto e' telemetria a finestra corta (30-113 giorni), con una sola eccezione — external/coinmetrics/ (26 colonne su 31 mai lette, storia dal 2018). Misurato prima di usarlo che il dato fosse nuovo: il flusso netto e' corr +0,9993 con la derivata dello stock gia' ucciso il 24/07, il lordo e' ortogonale (+0,035) perche' il 94% del flusso si cancella. E perde: massimo atteso dal PURO RUMORE su 36 trial = Sharpe 1,009, il candidato fa 0,951 — sotto; DSR 0,437; multi-cut negativo 7/7 anni. 📌 METODO RIUSABILE: mettere nella griglia una variabile che si SA gia' morta trasforma "il candidato perde" in "il dato non contiene nient'altro di selezionabile" — qui la selezione in-sample e' tornata sul controllo negativo. E' l'unica forma in cui un inventario puo' concludere qualcosa di positivo su un'assenza. ⚠️ Conferma diretta del §10 catturata dall'agente su se stesso: il pool "N=12" del deflated-Sharpe erano le 12 celle MIGLIORI e faceva PASSARE il candidato a 0,975 invece di 0,678. (4) §44 DEPOSIT-TIMING — il timing dei bonifici non paga, 0/12 celle in OGNI lente (€500/m, €250/m, IID, drift dimezzato). Replica 4/4 prima di ogni delta, fra cui P0 vs PN.accumula a max|dif| = 0.0 su capitale e giorno d'arrivo. 📌 Il segnale FA quello che promette e perde lo stesso: dip 20% compra al 0,494 del livello medio del piatto (51% piu' in basso) e arriva al capitale-rendita nel 6,3% dei casi contro l'85,4% del piatto — comprare meglio e comprare tardi sono la stessa mossa. E sotto soglia bassa si ribalta: dip 5% compra a 1,009, cioe' piu' in alto (su una serie che sale, una condizione poco profonda non compra il calo, ritarda dentro la salita). 📌 L'asimmetria e' la misura: un rialzo del 20% dal minimo arriva in 16 giorni, un ribasso del 20% dal massimo in 3.682. Il costo non e' scommettere sul lato sbagliato, e' mettere una condizione rara davanti a un bonifico — in qualunque direzione. Rischio di venue separato dal timing: tenere i soldi fuori vale +2,4pp a p=1% contro 15,7pp di penalita' di timing, e P(libro azzerato) e' IDENTICA per tutte le politiche (21,6%) — il conto salta comunque, cambia quanto c'e' sopra; la protezione si compra con un secondo conto. ⚠️ Due errori dell'agente catturati da un controllo: un diagnostico che diceva "il buy-the-dip contiene previsione" (+11,5%) e che sotto IID vale +14,9%, cioe' piu' grande → meccanico; e lo specchio anti-dip, che si legge sulla colonna dell'ATTESA, non su quella del segno (P4 e' piatto perche' la sua condizione e' quasi sempre gia' vera). Ordine di grandezza: la migliore politica di timing vale 0,1pp, dentro il rumore MC di 2,0pp; €250 → €500 al mese vale +71pp (14% → 85%). ⚠️ (5) §45 SPOT-NETTING — il lead dello spot REGGE, ma non per la ragione per cui il filone e' stato aperto. Il margine non e' il vincolo: BTC/ETH sono in_cross_collateral_pool (11 valute su 51), lo spot ha max_leverage: 10 (⇒ vive nel conto marginato) e nel caso peggiore la copertura e' 50,0x, invariante al capitale — anche valutando lo spot zero come collaterale. L'haircut non e' leggibile e non e' binding: unico caso in cui "non lo so" e "non conta" coincidono, e va detto in quest'ordine. 🚨 A bloccarlo e' IL CODICE, non Deribit: src/live/shadow.py::_equity legge solo account_summary("USDC") → con $477 in spot il libro leggerebbe $159 invece di $636 (25%) e il riconciliatore ricomprerebbe la gamba. Non e' un cambio di strumento, e' un cambio del percorso di SIZING del live. 🚨 La separazione delle gambe non vale nulla, su tutti e tre gli assi: (i) T1 sbloccato e' un DECLASSAMENTOonbook_tp hourly riproduce il pubblicato (+0,051/+0,057) ma contro il path che il live gia' percorre fa 0,048 FULL (6/23) (conferma indipendente della decisione del 26/07, per un'altra strada); (ii) il netting perso RISPARMIA commissioni ($4,34 → $2,97/anno, 0,216%) — la stima "1-2%" di §39 era alta di un ordine di grandezza — e le ore a segni opposti sono lo 0,61% della storia; (iii) meno ordini non e' meglio: il tracking peggiora del +12% (5ª occorrenza della lezione "banda in valuta assoluta"). Il valore e' il FUNDING e basta: lordo +1,58%/anno → netto [+1,55%, +1,66%], [+1,33%, +1,44%] se lo spot passasse a 3,50 bps, +0,50% nello scenario fiscale sfavorevole. Il costo vero d'esecuzione e' lo spread (perp a un tick, spot 1,5-3,1 bps) → [0,034%, +0,077%]/anno, ampiezza 7% del lead: l'esecuzione non decide questo lead. Ipotesi dell'agente nata e refutata nel filone: l'apr 3,40 di USDC in get_currencies costerebbe fino a 2,55%/anno — ma su 6 run col conto flat (il piu' lungo 257 giri orari) l'equity e' invariata al centesimo< 0,029%/anno. L'obiezione e' morta e il lead non deve pagarla. 🚨 Due costi NUOVI mai contati, che la separazione introduce: (a) se i derivati sono c-quater i comparti fiscali si SEPARANO → le minusvalenze del perp (SKH01) smetterebbero di compensare le plusvalenze spot (TP01); (b) il disaster-SL oggi protegge la posizione netta: separando resterebbe solo sul perp, e in un blackout TP01 resterebbe long al 75% del conto senza stop. (Di contro, lo spot non si liquida: esce dal perimetro il 75% del libro.) ⚠️ E fee_watch non vedrebbe una gamba spot (deriva INSTRUMENTS da BOOK_INSTRUMENT, il difetto corretto il 21/08); convenzione('BTC_USDC') ritorna 'ignota' → servirebbe una terza famiglia 'spot'. La ragione per sorvegliarlo non e' che la fee lo ucciderebbe (perde il 14% del guadagno e sopravvive), e' che oggi nessuno se ne accorgerebbe. 📌 IL PROSSIMO PASSO NON E' UN BACKTEST: e' la domanda al commercialista (gia' aperta dal 07/08) e un acquisto di prova da $7,73 — le tre cose non determinabili senza conto reale (haircut, se equity USDC includa i saldi BTC/ETH, se get_positions ritorni lo spot) si risolvono cosi'. E' un ordine ⇒ decisione dell'operatore. 📌 (6) LA RIGA DI SINTESI. Quattro filoni su cinque SCARTATI, il quinto ridimensionato a "vale il funding e basta". Ma la misura piu' grande dell'ondata resta quella di §44: la migliore politica di timing vale 0,1pp mentre passare da €250 a €500 al mese vale +71pp. Con questa sono 45 filoni in due giorni e 0 candidati promossi: la ricerca ha smesso di essere il vincolo binding il 26/07, e sette ondate lo hanno CONFERMATO invece che ribaltarlo.

  • 🚨 IL TRASPORTO DEGLI ALLARMI E' UN PUNTO SINGOLO DI GUASTO — misurato 2026-08-23, NON riparato (produzione, decisione dell'operatore). Registro docs/research/RESULTS-0822.md (sezione NOTIFIER). Il progetto ha tarato il rilevatore (venue_watch: 1 falso allarme in 8 anni, controllo positivo su 22 episodi Bitfinex, margine 3x su FTX) e mai il trasporto. src/live/notifier.send() fa UN tentativo urlopen(..., timeout=10), except Exception: return False, nessun retry; notify() ritorna bool e scripts/live/venue_watch.py:80 non lo guarda; logs/cron_book.log ha 0 occorrenze di un qualsiasi esito d'invio → quando serve sapere se l'allarme e' arrivato, l'informazione non e' stata scritta (la regola del 29/07 — "se un errore si ingoia per non bloccare, si registra nel punto in cui lo si ingoia" — non e' mai stata applicata al notifier). 🚨 E lo stato e' marcato PRIMA dell'invio: in venue_watch la riga new.alerted = True sta dentro la logica pura e viene persistita comunque; alle ore successive already = st.alerted and st.sign == sign fa tornare "WATCH" invece di "ALERT"notify non viene piu' chiamata per quell'episodio. Un 🚨 perso e' perso per l'episodio intero, e gli episodi storici durano 200-2.324 ore a segno costante: e' esattamente il caso in cui la ri-notifica non arriva mai. Taglia misurata: 6,9% di invii falliti (2/29, IC95 Wilson [1,9%, 22,0%]) sul digest giornaliero. ⚠️ Fonte dichiarata: e' il percorso del digest usato come proxy di quello d'allarme, che non ha dati propri — ed e' questo il punto; stessa funzione, stesso endpoint, stesso timeout. ⚠️ La nota stampata ("config Telegram assente o rete KO") conflazione due cause e la prima e' falsa: le chiavi sono presenti in .env (verificato) → manda a controllare il posto sbagliato, stessa forma del difetto codificato il 29/07, su un percorso diverso. Perche' conta piu' del suo numero: l'economia del 26/07 (falso allarme 0,248% di equity contro il 100% che un vero positivo evita, break-even p > 0,031%) assume che l'allarme arrivi, e questa e' l'unica mitigazione rimasta dopo la decisione 100% Deribit fino a $20k contro un rischio prezzato a P(perso tutto) 10/18/34/64%. Riparazione in tre pezzi indipendenti, NON eseguita: (a) retry con backoff in send(); (b) registrare l'esito nel punto in cui l'eccezione viene ingoiata; (c) marcare alerted=True solo a invio riuscito. ⚠️ (c) cambia il comportamento — rende l'allarme ripetitivo finche' non passa: verso giusto per un 🚨, sbagliato per un ⚠️decisione dell'operatore, non un fix ovvio. REGOLA: un rilevatore si valida sul segnale E sul TRASPORTO — tarare la soglia e non misurare mai se il messaggio arriva lascia un punto singolo di guasto a valle di tutto il lavoro di taratura, e non produce numeri, quindi non si fa notare.

  • ⚖️ RIVALUTAZIONE DELLA STRATEGIA (2026-07-26, fine giornata) — 0 cambi, e il peso 75/25 confermato per la TERZA volta. Script r0726_reeval_live_weight.py, test tests/test_reeval_live_weight.py (6), diario 2026-07-26-reeval-strategia.md. Book, pesi, cron, config INVARIATI. (1) Solo UNA delle sei misure del giorno apriva una decisione, e per una ragione precisa: il peso 75/25 fu confermato il 24/07 con la lente hourly, che il 26/07 e' risultata pessimistica su ENTRAMBI i lati di SKH01 (uscite +0.081, ingressi +0.048 di Sharpe di book) → se SKH01 vale piu' di come e' stato pesato, 0.25 e' ancora giusto? Contro tirava il LOO de-luckato dello stesso giorno (SKH01 = il meno affidabile dei cinque). Due correzioni in versi opposti: si misura, non si deduce. (2) Misura (path live intra_entry=True, 8 offset, mediana delle differenze appaiate): argmax a w=0.35 e 0.30-0.40 batte 0.25 nell'88% degli offset — il segnale c'e' ed e' nel verso previsto. Ma plateau entro 0.05 = [0.25...0.50] (il peso live e' dentro) e weights_tilt_null FALLISCE (delta_insample 0.0026, gate_pass False). (3) ⚠️ Il motivo vero sta in cio' che la mediana nasconde: il guadagno e' tutto nella coda ALTA. p10 per peso: 1.463 (0.25) / 1.465 (0.30) / 1.455 (0.35) / 1.435 (0.40) / 1.374 (0.50) mentre il p90 sale monotono 1.915→2.064. Alzare SKH01 non compra Sharpe, compra dipendenza da quale ancora ti e' capitata (banda da 0.45 a 0.69). Coerente con altre due misure indipendenti: SKH01 ha la frazione d'ancora piu' grande da restituire (LOO) ed e' 4x piu' fee-sensibile (curva fee). Tre misure indipendenti: SKH01 e' la gamba fragile, e 0.25 sta all'estremo prudente della regione robusta. (4) 📌 La rivalutazione che conta non e' sulla strategia. Ordini di grandezza a confronto: ottimizzare il peso = +0.030 Sharpe (gate fallito); versare €250/mese invece di €0 = da mai a 16.2 anni (P(entro 20a) 92%); perdere il conto Deribit a p=1% = 18% di probabilita' di arrivare, ripartendo da zero. Il book e' dentro il suo plateau su ogni asse misurato: la ricerca ha smesso di essere il vincolo binding. I vincoli binding oggi sono capitale che entra e conto che non sparisce. (Non significa che la ricerca sia finita — significa che il margine residuo vale centesimi di Sharpe contro leve che valgono il risultato.) REGOLE: (a) una rivalutazione parte dall'elenco di cosa cambia una decisione, non dal riassunto di cosa si e' scoperto; (b) quando due correzioni puntano in versi opposti si misura (a occhio si poteva argomentare qualunque cosa); (c) un argmax dentro un plateau non e' una decisione, e la mediana da sola puo' nascondere il fatto decisivo (qui: p90 su, p10 giu'); (d) quando le leve hanno ordini di grandezza diversi dirlo, o si lavora molto senza cambiare niente; (e) rivalutare non vuol dire anticipare i gate pre-registrati — anticiparli e' selezione sull'hold-out.

  • GTAA01 NON E' DEPLOYABILE — blocco PRIIPs CONFERMATO sul conto reale (2026-07-26). Nato da una domanda dell'operatore ("GTAA01 puo' essere in revolut?"), verificato lo stesso giorno tentando l'ordine. Il broker rifiuta: "Trading limitato — Questo prodotto non dispone di un KID in inglese o in una lingua approvata per il vostro Paese. I clienti retail possono negoziare prodotti retail preconfezionati solo se e' disponibile un KID appropriato." SPY/QQQ/IWM/TLT/GLD/HYG sono ETF domiciliati USA: gli emittenti non pubblicano il KID e i broker UE ne vietano l'acquisto al retail. ⚠️ Le quotazioni restano visibili — vedere i prezzi non e' poter comprare, ed e' esattamente cio' che rendeva l'assunzione invisibile. COSA CADE: lo sleeve cosi' com'e' non e' deployabile, e con esso il piano di attivarlo a ~$13k. Restano valide come ricerca e nulle come deploy: la validazione a 30 anni (22/06), il fix dei costi IB (25/07), GTAA_MIN_CAPITAL, e il risultato del LOO (26/07) che lo indicava come l'unico sleeve positivo nel 100% delle estrazioni su tutte e tre le metriche. COSA NON CADE: tutte le traiettorie, i muri e le tabelle di rendita pubblicate usano book_series(with_gtaa=0) = solo TP01+SKH01 su Deribit → nessun numero del piano va rifatto. E il book live non lo include. REGOLA: la negoziabilita' sul conto REALE va verificata quando lo sleeve entra in RICERCA, non quando entra nel book. Qui 5 settimane di misure poggiavano su un'assunzione mai controllata, e il controllo e' costato un ordine di prova. E' l'analogo azionario di cio' che il progetto fa gia' rigorosamente sul crypto (min-order, haircut small-cap, eseguibilita' a $600): la stessa disciplina non era stata applicata all'equity.

  • LA VIA D'USCITA UCITS E' APERTA E COSTA ~ZERO — misurata 2026-07-26 (domanda dell'operatore: "usiamo revolut o degiro"). E la premessa su cui era stata scartata era MIA e FALSA. Script fetch_ib_ucits.py + r0726_gtaa_ucits.py; modulo nuovo src/data/eq_crosscheck.py; test tests/test_eq_crosscheck.py (14) + tests/test_gtaa_ucits.py (10); diario 2026-07-26-gtaa-ucits.md. Book/pesi/cron/config INVARIATI. (0) ⚠️ CORREZIONE: la nota diceva "storia UCITS piu' corta → si perde la validazione a 30 anni". FALSO per un motivo strutturale: il PRIIPs vieta di COMPRARE, non di GUARDARE. I prezzi dei 6 ETF USA restano leggibili (l'operatore li aveva sul terminale mentre l'ordine veniva rifiutato) → il segnale gira sui 30 anni per sempre, cambia solo il veicolo su cui si incassa. La storia corta serve solo a misurare la deviazione del veicolo, un drift lento. Regola: prima di dichiarare che un vincolo esterno distrugge un risultato, chiedersi cosa vincola esattamente — "non posso comprare" ≠ "non posso vedere". (1) Il cambio di veicolo NON costa. Tre lenti a un grado di liberta' per volta su 6.3 anni comuni: L0 (segnale USA + rend. USA, pubblicato) Sh 0.81 / CAGR 3.96%; L2 (segnale UCITS + rend. UCITS, deploy) Sh 0.84 / CAGR 4.08%. Drag del veicolo +0.10%/anno EW, coerente coi TER (controllo piu' netto: GLD 0.40% vs IGLN 0.12% → atteso +0.28%, misurato +0.36%); e la ritenuta USA 15% sui dividendi (~35bps) e' A FAVORE dell'UCITS e non e' nel drag misurato (ADJUSTED_LAST USA e' al lordo). (Ipotesi fiscale dichiarata, fonte secondaria.) ⚠️ Lo stimatore ovvio da' la risposta sbagliata: la media delle differenze giornaliere dava 0.47%/anno su CSPX contro 0.06% vero. Le due serie seguono lo stesso indice ma sono campionate a orari diversi (Londra chiude 4h30 prima) → la differenza giornaliera e' dominata da uno sfasamento che si inverte il giorno dopo: SE ~7%/anno, 15× la quantita' stimata, piu' il drag di varianza. REGOLA: la deviazione fra due veicoli sullo stesso indice si misura sul RAPPORTO CUMULATO (e' una domanda sul drift), mai sulla media delle differenze. (2) IL VINCOLO NON E' IL BROKER, E' IL PREZZO DI UNA AZIONE — e quello e' una SCELTA. CSPX costa $802 e VUAA $144 sullo stesso S&P 500. Due insiemi: STORIA (CSPX/EQQQ/XRSU/ IDTL/IGLN/IHYU, finestra lunga, per misurare) e DEPLOY (VUAA/XNAS/R2US/IDTL/IGLN/IHYU, prezzo unitario basso, per eseguire). A $3.000 con esecuzione a azioni INTERE: STORIA tiene 4/6 gambe ed e' a mercato il 33% del tempo; DEPLOY tiene 6/6 al 65%, ΔSharpe 0.04. Il frazionamento del broker NON serve. Scartati benche' con piu' storia: RTWO (Russell 2000 quality), CSUSS (ESG), IDP6 (S&P 600) — equivalenza dell'INDICE prima della storia. ⚠️ Letto sulla colonna gambe vive + vol, non su Sharpe: il vincolo intero alza lo Sharpe a capitale piccolo perche' arrotonda in giu' e paga meno commissioni = null de-levering, 4ª occorrenza (VRP-DD, TP01×DVOL, MAT01). (3) Il costo per ordine. Col canonico lo sleeve fa 77 ordini/anno a $3k, 102 a $10k, 149 a $50k; soglia oltre cui non vale la pena (Sharpe<0.45) = $0.90/ordine a $3k, $2.23 a $10k, $7.62 a $50k. Listino proporzionale ≈ indifferente al capitale, listino fisso = tassa regressiva (regola 25/07 riconfermata su altro venue). ⚠️ Revolut/Degiro NON sbloccano gli ETF USA: il PRIIPs vale per ogni intermediario UE, IB e' anzi fra i piu' permissivi.

  • ADDENDUM 2026-07-27 — il numero di ordini e' un PARAMETRO, e con la banda giusta il costo smette di essere binding su qualunque broker UE. Nato dalla correzione dell'operatore "io ho gia' Revolut e Degiro e li uso da anni, IB sono solo iscritto": la raccomandazione del 26/07 ("restare su IB") poggiava su "il conto esiste gia'", che era falso. Il gateway IB serve solo per i dati del segnale (basta il paper), quindi il broker di esecuzione e' libero. Script r0727_gtaa_broker.py, test tests/test_gtaa_broker.py (9). Book/pesi/cron/config INVARIATI. (a) I 77-149 ordini/anno sono la conseguenza di REBAL_EVERY=5/REBAL_BAND_USD=50, scelti il 25/07 per il listino IB su azioni USA e a una taglia sola. A cadenza settimanale allargare la banda non costa: Sharpe a costo zero 1.27 ($50) → 1.27 ($400) mentre gli ordini vanno 84 → 23. Rallentare la CADENZA invece costa (1.27 → 1.12 mensile). Meccanismo: _exposure e' la media di 4 indicatori binari, si muove a scatti di 0.25 ≈ $417 su una gamba da $1.667 → la banda filtra la deriva del vol-target, non il segnale di trend. Controllo fuori finestra: sui veicoli USA su 10 anni lo Sharpe a costo zero passa 0.98 → 0.96 mentre gli ordini calano del 74% (133 → 35) — non e' un artefatto della finestra corta UCITS (3.2a). (b) ⚠️ MA la banda in dollari ASSOLUTI e' la parametrizzazione sbagliata. A $3.000 una banda da $400 e' l'80% della gamba: 3 ordini/anno, a mercato il 45% del tempo invece del 66%. Lo Sharpe resta 0.71 — accettabile — su una strategia che ha smesso di seguire il proprio target. E' il null de-levering in veste nuova: non travestito da "meno drawdown" ma da "meno costi". REGOLA: quando un parametro di esecuzione e' espresso in valuta assoluta il suo effetto dipende dal capitale, e il controllo non e' lo Sharpe ma la QUOTA DI TEMPO A MERCATO. (c) Configurazione proposta: banda = 25% della gamba21 ordini/anno a OGNI capitale (invariante), esposizione 66% ovunque; soglia per ordine $5.65 a $3k / $18.90 a $10k / $47 a $25k contro i $2.08 a $3k del canonico. E' la differenza fra "serve un broker economico" e "va bene qualunque broker europeo". ⚠️ Proposta, non cambio di produzione: tarata su questa finestra, non passata per study_family_honest ne' per un deflated-Sharpe — e GTAA01 non e' deployabile prima dei $20k, quindi c'e' tempo per validarla. (d) Cosa cercare sul proprio conto — per ISIN, non per ticker (da contract details IB; tutti domiciliati IE, quotati a Londra in USD): VUAA IE00BFMXXD54 ($143.80) · XNAS IE00BMFKG444 ($65.74) · R2US IE00BJ38QD84 ($86.35) · IDTL IE00BSKRJZ44 ($3.09) · IGLN IE00B4ND3602 ($79.06) · IHYU IE00B4PY7Y77 ($94.12). Nessuna azione oggi (decisione venue: 100% Deribit fino a $20k). ⚠️ CORREZIONE 27/07 A QUESTO PUNTO. Avevo scritto "una linea in EUR aggiunge la conversione per ordine → prendere quella in USD". E' vero solo per un conto in USD. Per un conto in EURO (retail italiano su Revolut/Degiro) vale l'OPPOSTO: la linea USD costringe a convertire a ogni ordine, quella EUR no. L'esposizione economica e' identica (il fondo detiene attivi USD e nessuna delle due linee e' coperta): la valuta di quotazione non copre nulla, decide solo se serve una conversione. REGOLA GIUSTA: prendere la linea nella valuta del proprio saldo. Misurato (turnover lordo $13.655/anno su $10k, 21 ordini): 15bps 0.04 Sh/$20 a., 25bps 0.07 Sh/$34 a., 50bps 0.14/$68 → a 25bps equivale a ~$1.6 in piu' per ordine, piccolo rispetto alla soglia di $18.90. REGOLA: un costo di conversione non e' una proprieta' dello strumento ma della coppia strumento-CONTO. (f) Equivalenze e ripieghi, verificati su contract details IB (27/07). ZPRR (Xetra EUR) == R2US (Londra USD): stessa ISIN IE00BJ38QD84, stesso fondo, stesso NAV → se un broker non quota la linea di Londra, quella di Xetra e' identica (e su conto in euro, migliore). REGOLA: si cerca per ISIN, non per ticker — lo stesso fondo ha ticker diversi su borse diverse. ⚠️ SPY4 IE00B4YBJ215 NON e' small cap ne' S&P 500: e' SPDR S&P 400 MID cap (l'S&P 500 e' SPY5 IE00B6YX5C33). Misurato come ripiego della gamba small: su 6.5 anni Sharpe 0.86 vs 0.86, CAGR 4.26% vs 4.20%, corr fra i due sleeve 0.991, peggiore in 3/7 anni = moneta (sulla finestra corta di 3.2a sembrava 0.15: rumore) → ripiego accettabile, per ragione meccanica (small e mid USA correlano ~0.95 giornaliero, un TSMOM si accende negli stessi giorni). Non e' "validato": 6.5 anni non distinguono due gambe cosi' simili, ed e' esattamente perche' la scelta non conta. Se c'e' una linea Russell 2000, si usa quella. (g) DEGIRO HA TUTTE E SEI LE GAMBE — verificato sul conto reale (2026-07-27, screenshot watchlist "Pythagoras"). Era Revolut a non avere R2US. Su Degiro: VUAA e XNAS su Tradegate in EUR, R2US/IDTL/IGLN/IHYU su LSE in USD. Verifica indipendente che le linee EUR siano gli stessi fondi (dai dati, non dallo screenshot): il rapporto prezzo-IB/prezzo-Degiro dev'essere un solo cambio → VUAA 1.1341, XNAS 1.1315, scarto 0.23%; le altre 4 stanno a 0.993-0.998 (gia' USD). Due fondi diversi non darebbero lo stesso cambio. ⚠️ ERRORE MIO, dello stesso tipo che avevo appena codificato: per cercare le linee in euro delle altre 4 gambe ho interrogato IB per TICKER sulle borse tedesche → "nessuna linea EUR" su 4/4, falso. Cercando per ISIN ognuna ce l'ha: ZPRR (=R2US), IS04 (=IDTL), EGLN (=IGLN, Londra EUR), IS0R (=IHYU). Un "assente" da una ricerca per ticker su una borsa dove quel ticker non esiste NON significa "non esiste". Turnover per gamba a $10k (21 ordini/anno): IDTL 9 ordini / $6.257 = 46%, VUAA $2.289 (17%), IGLN $1.695 (12%), XNAS $1.614 (12%), IHYU $958 (7%), R2US $843 (6%) → il turnover e' concentrato, il 71% e' su gambe in USD ($9.752/anno, conversione $24/a a 25bps, $49 a 50bps = 6-12% del CAGR). Spostare la sola IDTL su IS04 copre il 64% del turnover convertibile. ⚠️ Non e' un risparmio netto (spread Xetra piu' larghi delle linee primarie di Londra + tariffa di connettivita' per borsa) e su $10k parliamo di decine di dollari l'anno in entrambe le direzioni: non e' una decisione importante, ed e' piu' utile dirlo che costruire una precisione finta. ⚠️ Il prompt W-8BEN di Degiro ("aliquota ridotta della ritenuta USA") non riguarda queste sei: sono fondi IRLANDESI, non titoli USA — la ritenuta 15% la subisce il fondo al proprio interno e nessun modulo dell'investitore la cambia. Stato: PREPARAZIONE, non azione (saldo Degiro €328,92; GTAA01 richiede ≥$3k e la decisione venue tiene tutto su Deribit fino a $20k). LEZIONE: una raccomandazione poggiata su un fatto non verificato sul conto reale vale quanto quel fatto — due volte in due giorni un'assunzione sul conto ha cambiato la conclusione (prima la negoziabilita' PRIIPs, poi quale conto e' davvero operativo). (e) "degiro ha api?" — NO, e costa 0.02 di Sharpe. DEGIRO non espone una API di trading ufficiale al retail; Revolut nemmeno (la sua e' per pagamenti); IB si'. I wrapper NON ufficiali degli endpoint interni girano su credenziali + seed 2FA e si rompono in silenzio a ogni cambio di front-end — e il progetto ha gia' pagato quel prezzo (fresh_5m, 26/07): un esecutore automatico che puo' rompersi senza dirlo e' peggio dell'esecuzione manuale. Misurato invece il costo di NON automatizzare: carico operativo 15 settimane/anno con ≥1 ordine (29% dei controlli, 1.4 ordini per volta); costo del ritardo su 10 anni 1g 0.02 (peggiora in 6/11 anni = moneta), 3g 0.13, 10g 0.27. ⚠️ Sulla finestra UCITS di 3.2 anni la curva NON e' monotona (5g 0.26, 10g 0.13) → il campione corto non risolve differenze di questa taglia, si legge la finestra lunga. Il costo non e' il ritardo tipico ma la CODA: il rischio e' la dimenticanza, e si copre con un ALLARME non con una API (gtaa_rebalance_plan esiste gia' in produzione, nato per un esecutore; l'allerta Telegram c'e' gia' sul book live). ⚠️ Lato opposto, vero: il resto del book e' automatico, una gamba manuale aggiunge un modo di fallire che oggi non c'e' — argomento reale a favore di IB, che pero' richiede un secondo venue e quindi cade sotto la decisione venue ($20k). REGOLA: una capacita' mancante si valuta sul costo di non averla, non sulla sua assenza.

  • ⚠️ IL FEED EQUITY NON AVEVA UN CROSS-CHECK — buco trovato e chiuso (2026-07-26). src/data/eq_crosscheck.py. Nel crypto la certificazione incrocia sempre piu' venue (certify_feed.py vs Coinbase USD); il feed equity aveva solo controlli locali (integrita', gap, spike, split). Il primo veicolo estero ha trovato il buco alla prima estrazione: CSPX 2012-01-13 con open/high 112.740 in USD e low/close 88.010 in EUR (fattore dai close adiacenti 1.2797 = EURUSD di quel giorno) → 21.9% e poi +27.8% mentre SPY faceva 0.39%. La certificazione esistente non lo vedeva: unica guardia maxret > 50% → SPIKE?, e una contaminazione EUR/USD vale ~22-28% — stesso schema dello split 2:1 del 25/07 (che valeva esattamente 50%). 2ª conferma: una soglia tarata su una classe di difetto non sorveglia le altre. Perche' il GEMELLO e non una regola locale: il discriminante del 25/07 (range intraday) qui non funziona — anche un crollo vero ha range enorme (SLV 33%). Cio' che separa i casi e' che un evento di mercato lo fa anche il gemello: nel rapporto i movimenti veri si cancellano. Controprova su dati reali: la scansione sui prezzi segnalava IDTL 2020-03 (liquidazione treasury) e IGLN 2013-04 (crollo oro); sul rapporto spariscono. ⚠️ La soglia non era tarabile sulla deviazione — rumore legittimo fino al 9.90% (2025-04-09: Londra chiude alle 11:30 di New York) contro un difetto del 21.4% → margine 2.2×, sotto il 3× richiesto. La risposta non e' accettare il margine ma CAMBIARE STATISTICA: |dev| / movimento del gemello (un disallineamento d'orario non puo' superare il movimento del mercato) → rumore 8.1, difetto 42.7, margine 5.3×. Soglia 18.0, equidistante in scala log. Tre condizioni congiunte: deviazione + non-spiegato + rientro entro 5 barre. Riparazione = SCARTARE la barra, non ricostruirla (del prezzo vero non si sa nulla). ⚠️ Limite dichiarato e chiuso sul DANNO, non sulla rilevabilita': GBPUSD 1.27 → 21% sempre rilevato; EURUSD 1.09 → 8.3% dentro il rumore e non tappabile senza falsi positivi. Misurato invece il danno di una contaminazione non vista: dSharpe mediano 0.003, peggiore 0.056, |Δ|>0.05 nel 2%. REGOLA: quando un buco non si puo' chiudere senza generare falsi positivi, si misura il DANNO del caso non rilevato — un buco quantificato e innocuo e' un risultato, uno taciuto e' un debito. Il limite e' congelato in un test (test_limite_dichiarato_*): se qualcuno abbassa la soglia, il test dice cosa e' cambiato.

  • 💰 I VERSAMENTI — le 4 ipotesi che il piano non aveva mai fatto (2026-07-26, ultimo filone). Tutte le traiettorie del 25-26/07 assumevano versamento piatto, ininterrotto, per sempre = l'ipotesi meno realistica del piano. Script r0726_deposits.py, test tests/test_deposits.py (12), diario 2026-07-26-versamenti.md. Book/pesi/cron/config INVARIATI (non tocca la produzione). Block bootstrap sui ritorni reali del book live, fattore ×0.89 misurato. (1) SMETTERE — il costo non e' proporzionale ai soldi mancanti. €250/m per K anni poi stop, orizzonte 20a: 3a ($10.410) → $202.771 / P(muro) 32.7%; 5a ($16.950) → $287.081 / 53.3%; 10a ($33.572) → $410.220 / 77.9%; 20a ($66.818) → $496.778 / 90.0%. I primi 5 anni sono il 25% dei soldi e il 58% del risultato. → un'interruzione al 12° anno costa poco, una al 3° quasi tutto: argomento per partire con un importo sostenibile, non ambizioso. (2) CRESCENTE E' PEGGIO DI PIATTO a pari soldi. €150/m +5%/anno versa €67.998 → $401.889; piatto €250 versa €66.818 → $496.778 = +24% con gli stessi soldi, solo perche' entrano prima. Metrica giusta per confrontare piani di taglia diversa = $ finale / $ versato (piatti 7.4x, crescenti 5.1-5.9x). Contro-intuitivo: "i versamenti crescono col reddito" e' prudente per il bilancio, non per il capitale. (3) STESSO TOTALE, CALENDARIO DIVERSO = fattore 6. €60.000 distribuiti: ultimi 10 anni $178.494 (P(muro) 11%) / piatto 20a $496.778 (90%) / primi 10a $806.285 (98.3%) / primi 5a $1.104.587 (99.4%). ⚠️ NON significa "versa tutto subito": un piano che non si sostiene non e' un piano — serve a scegliere fra calendari sostenibili. Verificato col rischio di venue dentro (il vantaggio front-load mette piu' capitale sull'exchange prima = proprio il rischio del giorno): regge, 2.22x → 2.09x a p=2%, perche' il rischio colpisce il tempo, non il calendario. ⚠️ MA a p=5% il capitale mediano e' $0 per OGNI calendario (64% di rovina su 20a) → formulazione piu' netta del rischio di venue trovata finora: non erode il piano, lo CANCELLA. (4) LA DOMANDA INVERSA — rendita netta €/g mediana (riformula l'obiettivo: €50/g e' UN punto, non l'unico risultato):

    €/mese 5a 10a 15a 20a P(€50/g a 20a)
    100 2.08 6.54 16.40 38.07 31.0%
    150 3.00 9.55 23.96 55.80 58.7%
    250 4.83 15.53 39.11 91.30 90.0%
    400 7.59 24.52 61.85 144.23 98.9%
    600 11.26 36.52 92.17 215.07 100.0%
    Non-linearita': da 15 a 20 anni la rendita piu' che raddoppia a ogni livello (gli ultimi anni
    contano piu' in rendita, i primi piu' in versamenti).
    (5) FREQUENZA = la decisione meno importante. Mensile fino a ~$2 di costo per trasferimento,
    bimestrale sopra, trimestrale oltre $25 — ma le differenze sono 1-3% del capitale finale.
    Verificato che un deposito non resta strozzato: col cap dinamico attivo cap = equity/2 =
    esattamente il nozionale massimo richiedibile per asset.
    📌 ORDINE DI IMPORTANZA (da citare quando si parla del piano): versare o no (**da mai a 16
    anni**) > quando (6x) > quanto presto si smette (5 anni = 58% del risultato) > piatto vs
    crescente (24%) > frequenza (1-3%). E sopra tutte, fuori scala: **a p=5% di rischio venue il
    risultato mediano e' zero comunque.**
    REGOLE: (a) un piano di accumulo si giudica sulle sue deviazioni, non sul caso nominale —
    piatto/ininterrotto/per sempre e' l'unico scenario che non succede; (b) piani di taglia diversa si
    confrontano con una metrica normalizzata ($ finale / $ versato), altrimenti "versa di piu'"
    vince sempre; (c) un vantaggio calcolato ignorando un rischio noto va ri-misurato con quel
    rischio dentro anche quando ci si aspetta che regga (qui reggeva, ma la colonna p=5% ha prodotto
    il risultato piu' importante del filone); (d) quando l'obiettivo dichiarato non e' raggiungibile,
    la tabella utile e' quella inversa — non "quando arrivo a X" ma "cosa compro con quello che
    ho".
  • 📅 NUOVO SCHEMA FEE DERIBIT dal 2026-08-01 — misurata la CURVA, nessuna azione oggi (2026-07-26). Script r0726_fee_sensitivity.py, test tests/test_fee_sensitivity.py (6), diario 2026-07-26-fee-deribit.md. Book/pesi/cron/config INVARIATI. L'annuncio (taker piu' bassi, maker rebate piu' bassi, soglie VIP abbassate, nuovo VIP7, liquidation fee 1% su tutti i prodotti, spot a zero fino al collegamento con Coinbase) non contiene numeri e ⚠️ la tabella nell'articolo Insights e' un'IMMAGINE, non letta da fonte primaria → i valori indicativi (base ~5bps taker / 2bps maker, VIP7 2/0) vengono da un riassunto secondario e vanno etichettati come tali. Percio' e' misurata la curva:

    bps/lato %RT TP01 Sh SKH01 Sh BOOK Sh BOOK CAGR
    0 0.00% 1.322 1.567 1.849 21.69%
    3 0.06% 1.303 1.495 1.799 20.99%
    5 0.10% 1.290 1.446 1.766 20.53% ← oggi
    10 0.20% 1.258 1.324 1.682 19.39%
    15 0.30% 1.226 1.200 1.597 18.26%
    Sensibilita' marginale del book: 0.017 Sharpe/bps, 0.23% CAGR/bps → anche un RADDOPPIO del
    taker costa 0.08 di Sharpe, meno della banda d'ancora dello stesso book (2.222 → 1.946).
    ⚠️ SKH01 e' ~4× piu' sensibile di TP01 (0.69% vs 0.09% CAGR/bps: round-trip discreti vs
    posizione continua vol-targeted) → **se il taker salisse, il primo parametro da rivedere e' il
    peso 75/25**, non altro. **REGOLA DECISA IN ANTICIPO (per non decidere col numero davanti):
    taker ≤5bps/lato → non si tocca nulla; >10bps/lato → rivedere il peso di SKH01.**
    Punti irrilevanti e perche': maker — il book manda ordini market; tocca solo la
    raccomandazione T1 non implementata (TP resting per incassare il maker), che resta chiusa
    per il netting su strumento unico e il cui beneficio era quasi tutto "convertire una lotteria in
    certezza", non la fee. Liquidation fee 1%live.json da' nozionale lordo max **1.00x
    l'equity** (frac 0.5 × 2 asset) con disaster-SL 30%: servirebbe un movimento avverso ~100%;
    ⚠️ la conclusione poggia sul CAP, quindi e' cablata una guardia di decisione
    (test_leva_massima_da_config_resta_sotto_o_uguale_a_1x): alzare il cap rompe il test.
    VIP/VIP7 — a $600 il volume 30g e' trascurabile, tier base a qualunque soglia.
    Cio' che il cambio non puo' rompere: tutti i backtest sono a 0.10% RT → se la fee scende
    diventano conservativi. AZIONE 1 agosto: leggere il tier reale in Account Settings e
    applicare la regola sopra. REGOLE: (a) a un annuncio senza numeri si risponde misurando la
    curva, non aspettando il numero; (b) dichiarare la qualita' della fonte (immagine non
    letta = dato secondario); (c) una conclusione che poggia su un parametro di config va legata a
    un test su quel parametro, o sopravvive al cambio che la rende falsa.
  • MURO COME PUNTO FISSO — la mia previsione era SBAGLIATA e il numero pubblicato era giusto per caso (2026-07-26). Script r0726_wall_fixedpoint.py, test tests/test_wall_fixedpoint.py (11), diario 2026-07-26-wall-fixedpoint.md. Book/pesi/cron INVARIATI. Il follow-up dichiarato diceva: "i muri usano il book a 2 sleeve da $600 estrapolato a $272k; il book diversificato ha Sharpe piu' alto → il muro vero e' piu' basso". Misurato: FALSO. (1) Struttura giusta: il muro e' un PUNTO FISSO — serve capitale C per girare il book che determina il muro C → si itera C_{n+1} = muro(book(C_n)). Converge in 1 iterazione perche' il muro cade sopra la soglia XS01 ($117k), quindi la composizione non cambia; la struttura conta solo se il muro atterra vicino a una soglia — ma va iterato per saperlo. (2) Risultato: book deployable (TP01 38/SKH01 23/GTAA01 23/XS01 17; VRP01 escluso per regola short-vol, XSR01 escluso per gate 23/10; costi capital-aware; ancora ×0.860 misurata su questo book) → Sharpe 1.94, vol 8.9%, CAGR 18.3%. Muro $273.900 vs $272.061 = +1%. (3) Perche': diversificare alza lo Sharpe (1.64 → 1.94) ma abbassa drift e vol insieme; la rendita perpetua vive sul drift → 10.91% → 10.84% = invariata. Il guadagno di Sharpe va in meno rischio, non in piu' reddito — cioe' il fatto gia' misurato il 25/07 §3, che avevo dimenticato scrivendo il follow-up. (4) ⚠️ Stavo violando una regola gia' codificata: "un diversificatore a basso CAGR si giudica a ISO-RISCHIO, mai a iso-nozionale" (25/07 §3). A iso-rischio (leva 1.28x): rendita 13.35%, muro $222.406 = 18% replica indipendente del 19% misurato il 25/07 con macchineria e book diversi. Vale solo se la leva e' disponibile e a costo < uplift (IB: Reg-T 2x, portfolio margin da ~$110k, margine ~5.5%/a): $222k e' un TETTO, non una stima. (5) ⚠️ BUG catturato prima di pubblicare: la prima corsa dava Sharpe 0.95 e muro $854k ("diversificare triplica il muro" — spettacolare e falso). Causa: CC.gtaa_banded ritorna la storia GTAA dal 1996 mentre lo sleeve di produzione tronca a GTAA_BOOK_ACTIVATION; con la rinormalizzazione per-riga di combine_outer il 75% del campione era GTAA01 da solo al 100%. Preso non da un test ma perche' la somma pesata dei componenti (~18%) non tornava col drift del combinato (6.8%). Diagnostica decisiva: la COPERTURA PER COLONNA (TP01 24.6% / SKH01 24.6% / GTAA01 100.0% / XS01 8.6%) — un 100% accanto a valori bassi dice tutto. REGOLE: (a) un follow-up dichiarato contiene una previsione, che va misurata non assunta; (b) rileggere le regole gia' codificate prima di impostare il confronto; (c) quando un aggregato non torna con la somma dei suoi pezzi, fermarsi — era l'unico segnale del bug (nessun test, nessuna eccezione, output plausibile); (d) la copertura per colonna e' la prima diagnostica di un outer-join.

  • EDGE WATCH — criteri di kill del book LIVE, cablati (2026-07-26). (Bullet aggiunto il 27/07: era in cron dal 26/07 e NON stava in CLAUDE.md — il criterio di morte di cio' che gira con soldi veri non era nella memoria operativa.) scripts/live/edge_watch.py (in cron_daily.sh), taratura r0726_edge_death.py, test tests/test_edge_watch.py (11). Chiudeva l'asimmetria: gate di kill pre-registrati per i CANDIDATI, nessuno per il book. (A) RITORNO: Sharpe rolling 36m < 0.5 — falso kill 1.8% in 10 anni, riconosce l'edge morto nel 91% dei casi in ~3.8 anni. ⚠️ La lentezza non e' un difetto della regola, e' statistica: a 12 mesi la stessa regola ucciderebbe un edge VIVO nell'80% dei casi; a 12m il 56% dei casi "morto" e' indistinguibile da uno vivo. (B) PROTEZIONE: in un anno con DD buy&hold > 10%, il DD di TP01 deve restare sotto il 75% di quello — storico 8/8 anni di sinistro superati (protezione 1.8x-34.4x). Serve un criterio SEPARATO perche' il LOO misura il contributo hold-out di TP01 negativo nel 99.1% delle ancore: "non ha guadagnato" non e' evidenza di morte per uno sleeve difensivo — la sua morte e' non proteggere nel sinistro, e negli anni senza sinistro il criterio NON si valuta. Se (A) scatta il book non si spegne da solo: si riapre weights_tilt_null + deflated-Sharpe sui dati nuovi. Se (B) fallisce 2 anni di sinistro consecutivi, il peso di TP01 va rimesso in discussione. Stato 27/07: Sharpe 36m +1.51, protezione 8/8. Diario 2026-07-26-edge-death.md.

  • 💰 IL CAPITALE GIA' FERMO — la leva mai misurata, e la decisione di venue che ne dipende (2026-07-27). r0727_lumpsum_split.py, test tests/test_lumpsum_split.py (14), diario 2026-07-27-lumpsum-venue-gates.md. Book/pesi/config INVARIATI. Tutte le traiettorie del 25-26/07 hanno START = 600.0 cablato: il progetto ha misurato il calendario dei versamenti (fattore 6) e mai un versamento iniziale, mentre su Revolut ci sono ~€10.000 (di cui €6.043 in XEON a ~0% reale netto) contro i $600 che girano. Macchineria = generalizzazione di r0726_venue_risk.simulate, validata: con lump 0 riproduce IDENTICI i numeri del 26/07. (1) Cosa compra (p=0, 20a): €10.000 fermi oggi e mai piu' nulla → traguardo 17.2a mediani, P 62%, rendita €61.58/g (il piano €250/m senza lump: 15.7a, P 95%, ma $66.818 versati contro $10.900). Con entrambi: 13.3a, P 99.5%. (2) ⚠️ L'equivalenza si misura in versamento mensile equivalente, NON in versamenti risparmiati: la prima stesura diceva "€10k ≈ €7.414 risparmiati = 0.7x" — numero giusto, domanda sbagliata (il valore e' arrivare prima, non versare meno), e invita alla conclusione opposta. Onesto: €10.000 oggi = +€154/mese per 13 anni = €24.523, cioe' 2.45×. (3) Col rischio di venue dentro (a €10k il conto e' $11.500 e lo split diventa possibile — a quota IB 26%, non il 25% preferito: sotto $3.000 la gamba equity non esiste): lo split costa 1.9-2.6pp di P(arrivare) e taglia P(perso tutto) da 18.4% a 3.5% a p=1% (da 33.7% a 11.2% a p=2%). Il haircut dichiarato sulla gamba IB (0.8pp taglia piccola + 0.1pp UCITS) sposta 0.1-0.2pp: il costo della gamba equity non decide. ⚠️ P(perso tutto) sotto concentrazione NON dipende dal capitale (con un conto solo "almeno un fallimento" coincide con "perso tutto"): il lump non la peggiora, moltiplica cio' che porta via. (4) IL RISULTATO OPERATIVO — la protezione non e' bloccata dal PRIIPs. GTAA01 oggi non e' deployabile, quindi misurato anche lo SPLIT-CASSA (seconda gamba ferma): costa 0.6-0.8pp di P(arrivare) in piu' e la protezione e' IDENTICA (dipende da quanti conti falliscono, non da cosa ci sta sopra). Un rischio non-diversificabile si compra con un secondo CONTO, non con un secondo sleeve. (5) Soglie: split a quota raccomandata da $12.000, forzando al 35% da $8.571. La riapertura della decisione venue e' a $20.000: un lump da €10k cade sotto quella soglia ma sopra la fattibilita' tecnica, ed e' un cambiamento del piano = il caso in cui CLAUDE.md dice di riaprire PRIMA. Materiale pronto; la decisione resta dell'operatore. ⚠️ Cosa NON decide: quanto dei €6.043 sia vero fondo d'emergenza (un fondo d'emergenza non e' capitale disponibile). ADDENDUM "€5k messi dove" (stessa sessione). (a) ⚠️ La configurazione REALE non era quella tabulata: config/live.json fu alzato il 26/07 "in previsione del versamento (EUR 5.000 + 500/mese)" → il piano e' €500/mese, non €250. Nessuna azione di config al deposito: il cap e' gia' min($3.000, equity_osservata × 0.5) = leva lorda ≤1x a $6.050, protetto dal watermark. (b) A $6.050 non si sblocca NIENTE (GTAA01 vorrebbe il 50% del conto e non e' deployabile; XS01 $20k; XSR01 sotto gate) → il book resta TP01+SKH01 e l'unica domanda e' quanta parte NON sta sull'exchange. (c) Split in liquidita', p=1%, 20a: fuori 0% → P(arrivare) 89.4% / 11.4a / P(perso tutto) 18.4%; 10% → 89.0% / 11.8a / 3.5% [0.0% con cassa in banca] / salvati $6.818; 25% → 88.5% / 12.4a / salvati $17.045; 40% → 87.8% / 13.3a / $27.272. ⚠️ P(perso tutto) SATURA a qualunque quota > 0 (3.5% al 10, 25 e 40%): la protezione binaria si compra col FATTO di avere un secondo conto, non con quanto ci si mette → quando una metrica binaria satura, la decisione si sposta sulla metrica continua (qui il salvataggio). ⚠️ Errore mio corretto in sessione: la colonna del salvataggio riportava prima il capitale a 20 anni condizionato al fallimento ($77k al 10% = 11× il vero), gonfiato dalla convenzione ereditata dal 26/07 per cui i versamenti si dirottano ai superstiti (e si scartano se non ne resta nessuno) → attribuiva allo split il valore di continuare a versare, che si ottiene comunque aprendo un altro conto. Misura onesta = salvataggio ISTANTANEO, congelata in test_il_salvataggio_e_istantaneo_non_a_scadenza. (d) Lo split non si costruisce spostando soldi su un secondo venue: si ottiene versandone di meno. Con €6.043 in XEON, deporne €5.000 lascia fuori ~16% del capitale investito = gia' dentro la banda 10-25%, a costo operativo zero. Prezzo del 25%: 0.9pp di P(arrivare) e ~1 anno di ritardo mediano.

  • FEE WATCH + MONITOR HEALTH — due sorveglianze cablate (2026-07-27). Nessuna tocca l'esecuzione; entrambe in cron_daily.sh. (1) scripts/live/fee_watch.py (test 13): il nuovo schema fee Deribit entra il 1° agosto e l'annuncio non ha numeri → invece di un promemoria, un sorvegliante. Legge il tier BASE da public/get_instrument (nessuna chiave; a $600 ogni soglia VIP e' fuori portata), oggi taker 5.00 / maker 0.00 / liquidazione 75-90 bps, applica la regola congelata (≤5bps nulla · >10bps rivedere il peso SKH01) e allerta su qualsiasi cambiamento dei tre. test_baseline_e_quella_dei_backtest lega la soglia al default fee_rt=0.001 di backtest_signals: se divergono, il test lo dice. ⚠️ CORREZIONE 2026-08-21 — sorvegliava lo STRUMENTO SBAGLIATO (test 13 → 17). INSTRUMENTS era la tupla cablata ("BTC-PERPETUAL","ETH-PERPETUAL") = i perpetual INVERSE (regolati in BTC/ETH), mentre il book esegue sui LINEARI USDC (BTC_USDC-PERPETUAL). Due conseguenze: (a) il tier sorvegliato era di un prodotto mai tradato — oggi identico per caso (3.50/1.50 su entrambe le linee) ma la prova che si muovono in modo indipendente e' nel progetto: il cambio del 18/08 tocco' i SOLI lineari (inverse ancora tick 0.5/min 10.0, lineari 0.1/0.0001) → un aumento sulla sola linea lineare sarebbe stato invisibile e la regola ≤5/>10 bps applicata al numero sbagliato; (b) il cross-check sui trade reali non poteva misurare nulla per costruzione — chiedeva trade_history di uno strumento con 0 fill e stampava «NON MISURATO» anche nei giorni con 4 esecuzioni (verificato: inverse 0 trade, _USDC 3+1). Ora INSTRUMENTS si DERIVA da src.live.book.INSTRUMENT: la divergenza non e' un rischio da ricordare, e' impossibile. ⚠️ E non era un rename: le due famiglie hanno unita' DIVERSE — inverse amount=nozionale USD e fee in valuta base; lineare amount=quantita' BASE e fee gia' in USDC. Ripuntare senza correggerle avrebbe dato, su un fill vero (0.001 BTC @ 74.305,80, fee 0,02600703), ~2,6e8 bps invece di 3,50 — e senza sollevare nulla. Cablate convenzione() (lineare/inverse/ignota: una famiglia non nota non si indovina) e fee_bps_di_un_fill() pure; il cross-check ora gira e da' 3,50 bps effettivi = il tier esatto, e il report stampa lo scarto effettivotier con ⚠️ sopra 1 bps. REGOLA: un sorvegliante deve DERIVARE il proprio bersaglio dal codice sorvegliato, mai ridichiararlo — due liste in due file divergono in silenzio, e il giorno che divergono il sorvegliante continua a dire OK. 3ª occorrenza in un giorno della stessa forma (test di book_live senza potenza a libro flat, taratura di venue_watch misurata con bitfinex mentre il live girava senza): un controllo puntato su una configurazione diversa da quella che gira passa sempre, e non sta controllando niente. (2) src/live/monitor_health.py + scripts/live/monitor_health.py (test 16): tre gate pre-registrati (STATARB 27/09, XSR01 23/10, DVOLSPREAD 24/10) si decidono su serie forward di cui una sola aveva una guardia d'integrita'. Un monitor fermo produce silenzio, e il silenzio in una serie di ritorni si legge come zero (stesso schema di fresh_5m e del feed-freeze 14/07). Misura due guasti, perche' uno solo non basta: coda (ultima barra vecchia) e buchi interni (copertura fra prima e ultima barra) — ⚠️ una serie bucata E fresca passa qualunque controllo di freschezza, ed e' il guasto che falsifica un gate senza farsi notare. Cadenze dichiarate per monitor (prevday e' orario, combo segue il calendario di borsa: sbagliarle = un falso allarme a settimana); soglia di copertura 0.80 riusata dal veto DVOLSPREAD perche' i gate restino confrontabili. Stati OK/FERMO/BUCATO/ASSENTE/NUOVO — "troppo giovane per un giudizio" non e' "sano". Controlli positivi obbligatori nei test. Stato 27/07: 6/6 giudicati, tutti OK (combo 96% per una festivita' che np.busday_count non conosce = limite dichiarato, conservativo).

  • BANDA GTAA01 AL 25% — VALIDATA, produzione NON toccata (2026-07-27). r0727_gtaa_band_gate.py, test tests/test_gtaa_band_gate.py (13). Chiude il debito dichiarato il 27/07 ("tarata su questa finestra, non passata per study_family_honest ne' per un deflated-Sharpe"). Griglia 30 celle (5 cadenze × 6 bande) su 29.9 anni del path di produzione, annualizzazione √252. (A) Selezione in-sample (cella scelta sui soli dati pre-2015, letta sul 2015+): proposta 4/30 in-sample, 5/30 hold-out → il rango NON migliora sull'hold-out, quindi non e' selection-on-holdout. La cella scelta al buio (cadenza giornaliera, banda 25%) vale +0.04 di Sharpe ma costa 250 controlli manuali/anno su un conto senza API → non e' una configurazione, e' un'ipotesi. (B) Deflated Sharpe 0.999 PASS (nullo 0.14). (C) ⚠️ il modo di fallire NON e' il de-levering: allargando la banda la vol non scende (0.99-1.10 del riferimento), si rompe il TRACKING (corr 0.951 a 25% → 0.907 a 40% → 0.859 a 60%) e lo Sharpe smette di migliorare insieme alla correlazione → nessuna zona premia il congelamento. Ma il 25% e' AL BORDO (0.951 contro soglia 0.95), non al centro di un plateau: citarlo cosi'. Invarianza: 25 ordini/anno a $3k/$10k/$50k (banda 25%, Sharpe 0.66/0.70/0.71) contro 65/92/134 (banda $50 fissa, 0.52/0.62/0.66) — ⚠️ 25 e non i 21 citati il 27/07: stimatore diverso (griglia dei controlli su 30 anni USA vs cambi di posizione sulla finestra UCITS di 3.2a); l'invarianza, che e' la proprieta' sotto esame, regge in entrambi. Impatto sul book: Sharpe FULL 2.221 → 2.221, maxDD 6.08% → 5.94% = zero (il book modella GTAA01 a $10k, dove la banda fissa gia' funziona) → il valore e' tutto al capitale piccolo (0.52 → 0.66 a $3k), cioe' al deploy. REBAL_BAND_USD NON cambiato: non sposta un numero pubblicato e lo sleeve non e' deployabile prima dei $20k → si applica al deploy, con questo gate come giustificazione. REGOLA: un parametro d'ESECUZIONE scelto guardando il risultato e' selezione come ogni altra e passa per gli stessi gate, anche quando "non tocca l'allocazione". ⚠️ CORREZIONE 2026-08-07 — il criterio (A) qui sopra e' RITIRATO: non misurava cio' che dichiarava, e il "4/30 in-sample, 5/30 hold-out" non e' un'evidenza. Il test lo aveva segnalato smettendo di passare (9ª/30 in-sample, 8ª/30 hold-out) senza che il codice fosse cambiatodata/raw/ e' gitignored e il cron riscrive i parquet equity ogni notte con ADJUSTED_LAST di IB, che e' retroattivo. Misurato in r0807_gtaa_gate_resolution.py: (a) i due ranghi distavano 0.00116 di Sharpe su uno spread di griglia di 0.3124 (0.4%); (b) e soprattutto il criterio rank_in <= rank_oos lo passano 14/30 celle (47%) PER COSTRUZIONE — la somma dei ranghi e' la stessa nelle due finestre → e' una moneta, e il 27/07 la moneta era uscita bene. Contorno: spostamento tipico fra le due finestre 8 ranghi (max 25), Spearman IS/OOS +0.05. CRITERIO SOSTITUITO, e la proposta ne esce piu' forte di prima. La proposta e' una BANDA (la cadenza settimanale e' gia' REBAL_EVERY=5 in produzione), quindi la domanda decidibile e' quale banda si sceglie a cadenza di produzione guardando solo il pre-2015: esce 25% = la proposta, con margine +0.0151 di Sharpe sulla seconda (13× il margine del vecchio criterio); chi avesse scelto sull'hold-out avrebbe preso 40% (controllo positivo: se coincidessero il gate non avrebbe potenza). Su tutta la griglia la cella al buio e' cadenza 1 / banda 25% — stessa banda. La proposta e' il CONTRARIO di una selezione-sull'hold-out. Regge identico sull'universo a 5 gambe (blind 25%, hold-out 40%, margine +0.0164). ⚠️ Il criterio dice da dove VIENE la scelta, non che sia la migliore sull'hold-out (con Spearman ~0 nessuna cella lo sarebbe): provenienza ≠ previsione. ⚠️ TROVATO PER STRADA, ed e' il difetto vero: TLT ha 13.5 ANNI DI STORIA IN MENO. Parte dal 2016-02-03 invece che dalla quotazione (2002-07-22) → GTAA01 gira su CINQUE gambe prima del 2016, e quella assente e' la gamba obbligazionaria, cioe' quella che diversifica. Non e' di oggi (cosi' fin dal primo giro nel cron_daily.log, 24/06 = prima della validazione del 27/07) e non e' un fetch da rifare: una richiesta retro esplicita a IB su questo conto ritorna 0 barre. Conseguenza metodologica: l'in-sample e l'hold-out di GTAA01 non sono la stessa strategia, e ogni confronto fra le due finestre su questo sleeve va letto cosi'. Guardia cablata (fetch_ib_equities.certify, test tests/test_eq_history_guard.py, 11): TRONCATO = storia persa rispetto al disco → il file NON viene sovrascritto (e neppure fuso: ADJUSTED_LAST e' ri-aggiustato all'indietro, incollare due vintage crea un salto sul giunto); STORIA-CORTA = parte >1 anno dopo la quotazione e non al tetto della richiesta (PRIMA_QUOTAZIONE, 6 simboli, fonte secondaria dichiarata). Controlli positivi obbligatori: giro normale, serie al tetto 30Y, ETF giovane, simbolo fuori tabella. REGOLE: (a) un criterio si misura sulla sua RISOLUZIONE prima che sul suo esito — se decide su una frazione di percento dello spread e' rumore anche quando passa; (b) un gate si valida contando quante volte lo passa un candidato a caso (qui 47%: il conto si poteva fare il 27/07 senza dati nuovi); (c) una certificazione che guarda solo DENTRO la serie non vede cio' che la serie ha PERSO — una serie troncata e' integra, senza gap, senza spike, senza duplicati, e passa tutto (3ª occorrenza dopo split 2:1 e contaminazione EUR/USD); (d) distinguere «giovane» / «al tetto della richiesta» / «troncato», o la guardia segnala sempre e viene ignorata; (e) un test che fallisce senza che il codice sia cambiato sta segnalando che i dati non sono versionati — si guarda sotto prima di toccarlo. Diari 2026-08-07-crescita-fisco-etf-scelta.md §7 (scoperta) e 2026-08-07-gate-gtaa-e-storia-troncata.md (risoluzione).

  • 💰 IL FISCO DURANTE L'ACCUMULO — mai contato in nessuna traiettoria, vale 30% a 10 anni (misurato 2026-07-27, registrato qui il 2026-08-07). ⚠️ I quattro risultati del 27/07 sera (r0727_3k_vs_5k.py, r0727_orizzonte10.py, r0727_tasse.py) erano solo nei messaggi di commit, ne' in CLAUDE.md ne' in un diario — e uno cambia il numero di testa del piano. TAX_RATE compariva in un solo punto del progetto: la lordizzazione del bersaglio in fase di prelievo. L'accumulo componeva al lordo per dieci o vent'anni. Costo (lump €5.000 + €500/mese): 15.7% a 5 anni · 29.8% a 10 · 42.6% a 15 (27/07 su lump €10k: 16.8 / 31 / 44% → replica coerente). L'errore e' COMPOSTO. ⚠️ Conseguenza: TUTTE le tabelle a 15-20 anni pubblicate sopra sono al LORDO del fisco d'accumulo e vanno lette con questo sconto. Assunzioni dichiarate (33% plusvalenze, minusvalenze in carry 4 anni, 0.2% annuo sul valore), non un parere fiscale; il modello tassa la variazione ANNUA di valore = limite superiore, stretto perche' il book realizza quasi tutto entro l'anno. Vincolo dei 10 anni (operatore, 49 anni): il piano NON lo regge. €5k+€500/m → P(entro 10a) 19.7% al lordo; €10k+€500/m → 33.9% lordo ma 3.8% col fisco. Servono €880/mese a P=50%, €1.051 a P=75% (lump €10k) → si versano oltre $119.000 per arrivare a $272.061: a orizzonte corto non fai lavorare la strategia, compri il capitale coi bonifici. 📌 Contro-intuitivo: versare di piu' RITARDA il sorpasso (l'anno in cui il guadagno cumulato supera tutto il versato): 7º anno a €500/m, 8º a €800/m — alza l'asticella. I €300 in piu' comprano il traguardo, non il sorpasso: mediana al bersaglio al 12º anno invece del 15º, P(bersaglio) a 15a da 73.2% a 99.0%. Lump €3k vs €5k = ~1.8 mesi ogni €1.000 → non e' una decisione. Script scripts/research/r0807_growth_yearly.py. TABELLE RIFATTE AL NETTO (2026-08-07) — il muro si sposta poco, i VERSAMENTI molto. scripts/research/r0807_piano_netto.py, test tests/test_piano_netto.py (16), diario 2026-08-07-piano-al-netto.md. Book/pesi/cron/config INVARIATI. (0) Controllo di replica superato: a fisco spento la nuova macchina riproduce $272.061 al dollaro (implementazione separata) e la colonna LORDA delle traiettorie riproduce 4 righe su 4 della tabella pubblicata (16.3/12.4/9.0/6.0 contro 16.2/12.4/9.0/6.0). ⚠️ Trovato per strada: perp_and_wall gira a 2000 path e a quella taglia da' $269.648la terza cifra del muro e' rumore Monte Carlo (0.9%): si cita $272k, non $272.061. (1) IL MURO era calcolato con una convenzione ASIMMETRICA — prelievo lordizzato ma capitale che compone senza mai pagare imposte. Coerente (imposte annue dentro il portafoglio, prelievo gia' netto): perpetua 10.91% → 7.70%, muro $272.061 → $258.338 (5.0%); a 26% $236.310. I due errori vanno in versi OPPOSTI e si compensano quasi — per caso, non per costruzione. (2) TRAIETTORIE da $600 (25a, 3000 path, seed 725; mediana CONDIZIONATA all'arrivo + P(20a)):

    €/mese LORDO anni / P(20a) NETTO anni / P(20a)
    0 mai / 0% mai / 0%
    250 16.3a / 92% 19.8a / 52%
    500 12.4a / 100% 14.7a / 99%
    800 10.0a / 100% 11.4a / 100%
    1000 9.0a / 100% 10.0a / 100%
    2000 6.0a / 100% 6.4a / 100%
    📌 **€250/mese — il livello con cui il piano risultava «P 92%, funziona» — al netto e' una
    moneta (52%).**
    (3) QUANTO VERSARE, al netto (bersaglio $258.338; fra parentesi il vecchio numero lordo):
    orizzonte P=50% P=75%
    --- --- ---
    10 anni €998/m €1.162/m
    15 anni €470/m €570/m
    20 anni €245/m €306/m
    Il fisco costa +12% al mese a 10 anni, +32% a 15, +57% a 20 (cresce con l'orizzonte perche'
    l'errore era composto). La lettura del 26/07 si RAFFORZA: a 10 anni versi $175k per arrivare a
    $258k (il rendimento fa il 32%), a 20 anni ne versi $99k (il rendimento fa il 62%).
    (4) RENDITA €/g mediana, netta (perpetua 7.70%, imposte gia' dentro — non lordizzare due
    volte): €250/m → 4.38 (5a) / 11.82 (10a) / 24.61 (15a) / 46.61 (20a), P(€50/g a 20a)
    42.0% contro i 91.30 €/g e 90.0% pubblicati; €500/m → 92.11 e 97.6%; €800/m → 146.78.
    COSA NON CAMBIA: senza versamenti il capitale-rendita non si raggiunge mai a nessuna
    lente fiscale; l'ordine delle leve (versare > quando > quanto presto si smette > piatto vs
    crescente > frequenza) e' invariato; il rischio di venue resta fuori scala (a p=5% il mediano
    e' zero comunque).
    ⚠️ ERRORE MIO catturato prima di pubblicare: la prima stesura calcolava la mediana degli
    anni sull'INTERO vettore coi non-arrivi a -1 → €250/mese risultava passare da 15.7 a 15.3
    anni col fisco (piu' veloce) mentre P crollava da 91% a 53%, perche' con meta' dei path a 1
    la mediana cade sui PRIMI arrivi. REGOLA: un non-arrivo va codificato +∞, mai 1 — con 1 il
    numero migliora tanto piu' quanto peggio va la colonna. E **una mediana condizionata si stampa
    sempre accanto alla sua probabilita'**.
    REGOLE: (a) un modello che tassa una meta' del conto e non l'altra non e' conservativo, e'
    incoerente — e i due errori possono compensarsi quasi esattamente, il che li rende
    invisibili finche' non si rifa' il conto in modo simmetrico; (b) prima di pubblicare un numero
    nuovo, far riprodurre alla macchina quello vecchio; (c) **un Monte Carlo ha una risoluzione
    e va detta** ($272.061 e' esatto quanto $269.648: la differenza e' la taglia del campione).
  • 🇮🇹 QUADRO FISCALE VERIFICATO SULLE FONTI (2026-08-07) — il 33% e' confermato, la citazione normativa del progetto era SBAGLIATA, e la domanda che vale $22k resta aperta. Fonti: Fisco Oggi (rivista dell'Agenzia), Eutekne, Fiscomania, Circolare AdE 30/E del 27/10/2023, guide professionali. Non e' un parere fiscale. Corretto in r0725_capcurve.py, r0725_ib10k.py, r0727_tasse.py, r0807_asset_compare.py e nel diario 24/07. Nessun numero del piano cambia: l'aliquota assunta era ed e' 33%. CONFERMATO — (a) 33% sulle plusvalenze cripto realizzate dal 1/1/2026, su art. 67 c.1 lett. c-sexies TUIR; (b) franchigia €2.000 ABOLITA dal 2025; (c) minusvalenze riportabili 4 periodi d'imposta (art. 68 c. 9-bis) ma solo contro plusvalenze cripto — comparto separato dagli strumenti finanziari tradizionali; (d) patrimoniale 2‰ sul valore al 31 dicembre (dovuta sopra €12/anno), quadro RW/W; (e) regime dichiarativo per gli exchange esteri (quadro RT per i redditi, RW per il monitoraggio). ⚠️ CORREZIONE DI FONTE: il progetto citava ovunque «L.199/2025» come origine del 33%. Falso. Il 33% dal 2026 e l'abolizione della franchigia vengono dalla L. 207/2024 art. 1 c. 23-29 (Bilancio 2025). La L. 199/2025 art. 1 c. 28 (Bilancio 2026) fa un'altra cosa: ritaglia il 26% per i soli token di moneta elettronica denominati in EURO (EMT ex Reg. UE 2023/1114, riserve interamente in attivi in euro presso soggetti UE autorizzati) e stabilisce che la conversione euro↔EMT non e' realizzo. BTC/ETH e le stablecoin in DOLLARI restano al 33% → nessuna scappatoia per questo book. APERTA, e nessuna fonte la chiude: come si qualificano i DERIVATI Deribit. La Circolare 30/E (118 pagine) definisce le cripto-attivita' e non tratta i derivati. Le fonti professionali sono nette nel senso opposto al nostro assunto — «i CFD su crypto NON sono cripto-attivita': sono derivati su sottostante crypto e vivono nella Sezione II del Quadro RT, aliquota 26%» (lett. c-quater) — ma parlano di CFD di broker UE regolati in euro, non di contratti inverse marginati e regolati in cripto su sede extra-UE, che e' esattamente il caso in cui la qualificazione puo' ribaltarsi. Domanda da porre al commercialista, in questi termini: i future/opzioni BTC-ETH di Deribit (inverse, margine e regolamento in cripto, sede extra-UE) stanno in c-sexies (33%, RT Sez. V) o c-quater (26%, RT Sez. II)? E il collaterale in BTC/ETH sconta comunque il 2‰ al 31/12? 💰 Vale $258.338 → $236.310 di muro (8.5%) e ~€30/mese di versamento a 20 anni — piu' di quasi tutti gli uplift per cui in questo progetto si e' discusso se ammettere uno sleeve, e non si risolve backtestando. ⚠️ Conseguenza modellistica trovata qui: se i derivati sono c-quater sono un comparto di compensazione SEPARATO dalle cripto → il buffer di carry UNICO a 4 anni di r0807_piano_netto / r0727_tasse e' ottimistico sulla coda (non sull'aliquota). 📌 L'affrancamento al 18% (rideterminazione del costo ai valori 1/1/2025, L. 207/2024) e' scaduto il 30/11/2025: non e' una strada aperta, e a questo capitale non lo sarebbe stata. REGOLA: una fonte normativa citata in un commento di codice si verifica come un numero — questa era sbagliata da settimane in 5 file, e nessun test poteva accorgersene.

  • ⚖️ BOOK vs ETF (S&P 500 / MSCI World) — le due lenti danno risposte OPPOSTE, e la scelta robusta e' un MIX 50/50 (2026-08-07). Script r0807_asset_compare.py + r0807_best_strategy.py; diario 2026-08-07-crescita-fisco-etf-scelta.md. Book/pesi/cron/config INVARIATI. Tre cose rese comparabili: griglia (azioni su calendario con 0.0 a borsa chiusa = convenzione GTAA01; senza, Sharpe ×1.20 — lezione 25/07), fisco (book realizza ogni anno al 33%; UCITS ad accumulazione paga 26% alla vendita → le curve ETF sono valori di liquidazione: il differimento e' un vantaggio strutturale dell'ETF ed e' nel modello), bersaglio ($272.061 vale per la rendita perpetua del book e per il 33% → ricalcolato per ciascuno).

    a 15a, €5k+€500/m book S&P 500 MSCI World (proxy)
    rendita perpetua 11.67% 4.16% 3.09%
    capitale-rendita $254.524 $646.172 $869.729
    lente A (storia piena) $293.823 → 115% $204.663 → 32% $188.417 → 22%
    lente B (stessa finestra) $295.540 → 118% $343.805 → 110% $296.707 → 82%
    📌 Il risultato non e' chi vince, e' che le due lenti si contraddicono: sulla storia piena il
    book stravince, sulla stessa finestra l'S&P 500 accumula PIU' del book — il divario della
    lente A e' tutto nei crolli 2000/2008 che la strategia non ha mai vissuto.
    📌 E sulla stessa finestra il rendimento e' quasi identico — 17.4% contro 16.8%. Tutta la
    differenza e' nel RISCHIO (vol 11.0 vs 19.6%, maxDD 10.5 vs 33.7%): **il book non guadagna di
    piu', perde di meno** — conferma indipendente di cio' che il progetto scrive di TP01 dal 19/06,
    misurata contro un'alternativa vera. La rendita perpetua vive sul drawdown → 2.5× meno capitale.
    ⚠️ Un MIX esiste solo dove esistono ENTRAMBE le serie (errore commesso e corretto: la lente
    "storia piena" calcolava i bersagli del mix sull'intersezione → dichiarava 30 anni e ne usava 7).
    Percio' la scelta si giudica su UNA finestra con gli scenari espressi come spostamento del
    drift, simmetrico sui due lati. A 12 anni, quota del proprio bersaglio:
    w book base equity 30a book/2
    --- --- --- ---
    0% 68% 23% 68%
    25% 80% 41% 60%
    50% 86% 58% 48%
    75% 84% 69% 32%
    100% 75% 75% 16%
    Risposta: 50/50 — non perche' vinca (vince solo nel base) ma per il rimpianto minimo.
    ⚠️ Il criterio del solo caso peggiore non distingue 25% da 50% (27.09 vs 26.99% = pareggio
    dentro il rumore): a separarli e' il rimpianto.
    📌 L'asimmetria fra i due stress E' il risultato: quello sull'equity e' MISURATO (30 anni
    esistono: 11.3% invece di 16.5%), quello sul book e' GIUDIZIALE (meta' del drift, a mano,
    perche' 7.4 anni sono tutta la storia che ha e non c'e' nulla con cui stressarlo). Conseguenza
    brutale: col drift dimezzato il capitale-rendita del book puro passa da $254k a $771.646
    (rendita 11.67% → 3.85%).
    Perche' il mix non e' un compromesso: corr book↔S&P +0.082 (borsa aperta), +0.046 nei
    ribassi; nel 5% di giornate peggiori dell'indice (media 2.94%) il book fa 0.11% → il
    capitale-rendita del 50/50 e' $235.769, piu' basso sia del solo ETF ($311.567) sia del solo
    book ($254.524): due motori scorrelati abbassano l'asticella.
    ⚠️ MSCI World e' un PROXY 70% SPY + 30% EFA (URTH/ACWI/VT non sono nell'abbonamento dati IB);
    fra 50 e 80% di quota USA il drift si muove di 0.7pt e il Sharpe di 0.05. Il rischio di venue NON
    e' nel conto (spingerebbe ancora verso il mix) e la decisione del 26/07 tiene tutto su Deribit
    fino a $20k → questa analisi e' materiale per quella soglia, non un'indicazione di agire ora.
  • 🖥️ SIMULATORE NEL BROWSER — scripts/web/ (2026-08-07). Motore di accumulo in JavaScript (engine.js) sui ritorni veri del book esportati da export_series.py; pagine assemblate da build.py (dati iniettati da JSON, mai trascritti); test_engine.js prova che il motore riproduce r0807_growth_yearly.py e dep_necessario; smoke.js ESEGUE le pagine con un DOM finto. REGOLE (quattro errori miei, tutti trovati da un controllo e non a occhio): (a) i dati di una pagina si iniettano da un file, mai si trascrivono — due anni di una serie erano stati scritti a memoria perche' tail aveva troncato l'output; (b) un confronto punto-contro-distribuzione non prova una distorsione: "8 semi JS tutti sopra il Python, +0.75%" erano 8 estrazioni contro UN punto rumoroso → misurato bene (8 semi per parte) 0.01%, t = 0.04, ed entrambi i campionatori entro 1.7 SE dall'atteso ANALITICO; (c) le chiavi di un dizionario Python si leggono dal JSON, non si ricostruiscono ("0.0" vs String(0)="0" → pagina pubblicata rotta, e i pesi intermedi funzionavano per caso); (d) node --check valida solo la SINTASSI: una pagina puo' passarlo e morire alla prima riga. Misura che ha guidato una scelta: la banda del versamento suggerito resta ±1% da 1.200 a 3.000 percorsi → non domina il Monte Carlo ma la granularita' della bisezione (~€5) → percorsi tenuti bassi e incertezza dichiarata.

  • SOL COME TERZA GAMBA DIREZIONALE — SCARTATO (2026-08-22). scripts/research/r0822_sol_leg.py, test tests/test_sol_leg.py (5), diario 2026-08-22-sol-terza-gamba.md. Book/pesi/universo direzionale/cron INVARIATI. Nato da "hai gia' analizzato XRP/SOL/UNI?": si', ma sempre dentro panieri cross-sectional su HL — SOL e' l'unico dei tre eseguibile su Deribit e TP01/SKH01 non erano mai stati misurati su di lui. Ipotesi a priori registrata prima: diluisce (trend multi-asset 19/06, corr 0.74). Confermata. (1) Dato: storico ricostruito (SOL/USDC:USDC, 466.776 barre 5m dal 2022-03-15, 0 gap) e certificato → conferma esatta del 19/06: >1% da Coinbase nell'1.3% (2022) / 0.6% (2023) delle barre, med 8.1→3.9 bps dal 2022 al 2026; flat 1h 0.2% (ok), 5m 20.8% (run 177 barre). Da qui due lenti dichiarate prima di misurare: L-FULL 2022-03+ e L-PULITA 2024+. (2) Gambe sole (meccanismi CONGELATI): TP01 SOL Sh 0.91 / hold-out 0.24; SKH01 SOL Sh 0.51 / maxDD 40.5%. ⚠️ SKH01-V2-DD fu SELEZIONATA (23/06) sul criterio maxDD<30% (BTC 21%, ETH 27%): su un asset nuovo il criterio per cui la variante esiste fallisce → era una proprieta' dei due asset di taratura, non del meccanismo. (3) Book, 24 ancore, mediana delle differenze APPAIATE: dSharpe hold-out 0.166, >0 in 0/24 ancore in ENTRAMBE le lenti; L-PULITA dSharpe FULL 0.099 (0/24) e dCAGR 1.34pp (0/24); L-FULL dSharpe FULL +0.094 (24/24) ma dCAGR +0.10pp. Canonica: 2 gambe 1.44/9.4%/14.7% → 3 gambe 1.48/7.5%/13.6% (L-FULL), 1.54 → 1.30 (L-PULITA). (4) Il DD scende ma e' DE-LEVERING (5ª occorrenza dopo VRP-DD, TP01×DVOL, MAT01, azioni intere UCITS**):** a pari maxDD, L-PULITA k=0.886 → Sh 1.54 vs 1.30 e CAGR 14.5% vs 12.6%. L'unica lente in cui SOL aggiunge e' quella costruita sui dati che la certificazione segnala. (5) 📌 E dentro quella lente il guadagno e' UN ANNO: dSh per anno 2022 0.91 · 2023 +1.06 · 2024 0.29 · 2025 0.20 · 2026 0.22 → 4 anni su 5 negativi; la gamba SOL da sola fa Sh 1.99 / +2.65 / +0.45 / +0.17 / +1.46. Il 2023 e' la risalita post-FTX da ~$8 a ~$100: un evento, non un meccanismo. Corr col book +0.404 L-FULL / +0.561 L-PULITA — vicina allo 0.74 che boccio' il trend multi-asset, e in salita man mano che il dato migliora. (6) L'eseguibilita' NON e' il vincolo: SOL_USDC-PERPETUAL min 0.001 SOL = $0.09 contro il pavimento min_order $5 → primo candidato bocciato senza che il muro sia la taglia del conto. (7) ⚠️ EFFETTO COLLATERALE TROVATO SU ME STESSO: il "guardrail solo dati certi" NON e' codice. load_data non ha whitelist: load_data("SOL") -> FileNotFoundError funziona solo perche' il file non c'e'. Ricostruendo SOL in data/raw/sol_1h.parquet il guardrail si e' disattivato in silenzio, e quel file NON viene rinfrescato dal cron (--asset BTC ETH) → sarebbe diventato dato stantio con l'aspetto di dato attivo. Riparato con la convenzione gia' in uso (hl_/eq_/eqx_/fut_): SOL vive in data/raw/alt_sol_*.parquet, fuori dal namespace nudo; guardrail verificato ripristinato e congelato in due test (uno deriva gli asset a rischio da rebuild_history.DERIBIT_INSTR, l'altro segnala se load_data acquisisce una whitelist vera). ⚠️ La prima stesura del test elencava i prefissi a mano e bocciava eqx_, fut_, vol_term_, fundnews_ — namespace veri: l'invariante si deriva dal codice, non si elenca (stessa lezione di fee_watch il giorno prima). REGOLE: (a) un meccanismo si trasferisce a un asset nuovo coi parametri congelati, o non e' un trasferimento ma una nuova famiglia (→ study_family_honest + DSR); (b) un criterio di SELEZIONE va riprovato sull'asset nuovo — quello di SKH01 non sopravvive; (c) quando il risultato dipende dalla finestra, guardare quale finestra la CERTIFICAZIONE approva; (d) un contributo positivo si scompone per ANNO prima di crederci — 24/24 ancore positive sembravano un plateau ed erano un anno solo; (e) ricostruire dati per un'analisi puo' disattivare un guardrail che vive nell'assenza di un file: chiedersi in quale namespace atterra. ⚖️ DECISIONE DELL'OPERATORE 2026-08-22: SOL ESCLUSO. Presa dopo aver visto l'analisi completa. L'universo direzionale resta BTC/ETH, presidiato da tests/test_sol_leg.py::test_l_universo_direzionale_resta_BTC_ETH. Cosa NON si ri-discute: SOL su un book a 2 gambe, con questi dati. Cosa la riaprirebbe: ~3 anni di storia SOL certificata (dal 2024) sufficienti a rifare la misura senza la finestra 2022-23 che la certificazione segnala — cioe' non prima del 2028 — oppure un meccanismo che non sia TP01/SKH01 congelati. I parquet alt_sol_*.parquet restano su disco (precedente: i 51 HL conservati dopo il rifiuto dell'espansione XS01); non sono nel feed attivo e il cron non li rinfresca, quindi vanno rigenerati prima di ricrederci. ⚠️ Nota per il futuro-me: e' una decisione presa con l'informazione completa, non una svista. Se qualcuno propone SOL "perche' e' eseguibile su Deribit", la risposta e' che l'eseguibilita' non e' mai stata il problema — l'hold-out lo e', a 24 ancore su 24.

  • 🌊 ONDATA MULTI-AGENTE 2026-08-22 (20 filoni, branch research/wave-0822) — 0 candidati, 1 DIFETTO DI PRODUZIONE, 4 soglie pubblicate falsificate, 1 leva che nessun gate sa vedere. Diario docs/diary/2026-08-22-wave-multiagente.md; ledger per filone docs/research/RESULTS-0822.md; briefing docs/research/BRIEF-0822.md; 21 script scripts/research/r0822_*.py (15.295 righe, compilano tutti, ognuno gira da solo). Book, pesi, cron, config INVARIATI. 🚨 (1) I MONITOR FORWARD REGISTRANO UNA FRAZIONE DEL GIORNO — 4 su 6 rotti. fetch_hyperliquid e resample_tf scrivono la barra del giorno in corso; advance() la consuma e porta last_ts su di essa -> le ore restanti non entrano in nessun rendimento.

    monitor barre coincidenti min/giorno gate
    paper_statarb 0/46 4 STATARB 27/09
    paper_dvolspread 0/28 2 DVOLSPREAD 24/10
    paper_xsr 1/28 41 XSR01 23/10
    paper_portfolio 7/56 19
    paper_prevday 1259/1319 1.438
    paper_combo 7/37 1.402 — (sano per caso: aspetta una borsa)
    Il gate STATARB si ribalta su 2 criteri su 3: Sharpe registrato +1,96 contro 2,02
    ricostruito, maxDD 2,2% contro 15,3% (guardia <10%).
    La finestra NON va persa (misurato 2 volte: il feed non riscrive le barre chiuse —
    paper_prevday 1427/1488 identiche al bit dopo 62 notti; le 6 barre di statarb recuperate dopo il
    guasto EPERM 09-15/07 coincidono al bit) -> **"riparare advance() + RIGENERARE", non "riparare e
    azzerare": nessuna data di gate si sposta** (pessimista: STATARB +18g).
    Guardia raccomandata, NON cablata: ts_ultima_barra + cadenza <= mtime del file, grazia 5 min.
    O(1), segnala 5/6, tace sul sano, controllo positivo sintetico 6/6 nei due versi.
    ⚠️ monitor_health non poteva vederlo: **una serie fresca, completa e SBAGLIATA passa ogni
    controllo di freschezza**. E implausible_sharpe non e' mai stato puntato sulle serie forward.
    📌 (2) TRE SOGLIE PUBBLICATE, FALSIFICATE. (a) "XS01 serve ~$20k" (origine: "rumore di
    arrotondamento", stima a occhio del 19/06) -> nessuna soglia da min-order, haircut ~0 gia' a
    $200-600 allocati. Meccanismo: gli ordini sono due popolazioni — il ribilanciamento del
    segnale e' il 13% degli ordini ma il 75% del nozionale (ticket $13,65); la deriva del
    vol-target e' l'87% degli ordini ma il 25% (ticket $0,64) e il pavimento la taglia gratis.
    Contare gli ordini da' 16%, contare il nozionale da' 75%. ⚠️ **Il "$20k di XS01" e il "$20k
    della DECISIONE DI VENUE" sono due cose diverse conflate in questo file: il primo cade, il secondo
    REGGE** (e' sull'asse della rovina, non dell'eseguibilita'). (b) "slippage = rischio #1 di XSR01"
    -> refutato con margine 21x. (c) "BTC opzioni fuori a $3.000" -> misurato sulla famiglia
    inverse, che un conto USDC non puo' marginare; la famiglia USDC-lineare ha lotti **10x piu'
    piccoli** (ETH_USDC $242, BTC_USDC $772 contro $7.744). ~~Il muro resta **per il prezzo
    del lotto**.~~ 🚨 **CORRETTO 2026-08-23 (§46): quelle cifre sono il COLLATERALE PER VENDERE.
    COMPRARE un'opzione costa il PREMIO, non il nozionale** — min_trade_amount 0,01 su tutte le
    343 put BTC_USDC ( verificato al venue) e il premio del lotto minimo di una put deep-OTM va da
    $0,00 a pochi dollarisul lato LONG il muro di capitale non esiste (e la regola *niente
    short-vol da modello* non ha mai avuto bisogno di un muro di taglia per reggere).
    📌 Il muro vero sul lato long e' un altro, ed e' STRUTTURALE: il tick da 5,00 USDC (
    verificato, tick_size = 5.0 su tutte) — **piu' l'opzione e' deep-OTM, cioe' economica, piu' il
    tick domina**: una put marcata 0,82 USDC non e' quotabile sotto 5, cioe' un pavimento di prezzo
    del 6x sulle ali lontane, che nessun capitale aggira.
    Parametri veri Hyperliquid: min order $10 (non $5), taker 4,50 bps (non 5,0).
    📌 (3) LA LEVA E' L'UNICA VARIABILE CHE NESSUN GATE DEL PROGETTO SA VEDERE. Lo Sharpe e'
    invariante alla scala (1,31 a ogni cella del knob) -> deflated_sharpe e marginal_vs_tp01
    non falliscono, non la vedono. Il libro gira al 7% di Kelly e raccoglie il 15% della
    crescita massima in log; il gradino eseguibile 1,00x->1,25-1,50x vale 14,7a -> 12,9-11,6a al
    capitale-rendita (€500/m, netto fisco). **Lo scettico conferma il numero e toglie la sua condizione
    bloccante**: sotto la lente wick accoppiata il maxDD prende un **ricarico moltiplicativo costante
    ~3,5%**, non un'amplificazione (il maxDD e' multi-giorno, il wick e' di un giorno).
    Il gradino resta NON autorizzato: cade 1 riserva su 3; restano il drift stimato su 7,4 anni
    (k* e' lineare nel suo errore) e la coda assente dal dataset (un giorno 10%/anno -> k* 2x).
    ⚠️ Ma la lezione del 25/07 e' vera e NON si trasferisce: su una regola a UN giorno
    (daily-loss, stop di conto) close-only e' esattamente cieca — 0,00 breach/anno contro 0,40-1,21
    veri (rapporto INF). Sul canale prop/funded la lente accoppiata resta OBBLIGATORIA.
    ⚠️ target_vol e k NON sono la stessa leva: target_vol scala il 75% del libro e lascia
    fermo il 25% (a tv=30% il libro e' 82/18, a 60% 90/10) -> e' anche un tilt di pesi, e
    fallisce weights_tilt_null. La strada pulita per un cambio di SCALA e' il cap di config.
    📌 La vol realizzata di TP01 a target_vol=20% e' 12,14%, scomposto: 20% x 0,682 x 0,890,
    dove lo 0,682 sono due meta' quasi uguali (flat nel 44,3% delle barre e convinzione
    parziale) -> "TP01 e' long-flat" spiega meta'; e alzare target_vol **aumenta la size proprio
    nei giorni in cui il segnale e' piu' debole**. Il x0,890 e' diversificazione, non un difetto.
    ⚠️ XS01 dichiara lo stesso 20% e ne realizza 20,59%: vale per TP01, non per il libro. Nessun
    numero pubblicato cambia (sono tutti sulla serie realizzata); sbaglia chi legge l'etichetta
    (attribuirebbe a TP01 l'89% del rischio invece del 73%).
    📌 (4) PROP/FUNDED — l'ipotesi centrale e' falsificata, e per la ragione teorica giusta.
    Riallocare per la barriera invece che per lo Sharpe vale +0,016 di J (il 4%): il conto del
    gambler's ruin lo prevedeva (la vol sparisce, il contenuto sta nella LEVA). Cio' che vale e'
    mettere XS01 su un conto funded: +0,400 (J 0,335 -> 0,738; P(pass) 38,6% -> 82,2%). Leva ottima
    0,75x HYRO / 1,00x FTMO, e **la barriera piu' larga alza l'ottimo: il vincolo e' la regola di
    DD, non il libro**; la leva alta non compra probabilita', compra fretta. Il **75/25 del libro
    live non e' la ripartizione giusta per un conto a barriera** (sul 2019+ che contiene il 2022
    l'ottimo e' 38/62 @0,50x). Il null dei tilt dice che il PUNTO non conta: il massimo di 200
    pesi casuali (0,739) eguaglia l'argmax (0,738) — conta stare nella regione diversificata.
    🚨 **Il numero da citare e' LA BANDA: P(>=50/g) da €600 in 36 mesi = 42% al drift pieno · 7,7% allo
    stress moderato · 0,7% a quello severo** (e li' e' peggio del libro live), perche' **tutto il
    vantaggio poggia sul drift di XS01 misurato sulla sua finestra di scoperta**. Gate proposto: non
    aprire un funded su questa allocazione prima che XS01 abbia una finestra fuori dal 2024-2026.
    ⚠️ Distorsioni dichiarate e non rimosse: banda d'ancora non girata sotto quella lente (l'ottimo
    gira sull'ancora canonica e si appoggia a **SKH01, che ha la fortuna d'ancora piu' grande da
    restituire**); e la sotto-pesatura di **TP01, lo sleeve difensivo, e' misurata su un campione senza
    sinistro** — su una barriera assorbente quella scommessa si paga una volta sola.
    📌 (5) LO SLIPPAGE DEL LIBRO LIVE, misurato per la prima volta: non c'e' a questa taglia.
    I backtest a 10 bps RT restano conservativi di ~1,5 bps/lato (fee vera 7 bps RT); estremi
    avversi 1/18 contro 4,7 attesi. Prova diretta: un fill ha preso il **21,9% del volume della sua
    barra 5m** e quella barra ha avuto un range di 1,08 bps. **Fee sul NASTRO: 5,00 bps/lato
    prima del 2026-08-01 e 3,50 dopo, 16/16 esatti** = conferma indipendente di fee_watch.
    🚨 Ma la misura ha una DATA DI SCADENZA: la partecipazione scala lineare -> quel 22% diventa
    172% di una barra 5m a $5.000 e 687% a $20.000. Va rifatta a ogni salto di taglia.
    ⚠️ Due difetti del dato trovati prima di misurare: ts_utc in book_executions.jsonl **non e'
    l'ora del fill** (18/18 = 00:00:00; l'ora vera sta solo in logs/cron_book.log); e il feed
    certificato e' l'INVERSE mentre il libro trada il LINEARE USDC (4ª occorrenza dello
    schema fee_watch: misurare li' avrebbe misurato la base).
    📌 (6) IL f=0,73 DI VRP01 SCOMPOSTO — il 42% e' STRUTTURA A TERMINE, solo il 25% e' skew
    (30% spread, 2% fit). Il sleeve prezza un'opzione a 7 GIORNI col DVOL a 30 GIORNI, che nel 90%
    delle ore sta ~3 punti di vol sopra l'ATM a 7g -> sovrapprezza entrambe le gambe. Il
    "+0,8pp sulla gamba corta" del 30/07 — che faceva sembrare corretta la gamba venduta — e' la
    cancellazione di due errori da ~3pp. ⚠️ E la regola per prenderlo era gia' scritta il 03/07
    ("riprezzare term-structure-consistent prima di credere a un numero da struttura BS-flat") **e non
    e' stata applicata alla misura del 30/07**. Verso: f_term va da 0,83 (IV-rank basso) a
    0,93 (alto) e supera 1 in backwardation mentre f_skew resta piatto -> **la parte maggiore
    del difetto si annulla proprio dove il gate fa tradare il sleeve**, quindi f=0,73 e' plausibilmente
    conservativo li'. Non misurato (0/22 ingressi passano il gate) e in un crash i due pezzi vanno
    in direzioni contrarie. VRP_CFG["f"] NON cambiato. Replica indipendente del f: 0,714.
    📌 (7) CHIUSURE DI FAMIGLIA. Il filone funding si chiude sul QUARTO lato (affollamento):
    su 53.430 ore / 3 anni non predice ne' direzione ne' volatilita'. E i futures datati **non sono
    un quinto lato**: il loro basis E' il funding del perp (+7,33% implicito contro +6,48%
    realizzato; premio incassabile +0,85%/anno con IC95 che contiene lo zero). **La mean-reversion
    non risorge** sotto due conditioner mai provati (volume, shock 3σ): la selezione in-sample sceglie
    il ramo di continuazione in entrambi. Scartati anche: adaptive-horizon (il "vincitore adattivo"
    ha lookback costante, corr 1,000), dealer-gamma (BTC non separa, ETH separa al rovescio;
    ⚠️ e qui una REGOLA MIA, pubblicata la sera stessa e RITIRATA poche ore dopo: avevo scritto che
    dealer_net_gamma del dataset ereditato "e' il GEX col SEGNO INVERTITO" (corr 0,95). **FALSO, e
    la fonte gira su questa stessa VPS:** /opt/docker/cerbero-mcp/src/cerbero_mcp/common/options.py:11-14
    dichiara la convenzione"i dealer sono SHORT calls (le vendono al retail) e LONG puts" — e
    dealer_gamma_profile:138-140 la implementa (call_dealer_gamma -= contrib / `put_dealer_gamma
    += contrib`). Non e' un segno sbagliato: e' un'assunzione di posizionamento dichiarata, diversa
    da quella del GEX standard, e il default top_n_strikes=50 spiega anche il coefficiente 0,7 e
    l'offset che avevo attribuito a "non-portabilita'". Il verdetto SCARTATO regge; cade la regola
    che le prossime ondate avrebbero ereditato al contrario. **REGOLA VERA: prima di dichiarare che un
    campo di un dataset e' sbagliato, aprire il codice che lo produce** — qui erano due comandi, e la
    correlazione a 0,95 con la ricostruzione "standard" era esattamente cio' che una convenzione
    diversa deve produrre. liquidation_*_risk e' invece **una sola categoria in 17.229/17.229
    righe**, e quello e' confermato.
    Scartati anche: oi-pin (il max-pain non batte mai, 0/24, la media a 7 giorni dello spot),
    term-structure (termometro contemporaneo), skew direzionale (il prezzo muove lo skew,
    t 3,1-9,4 su 8/8, non il contrario), ortho-screen 7/7, alt-options, xs-lite, vrp-quote-vere.
    ⚠️ La catena ereditata da bite ha 74-75 giorni utili, non 3,7 mesi: prima del 2026-06-09
    raccoglieva una sola scadenza per giro (due agenti indipendenti, 74 e 75).
    📌 (8) REGOLE NUOVE. (a) L'open interest NON misura la negoziabilita' — su Deribit USDC sono
    quasi anti-correlati (rho di rango 0,77): SOL_USDC e' 1ª per OI e **ultima per quote a due
    lati (9%)**, BTC_USDC ha 5 strumenti con OI>=100 e il 93% dei put quotati (e sul short leg
    di SOL il miglior bid sta a UN tick: vendere li' significa pagare $27 per aprire un credit
    spread). (b) Il deflated-Sharpe va calcolato DI SCREEN, non solo di famiglia: su 168 trial il
    massimo atteso dal puro rumore e' Sharpe 1,572, sopra il soffitto direzionale (~1,3) ->
    uno screen largo su BTC/ETH direzionale non puo' passare il proprio gate, per aritmetica.
    🚨 QUESTO ARGOMENTO E' REFUTATO DUE VOLTE, per due strade indipendenti, e NON va ereditato:
    (i) la stessa griglia dichiarata come 7 famiglie da 24 da' 1,15, sotto il soffitto — il
    verdetto si ribalta sulla partizione (ondata 2, §24); (ii) il soffitto non e' ~1,3: la
    stessa ondata pubblica un lookback costante a 1,639 e la cella PREVDAY al buio a 1,621,
    stessa coppia e stessa lente netta-fee (§23, §54). «Soffitto» sta per tre cose diverse e il
    registro usava la piu' bassa citandola come la piu' alta.
    (c) Un placebo si controlla per BILANCIAMENTO DEL SEGNO prima di usarlo (un null che concorda
    col segnale nel 14% dei casi non e' un null, e' la strategia invertita: fabbrica celle
    "significative"). (d) **Il null del de-levering e' DEGENERE quando la variante e' una
    ri-scalatura** (sh(k*base) === sh(base)): serve iso-peso sullo Sharpe. (e) **Un gate che
    stampa None va verificato prima di dichiararlo "non girato"**. (f) **Su una finestra interamente
    post-hold-out marginal_vs_tp01 non puo' dare ADDS per costruzione** — un NEUTRAL li' non e' un
    giudizio. (g) Un confronto appaiato deve ereditare TUTTI i parametri della riga in cui compare.
    REGOLA RITIRATA, pubblicata poche ore prima nella stessa ondata: *"su equity a gradino un
    overlay giornaliero e' non-causale"* — falso su questo motore: backtest_signals contabilizza
    al giorno d'INGRESSO in 291/293 trade e la "riparazione" e' un no-op bit-exact; il
    "+0,04 fantasma" era la differenza fra due varianti entrambe causali, e quella scartata era la
    migliore sull'hold-out. *Il costo di una regola derivata da un difetto inesistente e' gia'
    stato pagato.*
    📌 **(9) Cosa NON e' piu' il vincolo: TRE volte in questa ondata l'eseguibilita' a $600 non ha
    bocciato niente** (haircut 0,00-0,01; lotti $7-242; margine ~$148). Dopo due mesi in cui il muro
    era sempre il capitale, adesso muoiono tutti sull'edge.
    ⚠️ (10) FATTO OPERATIVO: il cron gira dal WORKING TREE. Con un branch di ricerca attivo, il
    cron esegue quel branch. Durante l'ondata il diff vs main toccava solo scripts/research/ e
    docs/research/ (verificato) -> produzione identica; ed e' il motivo per cui **nessuna riparazione
    e' stata applicata**: sarebbe andata live alle 00:30 senza una decisione dell'operatore.
    🗂️ Dataset nuovo in eredita': 30/30 futures trimestrali scaduti Deribit ricostruiti
    (get_instruments?expired=true ne ritorna 1, ma i nomi sono deterministici e
    get_tradingview_chart_data serve la storia di un contratto scaduto): **BTC 240.150 barre orarie /
    ETH 233.334, dal 2018-09, col deleveraging 2022 dentro** — cioe' **la coda che a CC01 mancava per
    costruzione**. Cross-check col forward implicito nella catena opzioni: mediana 0,6 bps.
  • 🌊 SECONDA ONDATA 2026-08-22 sera (9 filoni, research/wave-0822) — 0 candidati, 1 gate pre-registrato SOSTITUITO, il numero funded ridimensionato di 5x, e un difetto strutturale del deflated-Sharpe misurato da TRE agenti indipendenti. Diario docs/diary/2026-08-22-wave2-xs01-funded.md; registro docs/research/RESULTS-0822.md §21-29. Libro, pesi, cron, config INVARIATI. (1) XS01 REGGE FUORI DALLA SUA FINESTRA DI SCOPERTA — ED E' PIU' FORTE LI'. La finestra c'era gia': stessi 19 ticker su Binance spot 2021-2023, che contiene LUNA e FTX, meccanismo congelato. Mediana di fase +1,12 fuori campione contro +0,37 dentro; differenza appaiata +0,668, positiva in 10/10 fasi; p=0,013 contro permutazione a fee zero; sopravvive a 30 bps/lato. L'obiezione "Binance non e' la verita'" e' stata MISURATA, non aggirata: quella regola riguarda l'ancoraggio di prezzo, non un ranking cross-sezionale, e lo scarto USDT e' un fattore comune che sparisce nello z-score — stesso sleeve sui due venue corr 0,9991. Null "universo dove non dovrebbe funzionare" (11 settoriali SPDR 1998+): 0,45, 0/10 fasi3ª conferma indipendente che il cross-sectional e' crypto-specifico. ⚠️ Ma tre correzioni vanno nel verso opposto: maxDD standalone 10,8% → 21%; deflated-Sharpe FAIL 0,342; 32% dell'universo non testabile (19 gambe 1,31 contro 13 gambe 0,54, stessa finestra e venue). Verdetto LEAD, non promozione. (2) Il falsificatore che l'autore aveva nominato CONTRO SE STESSO — eseguito, e non falsifica. La validazione di venue girava solo sul 2024+, cioe' senza il depeg USDT che il fuori campione contiene. Soglia dichiarata da lui (corr ≥ 0,99): corr mediana 0,9992, minima 0,9921, dSharpe appaiato 0,000, titolo da +1,12 a +1,11; sui 734 ribilanciamenti solo 10 cambiano una gamba su cinque e ZERO dentro il depeg. Il punto di metodo: la divergenza va SCOMPOSTA — la comune arriva a 39 bps ed e' quella che lo z-score annulla, la idiosincratica (l'unica che cambia il ranking) sale solo da 2,0 a 3,6 bps mediani; riportare solo la prima da' la risposta rassicurante e sbagliata. 🚨 E il caso peggiore del campione non e' il depeg: e' il 2025-10-10 (cascata di liquidazioni /USDT, INJ 1.981 bps mentre BTC/ETH stanno a 21) → il meccanismo temuto e' REALE, e' solo caduto nella finestra di scoperta. 🚨 (3) IL NUMERO FUNDED SI RIDIMENSIONA DI 5x, E IL COLPEVOLE NON E' LA FINESTRA. Decomposizione a un grado di liberta' per volta (riproduzione esatta cifra per cifra dei numeri del mattino + 3 controlli bit-exact a 0,0):

    passo J Δ
    il pubblicato (HL, 19 gambe, finestra di scoperta) 0,739
    → venue Binance, date allineate 0,732 0,006
    13 gambe 0,426 0,307
    → pannello lungo 0,459 +0,034
    fuori campione 2021-2023 0,520 +0,061
    Il 42% del numero pubblicato sta nelle 6 gambe che fuori campione non esistono (ARB OP SUI APT
    SEI TIA) — **e quelle 6 entrarono nell'universo nel 2026-06 guardando la liquidita' HL del 2024+,
    cioe' dentro la finestra di scoperta**. La finestra, da sola, migliora; allargare l'universo man
    mano che le gambe nascono non recupera i 0,307.
    ⚠️ Errore di metodo catturato prima di pubblicare: la prima stesura dava al passo venue 0,254
    ("Binance costa un quarto di J"). Era FASE, non venuexsec_engine ribilancia sulla parita'
    dell'indice di pannello, e **due pannelli che iniziano a date diverse ribilanciano in giorni di
    calendario diversi**. Allineati, il venue vale 0,006.
    NUMERO DA CITARE: P(≥50 €/g) da €600 in 36 mesi = 7,8% [7,29,1%], P(zero) 25,5% (non 42%);
    6,6% se la firm non lista gli alt; 4,3% per il libro live. **Il peso 0,50 non sopravvive; la
    REGIONE [25%, 38%] e' entro il 3% dell'ottimo su tutte e tre le finestre.** Stress ora ancorati al
    misurato: XS ×0,00 +0,041 → **XS01 come pura DECORRELAZIONE vale +0,04, tutto il resto e' il
    suo drift.**
    📌 GATE PROP-01 — SOSTITUISCE l'attesa di anni, che e' CHIUSA: **(a) LISTINO — verifica a €0,
    BLOCCANTE prima di ogni spesa:** ≥10 delle 13 gambe negoziabili con short (sotto 10 il
    meccanismo congelato non ribilancia affatto); FAIL → si decide sulla riga senza XS01. *Stessa
    classe dell'errore GTAA01/PRIIPs, per cui la regola e' gia' scritta.* (b) banda d'ancora di
    SKH01 sotto la lente prop, 2026-10-31, PASS se > +0,05 (atteso PASS, dichiarato prima).
    (c) un'eval HYRO $100k costa $579 su un conto di $635 = il 91%.
    ⚠️ (4) I DUE AFFINAMENTI DI XS01 DEL 2026-06-19 NON SI REPLICANO FUORI CAMPIONE (misurato da
    due agenti indipendenti): il blend [30,90] e' PEGGIO del solo L=30 (+1,12 vs +1,28) e il
    gate di dispersione p30 vale ZERO (+1,12 con e senza) — mentre dentro la finestra di scoperta
    il gate vale eccome (+0,37 contro 0,03). Il secondo agente lo ritrova per un'altra strada: l'unica
    correlazione sotto soglia del suo test e' causata dal gate (spento, 0,9674 → 0,9977), perche'
    e' binario e pochi bps lo fanno cadere ai due lati. **Cio' che sopravvive e' il meccanismo
    cross-sectional NUDO.** ⚠️ NON e' un argomento per cambiarli — cambiarli guardando questo
    risultato sarebbe la stessa selezione spostata di finestra — **e' un argomento per non attribuire
    loro il valore che questa memoria gli attribuisce.**
    (5) L'ALLARME SUL PESO DI TP01 E' FALSIFICATO NEL VERSO (l'agente aveva registrato nel
    docstring, prima di misurare, che si aspettava di confermarlo): **TP01 ~0,375 e' l'argmax sia
    sulla finestra che contiene il 2022 sia su quella che non lo contiene**, e nel sinistro il libro con
    meno TP01 fa meglio — TP01 va flat mentre SKH01 si gira short e guadagna; test dei segni
    12/12 (p=0,0005) e 8/8 sul solo pre-2024. **Null del de-levering, 7ª occorrenza, in veste
    nuova** ("protezione dal crash"): a leva comune TP01 protegge davvero, ma **a ISO-SOPRAVVIVENZA meno
    TP01 paga di piu'** ($4.490 → $2.119, monotono). Tre collaterali: (i) *"2024-2026 non contiene
    un crash"* e' falsa nella forma (buy&hold 60% di DD); manca la taglia (~2,3x sulla coda) →
    la domanda giusta e' "e se ne arriva uno due volte piu' grande"; (ii) alle leve funded **il
    2022 non era una minaccia** (min equity 1,4/2,4% contro barriera 6%): **cio' che uccide un conto
    a barriera e' la regola a UN GIORNO su una giornata qualunque**; (iii) il rischio vero
    dell'ottimo e' XS01, non TP01. Il 75/25 live e' fuori dalla regione di compromesso del funded
    — coerente col fatto gia' scritto il 25/07: *canale funded e libro proprietario vogliono libri
    diversi*.
    (6) ORIZZONTE ADATTIVO — CHIUSO DEFINITIVAMENTE. Il falsificatore e' stato eseguito coi
    rilevatori che nominava (BOCPD Adams & MacKay + optimal partitioning causale) e **questa
    volta ha avuto POTENZA**: 68/96 celle davvero adattive (contro 0 del primo tentativo, dove il
    "vincitore adattivo" aveva lookback costante). Con potenza: 0/68 su entrambe le condizioni
    dichiarate, corr→TP01 minimo 0,754 (soglia 0,60). 📌 **La decomposizione E' il risultato:
    l'adattivita' spiega il 7% del vantaggio su TP01** (miglior costante +0,326, adattivo +0,305) → il
    100% e' "un orizzonte piu' corto", non "adattarlo". E il miglior costante non si propone: il
    salto fra L adiacenti e' +0,190 = il 58% del vantaggio — max-of-24 su un crinale di rumore.
    📌 Prova di IDENTITA' invece di diagnostica (controllo riusabile in ogni famiglia con un
    parametro clippato): invece di "questa cella sta al bordo", la sua serie e quella del costante
    coincidono a **max Δ = 0 su n=2719**.
    (7) MAKER — il segno dipende da < contro <=. Differenziale maker/taker: tetto **$2,96/anno
    a $635** (replica indipendente della curva 26/07 al terzo decimale). Il costo del non-fill lo mangia
    interamente gia' alla condizione di riempimento piu' generosa fisicamente difendibile: se una
    barra che apre esattamente al nostro prezzo e da li' se ne va conta come fill, resta +0,31 bps; se
    non conta (e non conta: a quel prezzo non e' stato scambiato niente dopo l'arrivo dell'ordine, e
    un passivo sta dietro a tutta la coda), resta 0,47. **Non esiste un q positivo di
    pareggio**; IC95 contiene lo zero in 10 celle su 10. 📌 **La firma della troncatura, vista
    dall'altra parte: il passivo vince sul 92-98% degli ordini e perde sulla media** (5 ordini su 1535
    fanno il 42% del danno) — *una politica che vince quasi sempre e perde sulla media si giudica
    sulla media*. Placebo a ore casuali girato: la selezione avversa non e' "il libro trada nei
    momenti brutti", e' strutturale all'esecuzione passiva. ⚠️ Osservazione che riapriva la domanda:
    il netting su strumento unico (che uccise T1 il 26/07) **non si applica all'ordine NETTO di
    ribilanciamento**, che e' uno solo.
    (8) SUPERFICIE DI VOLATILITA' — il lato relative-value e' CHIUSO. Censimento (non selezione)
    su 1,24 M quote a due lati: 0 violazioni di monotonia su 1,11 M, **1 di convessita' su 1,03
    M** che vale $0,00 ed e' sparita l'ora dopo. residuo mediano 0,125-0,200 pt-vol contro
    mezzo spread 0,861-1,208, e sotto il tick nel 96% dei casi. 📌 **IL MECCANISMO: residuo
    cresce MONOTONAMENTE col largo del mercato** (0,080 pt a spread 2,6% → 0,255 a spread 50%) →
    l'incoerenza al mid E' la larghezza del mercato guardata attraverso il mid, non un errore di
    prezzo — e questo uccide il controfattuale USDC che l'agente stesso aveva costruito (restringendo
    alla superficie gia' quotata stretta: 0 su 158.718). Reversione misurata: mezza-vita 11-12 h,
    corr(t,t+1) +0,94 → il residuo e' la forma dello smile. Controlli positivi **3/3 in entrambi i
    versi** — un rilevatore che trova ~0 e non e' validato e' indistinguibile da uno rotto.
    ⚠️ **(9) BIN-FREQ (il binario di frequenza su SKH01) — LEAD: la direzione e' reale, la TAGLIA e'
    selezione.** Argmax +0,112 in 23/23 ancore, ma mediana di famiglia +0,007 con 39/72 celle
    positive = monetina: l'argmax vale 16× la mediana, punta e non plateau. Direzione
    solidissima (0/72 sul segno inverso; trasferisce a SKH01_V1). Criterio a 4 gambe: 3 FAIL, e
    la taglia e' €0,0113/giorno. Due implementazioni difendibili della stessa regola, d'accordo sul
    97,6% dei trade, danno +0,066 contro +0,080 → **il 21% dell'effetto sta in come si riempie il
    warm-up**. 📌 Riapertura pre-registrata: non una data ma una SOGLIA DI CAPITALE ($5.600 alla
    stima della cella, $53.000 a quella onesta di famiglia) — perche' cio' che fallisce e' il
    rapporto fra un costo fisso e un beneficio proporzionale, e nessun forward a 6 mesi puo'
    misurare 0,07 di Sharpe (SE≈1,4).
    🚨 **(10) IL FILO DELLA GIORNATA: deflated_sharpe NON HA UNA REGIONE UTILE IN MEZZO — misurato da
    TRE agenti indipendenti, e TRE gate pre-registrati ci poggiano sopra** (XSR01 23/10, DVOLSPREAD
    24/10, 22/12). altlib.deflated_sharpe calcola sr0 = sd(Sharpe dei trial) × mult(N): dipende
    dalla VARIANZA della griglia, non solo da N. (a) VOL-SIZE lo dichiara VACUO (1,000 anche
    per il baseline). (b) BOCPD lo misura dall'altro capo: 0,998 PASS dentro la famiglia omogenea
    0,555 FAIL con l'sr0 di screen, TP01 compreso — *"gonfiare N col padding alza N e non la
    varianza"*. (c) Il critico trova che l'1,572 di ORTHO-SCREEN implica sd≈0,58 e che **le
    stesse 168 celle dichiarate come 7 famiglie da 24 danno 1,15**, sotto il soffitto ~1,3: il verdetto
    "uno screen largo non puo' passare il proprio gate per aritmetica" **si ribalta senza toccare un
    dato**, e la cura che suggerisce (famiglie piu' piccole) e' la manovra proibita il 30/07.
    (d) BIN-FREQ chiude il cerchio dall'alto: su una famiglia binaria il DSR **riacquista
    potenza** (0,977 contro baseline 0,834) perche' le sue celle scartano insiemi di trade molto
    diversi — non e' il candidato a essere piu' solido, e' la famiglia a essere piu' larga.
    REGOLA: non basta contare i trial di screen, serve la VARIANZA di screen — e **la stessa griglia
    da' verdetti opposti a seconda di come la si partiziona**, il che rende la scelta della partizione
    un secondo posto dove barare e' indolore e invisibile.
    ⚠️ (11) REGOLA MIA PUBBLICATA E RITIRATA IN GIORNATA — vedi il ritiro nel bullet dell'ondata 1:
    dealer_net_gamma non e' il GEX col segno invertito, e' una convenzione dichiarata nel
    sorgente che gira su questa stessa VPS. **REGOLA: prima di dichiarare che un campo di un dataset e'
    sbagliato, aprire il codice che lo produce.**
    📌 (12) ALTRE REGOLE NUOVE. (a) **Una divergenza fra due fonti di prezzo si scompone in COMUNE e
    IDIOSINCRATICA prima di giudicarla**: le due rispondono a domande diverse e la prima da' sempre la
    risposta rassicurante. (b) **Due pannelli che iniziano a date diverse ribilanciano in giorni di
    calendario diversi**: un confronto di venue non allineato misura la fase, non il venue (qui
    0,254 contro 0,006, fattore 42). (c) **Un null di permutazione puo' avere mediana diversa da
    zero per ragioni strutturali** — scartare a caso il 40% dei trade danneggia perche' lo Sharpe va con
    √(scommesse/anno) (misurato 0,883 contro 0,861 previsti): il null resta valido e piu' severo, ma
    risponde a "batte una selezione casuale?", non a "batte il non filtrare?". (d) **Un
    contro-fattuale costruito sui mid di un mercato largo non descrive un mercato stretto**: prendere il
    mid a spread 50% e fingere di quotarlo al 2,6% fabbrica opportunita' che spariscono restringendo il
    campione a cio' che e' gia' quotato stretto. (e) **Un git add -A durante un'ondata cattura il
    lavoro IN CORSO degli agenti** (successo qui: un commit conteneva una versione intermedia e
    sbagliata di uno script poi corretto).
    📌 **(13) E LA RISPOSTA ONESTA AL MANDATO, che al critico era stato chiesto di dare se vera:
    NESSUNA misura di ricerca di questa giornata batte "versare".** L'effetto piu' grande misurato oggi
    vale €0,0113/giorno; versare €500/mese vale ~1456× quello. **La verifica che costa meno di
    tutte non e' ricerca: leggere il listino di due prop firm** — l'intero risultato di testa poggiava
    su un assunto scritto in un commento a riga 100. *La ricerca ha smesso di essere il vincolo
    binding il 26/07, e due ondate da 29 filoni lo hanno CONFERMATO invece che ribaltarlo.*
  • 🌊 TERZA ONDATA 2026-08-22 notte (4 filoni) — DUE GATE D'ATTESA ELIMINATI, 2 difetti strutturali trovati, 0 candidati. Diario docs/diary/2026-08-22-wave2-xs01-funded.md; registro docs/research/RESULTS-0822.md §30-33. Libro, pesi, cron, config INVARIATI. (1) GATE PROP-01 gamba (a) — LISTINO: PASS 13/13. La verifica a €0 che il hook e il critico avevano indicato come il vero vincolo. 📌 Metodo: non leggere il sito della firm, interrogare il VENUE su cui la firm esegue. HyroTrader esegue su Bybit; api.bybit.com/v5/market/instruments-info?category=linear (pubblico, tokenless, 833 strumenti) → 13/13 gambe U13 Trading, LinearPerpetual, min notional $5, leva 50-150x; 6/6 anche le gambe non testabili. Lo short e' STRUTTURALE su un perp, non un permesso. ⚠️ Non prova che la firm non abbia una propria lista ristretta: la sua pagina dichiara "700+ pairs" su un venue che ne ha 833 (coerente, ma e' la sua dichiarazione) → si chiude con una domanda al supporto, non con un dataset. VALIDAZIONE del modello: la firm dichiara daily DD 4% · max loss 6%, e r0725_hyro.py:48-49 usa gia' EV_TARGET,EV_DD,EV_DL = 0.10,0.06,0.04le regole modellate dal 25/07 sono quelle vere. 🚨 CORREZIONE ECONOMICA: la quota d'ingresso NON e' un costo affondato — e' un "Refundable Challenge Deposit, returned in full alongside your first funded payout". Il progetto l'ha sempre modellata come spesa persa. Resta vero che immobilizza il 91% del conto ($579 su $635), non che lo brucia: si perde solo nel ramo senza payout. E' una struttura a OPZIONE, non una fee → l'EV del biglietto va rifatto (gamba (c) del gate). Qualita' delle fonti dichiarata: listino primario e misurato; regole DD primarie dichiarative; rimborsabilita' dichiarativa + secondarie concordi, non misurata. (2) GATE PROP-01 gamba (b) — chiusa OGGI invece che il 2026-10-31: PASS 23/23. Delta appaiato mediano +0,1162 [p10-p90 +0,087/+0,152], 23/23 offset e 230/230 celle congiunte positive (soglia +0,05), su griglia congiunta PIENA 23 offset × 10 fasi — non un campionamento e non una somma di marginali. Riproduzione 7/7 esatta, bit-exact 3/3 a 0,0. 📌 La data non aspettava un dato: aspettava che qualcuno misurasse il COSTO (0,6 s per offset; i "~9 min" erano di una computazione che la misura non usa). Secondo gate d'attesa eliminato in una sera, per la stessa ragione del primo. 🚨 Ma il numero operativo scende ANCORA: P(≥50 €/g) da €600 in 36 mesi = 4,4% [2,58,2%], P(zero) 35,3% (l'offset canonico era al 91° pctl; all'ancora canonica la macchina ridice 7,7% → e' fortuna d'ancora, non disaccordo). Traiettoria del numero in una giornata: 42% → 7,8% → 4,4%. 📌 E la distorsione dichiarata DUE VOLTE e mai rimossa — "l'ottimo si appoggia a SKH01, lo sleeve con la fortuna d'ancora piu' grande" — e' MISURATA E REFUTATA nella forma forte: a 38/25/38 SKH01 sta allo stesso peso del LIVE, la sua ancora si cancella nella differenza appaiata, e li' il delta e' il piu' alto dei tre (+0,120) con la banda piu' stretta. L'ampiezza della banda scala col differenziale di peso su SKH01cio' che paga e' XS01, non un sovrappeso dello sleeve fragile. ⚠️ Due avvertenze: (i) il gate e' su una DIFFERENZA, il numero operativo e' un LIVELLO — nella prima l'ancora si cancella in parte, nel secondo per niente: passano insieme e si muovono diversamente (33% contro 44%). Un gate superato non e' un numero confermato. (ii) il surrogato del 22/08 era finito vicino al vero per la cancellazione di due asimmetrie opposte: il numero era giusto, il metodo no. Smentitore residuo fuori perimetro: l'ancora giornaliera di TP01 (24 ore, canonica 00:00 UTC = la piu' fortunata delle 24) non e' toccata da questa misura. 📌 (3) GATE-RECON — il difetto advance() ribalta UN gate su tre, e in quello due criteri su tre. Audit di sola lettura provata (md5+mtime di ogni data/paper_* invariati). STATARB 27/09 — riparata: RITIRO · attuale: CANDIDATO AL DEPLOY (Sharpe +1,96 → 2,02, maxDD 2,24% → 15,19%); XSR01 e DVOLSPREAD danno lo stesso verdetto in entrambe le lenti. La premessa "rigenerare non perde la finestra" e' ora CONFERMATA PER VIA DIRETTA: data/_feed_backup/*.prebuild.bak conserva il vintage pre-riscrittura → 0 barre chiuse cambiate su 1.761.259; l'unica riga che cambia per file e' l'ultima del vintage, che era aperta = il difetto stesso, in chiaro. ⚠️ Limite: hl_*_1d e dvol_* non hanno vintage su disco → per XSR01/DVOLSPREAD l'evidenza resta indiretta. 🚨 Il veto d'integrita' di DVOLSPREAD NON scatta: 28 attive/28 = 100%. Una serie che registra 2 minuti di mercato al giorno passa al 100% un veto progettato apposta per non far decidere su dati mancanti — non e' taratura: il veto conta se il DVOL c'era, non quanto dura la barra su cui c'era (assi ortogonali); la stessa soglia 0,80 sulla quota di barre chiuse leggerebbe 0%. Variante nuova: una barra presente non e' una giornata presente. 🚨 Il caso peggiore NON e' quello coi numeri piu' assurdi: XSR01 sbaglia di ×6,6 e DVOLSPREAD di ×3,0 senza cambiare verdetto; STATARB ha |Sharpe| quasi identico (1,96 contro 2,02) e cambia SEGNO — ed e' il gate piu' vicino. Un controllo che cercasse "numeri troppo belli" lo lascerebbe passare; implausible_sharpe, girato per la prima volta sulle serie forward, dice "ok" in entrambe le lenti (e chiede n≥30, quindi 2 serie su 3 non sono giudicabili). La firma da cercare e' la VOL forward molto sotto quella del backtest (7,88% contro 31,42%). 📌 QUANDO riparare, con un numero: con rigenerazione zero barre perse a qualunque data; senza, riparare oggi lascia 36/90 barre vere a STATARB (62/90 XSR01, 63/91 DVOLSPREAD), alla vigilia 1 — e la riparazione parziale non contamina la finestra, la ACCORCIA (una barra troncata porta ~1/370 della varianza e del rendimento di una vera, quindi non pesa). ⚠️ La diagnostica pre-registrata del 25/07 (statica sempre-short) non e' affetta perche' si ricalcola dal pannello → al gate si confronterebbe un benchmark giusto con un numero di strategia sbagliato, e il margine sembrerebbe +5,83 invece di +1,87. 🚨 (4) WORST-DAY — la riserva sulla leva e' mal tarata di 2-4 ORDINI DI GRANDEZZA, ma il knob di scala NON ESISTE. 🚨 AGGIORNATO 23/08: il 1,50x e' BOCCIATO (§53: peggior giorno strutturale 21,48% > 20%) e il k massimo difendibile e' 1,40 — di questa riga sopravvive solo la colonna 1,25x. Il gradino di leva vale 14,7a → 12,9a a 1,25x e → 11,6a a 1,50x al capitale-rendita (+€164/mese e +€282/mese di versamenti equivalenti 🚨 il primo e' +€144 misurato direttamente — vedi il ritocco del 23/08 sotto) ed era bloccato da un parametro scelto a mano ("un giorno a 10% ogni anno"). Il peggior giorno ha due risposte: 3,94% in chiusura (2020-03-13) e 7,33% al minimo intra-giorno (rapporto mediano 1,89×). Coda GPD: 4,55% a 1/10.000 giorni [6,34/3,08] ⚠️ ma Hill dice 7,34% (ξ 0,34 contro 0,09): i due stimatori NON concordano → si cita la banda. Conto aritmetico (cap + vol-target + gap-through di SKH01): peggior giorno possibile a k=1,00x 14,32%. 📌 Il 10% sta al 70% del massimo strutturale: la TAGLIA e' plausibile, la FREQUENZA no (1 ogni 67-6.075 anni contro "ogni anno"). 📌 E la forma della coda non e' la leva: muove k di 1-2 unita', il DRIFT di 6,7.* Anche prendendo lo stress alla lettera, k* 2,95x → mezzo-Kelly 1,48x: lo stress bocciava il gradino DOPPIO, non quello singolo. C1-C5 passano tutti. ⚠️ Il libro NON e' immune ai crash, e' immune ai crash GROSSI: sui 160 giorni di crash perde in media 0,505%, e l'esposizione di TP01 scende monotona col crollo (0,096 → 0,042 sotto il 20%) perche' li' il trend si e' gia' girato. Il suo peggior giorno non e' un crash: e' uno SHORT SQUEEZE (SKH01 short con stop 2% che gappa a 15,77% di sleeve mentre TP01 e' flat; il secondo peggiore fa 6,67% → la coda di SKH01 e' un giorno solo). 🚨 IL RISULTATO CHE DECIDE, e nessuno lo cercava: il cap di config/live.json e' un CLAMP, non un MOLTIPLICATORE. Morde su 3 osservazioni-asset su 5.650 (0,053%); alzarlo da 0,50 a 0,625 lascerebbe il libro a k=1,00x in 5.647 giorni-asset su 5.650. Verificato: le chiavi sono max_notional_per_asset_usd/_frac, min_order_usd, disaster_sl_pct, max_data_age_days, skh_feed_max_age_minnon esiste una chiave di scala; servirebbe toccare WEIGHT/W_TP01/ W_SKH in src/live/book.py, cioe' codice su un percorso con soldi veri. ⇒ La regola "ogni cambio di SCALA passa dal cap di config, non da target_vol" NON E' IMPLEMENTABILE COME SCRITTA. Due mesi di discussione su un knob inesistente. Il gradino a 1,25x e' AUTORIZZABILE A CONDIZIONE DI costruire prima una chiave di scala esplicita in config e rifare r0726_fee_sensitivity, la cui conclusione "liquidation fee irrilevante" vale solo a nozionale lordo ≤1x (ed era gia' legata a un test di guardia sul cap). ⚠️ Nota dovuta: credendo entrambe le riserve insieme (drift 2SE e 10% annuo) il drift atteso e' 0,61%/annonon e' il gradino a essere sbagliato, e' il libro; chi usa quella combinazione sta chiedendo di spegnere anche il conto di oggi. 🚨 (5) IL FUNDING DEI PERPETUAL NON E' MODELLATO IN NESSUN BACKTEST — e tocca ogni numero del progetto. Verificato: zero occorrenze di funding in src/backtest/harness.py, src/strategies/trend_portfolio.py, src/portfolio/{sleeves,portfolio}.py e in tutto src/live/. Il progetto ha prezzato fee, slippage, min-order, pavimento IB, haircut, fortuna d'ancora, degrado d'esecuzione, look-ahead, split, rischio di venue e fisco — e mai il costo di TENERE APERTA una posizione su un perpetual. MISURATO la notte stessa (r0822d_funding.py, 1.212 righe, replica bit-exact 5/5, §35 del registro): il libro paga 2,16%/anno di DRIFT (2019-2026) · 1,39% sulla sola finestra dello strumento vero (≥2022-03) · 0,55% sul 2025+. Il costo si cita con la finestra, e il 2022 e il 2026 costano ~0 perche' il libro era FLAT, non perche' il funding fosse sparito. 🚨 Il meccanismo, ed e' trasferibile a ogni futuro candidato su perpetual: esposizione e funding sono POSITIVAMENTE CORRELATI — il tasso pagato davvero e' 1,86-2,55× l'incondizionato per TP01 e 2,41-3,44× per SKH01, quindi il prodotto ingenuo "esposizione media × tasso medio" sottostima di ~2×. Ipotesi da cui il filone era partito, FALSIFICATA: "SKH01 paga meno perche' sta a mercato il 12% del tempo" → paga 2,24%/anno contro 2,02% di TP01, perche' quando e' a mercato sta a nozionale 1,0× (TP01 vol-targeted sta a 0,14×) ed entra sui breakout, cioe' quando il funding e' caro. Il peso 75/25 NON si muove (delta negativo a 23/23 offset per ogni w). ⚠️ Il proxy Hyperliquid era 2,1-2,2× il venue vero (14,8% contro 6,8-7,1% sulle stesse ore): due errori opposti — tasso troppo alto, esposizione condizionale troppo bassa — che quasi si compensavano. Compensarsi non e' misurare. 🚨 NUMERI PUBBLICATI CHE CAMBIANO: rendita perpetua 10,73% → 9,14%; muro $276,6k → $325,0k (+17,5%); traiettoria da $600 a €250/mese 16,4a P(20a) 90% → 18,7a P(20a) 64%; soffitto direzionale ~1,31 → ~1,15. NON cambiano: peso 75/25, gradino di leva (k* 13,7→12,3), maxDD (+0,3pp), ordine delle leve del piano. 📌 E' una tassa sul DRIFT, non sulla coda — per questo colpisce i muri molto piu' dello Sharpe, ed e' lo stesso ordine di grandezza della correzione d'ancora ×0,89. ⚠️ QUESTA CORREZIONE E QUELLA DEL FISCO SI SOMMANO, E NESSUNA TABELLA PUBBLICATA LE CONTIENE ENTRAMBE. La riga "€250/mese" vale P(20a) 92% al lordo · 52% col fisco (07/08) · 64% col funding (22/08): le due lenti sono state applicate separatamente allo stesso numero lordo, e il risultato congiunto sara' peggiore del 52%. La tabella con entrambe non esiste ancora. Validato contro il conto vero per ELIMINAZIONE, non per grandezza: modello vs realized_pnl di sessione ETH 0,2% / BTC 7,7% (le finestre sbagliate sbagliano di 2-4×), e l'identificazione regge perche' nella sessione ci sono stati 0 ordini → il P&L di trading e' esattamente zero, quindi quel campo non puo' essere P&L di trading. Convenzione interest_8h verificata sui dati (mediana |dif| 2,2e-08 contro 1,1e-06). Funding realmente pagato dall'arming: $0,22. ⚠️ BUG in famiglia gia' nota, catturato da un controllo positivo e non a occhio: DatetimeIndex.astype("int64") su tre serie con risoluzioni diverse ([ms]/[us]/[s]) dava 0,000%/anno su SKH01 e +1,229%/GIORNO su TP01nessuna eccezione, nessun NaN, due numeri plausibili in due punti diversi. Stessa famiglia del DatetimeIndex.view("int64") codificato il 01/07. Su un perpetuale lineare, inoltre, diff(nozionale) < 0 NON e' una vendita: il nozionale scende da solo quando scende il mark. SEGUITO 2026-08-22 notte — LA CHIAVE E' SPECIFICATA (docs/research/SPEC-scale-key.md + prototipo isolato r0822e_scale_proto.py, zero scritture, isolamento verificato a runtime), con un NODO IRRISOLTO. Registro §38. Replica a k=1,00 6/6 contro WORST-DAY. ⚠️ CORREZIONE A UN NUMERO CHE AVEVO SCRITTO IO: "1,25-1,50x vale 14,7 → 11,6 anni, ~€300/mese" fondeva due gradini — a 1,25x l'equivalente e' +€164/mese, il €282 e' del 1,50x 🚨 che il 23/08 e' stato BOCCIATO: la meta' cara della frase non esiste piu'. 🚨 RITOCCATO 2026-08-23 (§53), e il ritocco riguarda la CONVENZIONE piu' che il numero: il "+1,8 anni / +€164" e' la lettura a muro CONGELATO (si de-leva al traguardo) e §33 non dichiarava quale delle due letture stesse usando. A muro MOBILE lo stesso gradino vale +2,98 anni; con il funding dentro, +2,10a (congelato) / +3,49a (mobile). La differenza fra le due letture e' 1,2 anni — piu' grande di quasi tutti gli effetti che questo progetto misura ⇒ da qui in avanti un guadagno in anni si cita con la sua convenzione. Il versamento equivalente misurato direttamente e' +€144/mese, non €164: la differenza e' l'ipotesi di linearita' dell'interpolazione. 📌 E il funding va nel verso opposto all'atteso: non riduce il gradino, lo AUMENTA (peggiora il caso base) — ma il livello peggiora su tutta la colonna: k=1,25 col funding (13,78a) resta peggio di k=1,00 senza (14,81a). Il gradino non ripaga il funding, lo attenua. 🚨 Tre risultati che il mandato non prevedeva: (i) test_leva_massima_da_config_resta_sotto_o_uguale_a_1x NON si rompe, ed e' PEGGIO che rompersi: misura frac · n_asset mentre la grandezza vera diventerebbe frac · n_asset · scalacontinua a passare e smette di controllare. 4ª occorrenza della forma "un controllo puntato su una configurazione diversa da quella che gira". Va cancellato con nota, non aggiustato. (ii) La guardia che morde per prima e' il DISASTER-SL, non il peggior giorno: bound strutturale k ≤ 3,49x, disaster-SL k ≤ 1,67x = 2,1× piu' stringenteC1 di WORST-DAY guardava la grandezza sbagliata. Il tetto giusto e' l'invariante n_asset · frac · scala · disaster_sl_pct ≤ 0,50, che lega tre chiavi. (iii) Il tetto va sul PRODOTTO, non sulla chiave: frac=0,625 + scala=1,25 = leva 1,562x e passerebbe un tetto "scala ≤ 1,25" — e WORST-DAY aveva appena pubblicato che alzare frac da solo "non produce k=1,25": combinato con la scala lo produce eccome. 📌 Gate proposto GATE SCALA-01 (9 condizioni, fra cui tetto sul prodotto e A6 anti-recency: k_ammesso calcolato togliendo gli ultimi 90 giorni dev'essere ≥ k richiesto), perche' la scala e' invisibile a ogni gate esistente — Sharpe 1,5051 identico a tutte le celle di k: deflated_sharpe e marginal_vs_tp01 non falliscono, non vedono la variabile. weights_tilt_null invece passa con potenza: peso implicito TP01 0,750000 a ogni k, max|target(k) k·target(1)| = 0, e il controllo positivo (scala sulla sola gamba TP01 = cio' che farebbe target_vol) lo porta a 0,789 e viene smascherato. IL NODO E' SCIOLTO (2026-08-23, r0823_sl_anchor.py, §40) — E LA DICHIARAZIONE DI NON-MISURABILITA' ERA FALSA: IL LOG BASTAVA. (3ª conferma della regola del 26/07: un blocco dichiarato e' un'IPOTESI, non un fatto.) 📌 L'attesa e' stata scritta PRIMA di guardare, derivata dal codice, e ha predetto le soglie esatte: rotolante e simmetrico, innesco +5,263% / 4,762% (il fattore 0,70 si semplifica e la condizione diventa una condizione sul mark, non sullo stop). Il fatto e' confermato: su 1443 giri i 15 placed sono 5 aperture + 7 ribilanci + 3 A POSIZIONE FERMA (21/08, HOLD (a target), 0 ordini, trigger spostato di +5,74/+5,81/+5,38% = appena sopra la soglia predetta); e sul venue l'ordine di stop e' 2,5 giorni piu' giovane della posizione che protegge. 🚨 MA IL TIMORE E' REFUTATO, e va nel verso OPPOSTO: uno stop che segue il prezzo si allontana dal mercato, quindi scatta MENO. Alla cadenza che gira (1h) gli episodi su storia reale sono 0-1 contro 1 del pavimento, mai piu' di 1 in 30 giorni; e nell'outage — l'unico scenario per cui il bracket esiste — il ri-ancoraggio e' SPENTO per costruzione (nessun giro, nessun ri-piazzamento) ⇒ un episodio solo. Il 37,5% resta il costo di un episodio singolo, il margine 1,33× e' quello vero, la gamba di WORST-DAY REGGE. 🚨 Due cose indipendenti da k, da sapere comunque: (i) il nome inganna"disaster-SL 30%" suggerisce un massimo di perdita per trade che non esiste: su cicli a ingresso proprio il rotolante lascia passare perdite oltre 30% senza scattare nel 0,03%/0,96-2,84%/7,22-13,33% dei cicli (24h/7g/30g) e il peggior DD dall'ingresso e' 60,6% BTC / 61,5% ETH; (ii) 🚨 TRAPPOLA VIVA: l'accumulo e' funzione della CADENZA DEL CRON, e il docstring di book_execute.py prescrive "ogni ~230 minuti" mentre il cron gira OGNI ORA — chi "correggesse" la cadenza verso il docstring sposterebbe il libro sulla riga 4h, dove BTC RADDOPPIA gli scatti (2 contro 1; a 24h ETH arriva a 5). Il docstring e' sbagliato e la configurazione che gira e' quella giusta. ⚠️ Limite dichiarato: 0 ri-ancoraggi verso il BASSO osservati su 3 — 2 mesi di vita del libro in un solo regime (BTC ~$66,5k → ~$78,6k), mai un calo del mark >4,76% con posizione aperta. La simmetria e' un fatto di CODICE (un solo abs(), esercitato in entrambi i versi), non un fatto OSSERVATO: la prima osservazione utile arriva al primo ribasso >5% con posizione aperta. Seconda soglia dichiarata: il fallback dell'equity oggi scatta 0 volte su 1.442 giri; sopra il 2% dei giri in 90 giorni il libro girerebbe a leva mista e g(k) smetterebbe di descriverlo. REGOLE NUOVE: (a) una data in un gate va giustificata col COSTO della misura, non con la sua difficolta' percepita — due gate d'attesa eliminati in una sera perche' nessuno aveva contato i secondi; (b) una verifica esterna a €0 va fatta PRIMA di qualunque misura che ne dipenda, e si fa sul venue, non sul sito di chi la dichiara; (c) un gate superato non e' un numero confermato: differenze e livelli ereditano la fortuna d'ancora in modo diverso; (d) un veto d'integrita' sorveglia l'asse su cui e' stato scritto — contare se il dato c'era non dice quanto del giorno copriva; (e) una regola operativa va provata contro il codice che dovrebbe eseguirla, o si discute per mesi di un knob che non esiste; (f) quando due stimatori di coda non concordano si cita la banda, non quello che conviene.

  • 🌊 QUINTA ONDATA 2026-08-23 (12 filoni + critico di chiusura, research/wave-0822) — 0 candidati su 57 filoni cumulativi, 1 candidato scoperto GIA' IN PRODUZIONE SENZA GATE, il gradino di leva delimitato, e un critico che ha falsificato due sue attese e tre miei numeri. Registro docs/research/RESULTS-0822.md §46-57; 17 script scripts/research/r0823_*.py (15.443 righe, compilano tutti, ognuno gira da solo). Libro, pesi, cron, config INVARIATI. 🚨 (1) IL RISULTATO PIU' IMPORTANTE NON E' UNA STRATEGIA NUOVA: E' CHE LA PIU' FORTE GIA' MISURATA GIRAVA SENZA GATE. §50 cercava il miglior TERZO sleeve eseguibile a $635: sette candidati, sette muri diversi, e nessuno dei sette e' una soglia di capitale. Il piu' forte — PREVDAY — sta in monitor da giugno senza gate pre-registrato e senza deflated-Sharpe. §54 gliene ha scritto uno (GATE PREVDAY-01, 8/10 condizioni oggi) e le due che mancano sono la stessa cosa: 🚨 la cella che GIRA non e' quella che la selezione onesta sceglie (e la cella viva fallisce il DSR, 0,905), e la selezione onesta compra il libro LONG-FLAT — cioe' butta via proprio la gamba per cui PREVDAY fu promosso. La serie e' intatta, 1512 barre su 1512 (e' il monitor sano, quello che il difetto advance() non tocca) ⚠️ ma la finestra e' 0,172 anni → MDE 4,72 di Sharpe: il +2,11 forward non e' distinguibile da zero su 26 ENTRY. Qualunque cosa il gate decida, non puo' appoggiarsi al numero forward. 🚨 (2) IL GRADINO DI LEVA E' DELIMITATO: 1,25x REGGE, 1,50x E' BOCCIATO, k max difendibile 1,40. §53 lo attacca 6 volte col funding dentro: 5/6 falliscono; il 1,50x cade sul peggior giorno strutturale (21,48% > 20%). L'incrinatura e' il ramo eq_fallback, dove la scala non apre il buco: lo MOLTIPLICA. Aritmetica dei tetti verificata sul config che GIRA, 3/3 al centesimo: disaster-SL ⇒ k ≤ 1,67 · peggior giorno ⇒ k ≤ 3,49 · scettico ⇒ k ≤ 1,40. (3) TRE MECCANISMI DI PROTEZIONE REFUTATI, E DUE PER LA PREMESSA. TAIL-HEDGE (§46): la premessa cade prima del prezzo — il maxDD SALE in 162/162 celle, a ogni lente di f (f=1,00 regalato compreso), perche' il beta del libro al sottostante e' +0,076: non si assicura un libro che nei crash e' gia' quasi piatto. TP01-TWIN (§49): un ensemble di definizioni di trend protegge PEGGIO — 0/24 ancore nei 4 anni recenti, 3,2x peggio nel 2022, 0,127 di Sharpe hold-out; e i meccanismi non erano ridondanti (corr di posizione 0,61): la ridondanza non era il problema. ANCHOR-ENSEMBLE (§47): eseguibile, ma su TP01 il drift non puo' cambiare per algebra (lordo_ens == media(lordi), residuo 1,4e-17); il segnale c'e' su SKH01 (+0,312 di Sharpe mediano, maxDD 23,3%→16,6%) ma dentro il libro non si distingue da zero. 📌 (4) IL LEAD DELLO SPOT MUORE DOVE SERVIREBBE. §52 lo attacca sei volte: 5/6 falliscono, e cio' che morde non e' nei numeri — e' nella taglia a cui vengono spesi. Regge a $600, si annulla a $272k: sparisce esattamente al muro che pretende di spostare. (5) IL COSTO D'ESECUZIONE ENDOGENO NON MORDE (§55): muro +0,6% (dentro la risoluzione MC), saturazione a $9,5-10M = 30x sopra, e il fatto trovato per strada — alla taglia di oggi il costo mancante ha SEGNO NEGATIVO: il drift a $635 e' 13 bps/anno piu' basso che a $5.000 per il pavimento min_order $5, ~2x quello che lo slippage costa da $313k a $1M, in direzione opposta. Il conto piu' preciso non muove il muro: sposta il segno dell'errore, e a questa taglia lo sposta a favore. (6) DUE CHIUSURE DI FAMIGLIA. VOLVOL (§48): la volatilita' del DVOL e' davvero una variabile NUOVA (ortogonalita' PASS, max |corr| 0,396) ma guarda INDIETRO — picco a lag 5/10, parziale con la vol futura NEGATIVA: un secondo momento non e' automaticamente informazione anticipata. ⚠️ Ma il filone lo chiude su una branca dove dichiara esso stesso un fattore 44 sotto l'MDE: e' un'etichetta piu' forte della misura. XS-AMPIEZZA (§56): su 11 gambe la caduta NON era ampiezza — solo il 14%: e' selettivita' (recuperabile, ma sotto l'MDE) piu' un IC che su quelle gambe vale ZERO. 🚨 E k=5 non e' invariante di scala: il numero di gambe per lato di XS01 e' tarato su 19 gambe, non e' una proprieta' del meccanismo. 📌 (7) SOLO 2 FONTI SU 10 MERITANO DI ESSERE RACCOLTE (§51): la catena USDC (+18% di chiamate, non +90%) e una campagna a termine di book depth. Il criterio di ricostruibilita' ne uccide 4 da solo — se lo puoi ricostruire domani, non raccoglierlo oggi. ⚠️ (8) ERRORI MIEI, corretti dentro l'ondata (tutti numeri gia' pubblicati, due in questo file): (a) "la convinzione di TP01 sta spesso a 1/3 o 2/3"falso, tsmom_blend media tre np.sign() → direzione in {0, 1/3, 1} dopo il clip: il bucket 2/3 NON ESISTE, la famiglia ha UN grado di liberta'; trovato indipendentemente da due agenti. (b) catena USDC "+90% di chiamate"+18% (i 587 erano il conteggio grezzo, senza il filtro OI≥100 del collettore; al venue: 113 USDC contro 649 inverse). (c) "le opzioni BTC sono fuori a $3.000 per il lotto" → quello e' il collaterale per VENDERE; comprare costa il premio (min_trade_amount 0,01) e il muro vero e' il TICK da 5,00 USDC (una put che vale 0,82 non e' quotabile sotto 5 = pavimento di prezzo 6x). (d) "il gradino vale +1,8a / +€164" — era la lettura a muro FERMO, convenzione mai dichiarata; a muro mobile fa +2,98a, e le due distano 1,2 anni. (e) "la coda muove k* di 1-2 unita'"4,6. 🚨 (9) IL CRITICO DI CHIUSURA (§57) — repliche 6/6, ma tre numeri di testa vanno riscritti. Ha riprodotto con macchineria propria i quattro muri al dollaro, il funding (2,1597%/anno, e da implementazione indipendente TP01 2,138% con rapporto condizionale 1,93x/2,58x), il dShFULL di §42 (0,4502) e che il muro E' esattamente prelievo/perpetua su 4 lenti su 4 — il nucleo quantitativo dell'ondata regge. Le tre cose che cambiano — la banda del muro, «N/N ancore» = ~2 osservazioni e il 1,50x bocciato — sono gia' scritte nei bullet a cui appartengono, sopra. In piu': tre baseline diverse sotto lo stesso nome «libro 75/25» (hourly 1,683/11,22% = la lente di ogni muro e traiettoria · canonical 1,800/9,56% · mediana d'ancora 1,626/10,4%) — spread 0,12 di Sharpe e 1,7pp di maxDD, piu' grande di quasi tutti gli effetti che l'ondata misura, quindi un Δ accostato al baseline sbagliato cambia piu' del Δ: ogni numero va scritto con la sua lente attaccata. ⚠️ E il pilastro del canale funded (§21, XS01 fuori campione) ha effetto +1,12 contro un MDE di 1,13: sta esattamente al proprio limite di rilevabilita', e viene propagato fino a P(≥50 €/g) come se fosse noto a due cifre. (Equita': §21 gira anche un null di permutazione a fee zero, p=0,013, che ha piu' potenza del t-stat — il problema non e' «nessuna evidenza», e' la precisione attribuita al livello.) A credito dell'ondata: quattro auto-correzioni in 24 ore (§45 falsificato da §52; §39 falsificato lo stesso giorno; la regola «overlay non causale» ritirata; «dealer_net_gamma e' il GEX invertito» ritirata leggendo il sorgente). E' il dato piu' sano dell'ondata. 🚨 (10) LA RISPOSTA AL MANDATO, in una sola unita' (€/giorno a $635): gradino di leva 1,25x +0,046 · lead SPOT +0,017 · PREVDAY al 15% de-luckato +0,014 · BIN-FREQ +0,011 · MAKER +0,005 · funding (costo scoperto) 0,023. Somma di TUTTI i lead positivi, se fossero autorizzati e additivi (non lo sono, e nessuno e' eseguibile oggi): +0,036 €/giorno. Sullo stesso motore e sugli stessi percorsi: €250 → €500 al mese porta P(20a) dal 14% all'85% e la mediana da 23,4 a 17,3 anni. VERDETTO DELL'ONDATA: NIENTE CHE AVVICINI I 50 €/GIORNO. Ha prodotto (i) un costo gia' in essere che porta P(20a) a €250/mese dal 49% al 14% (il funding), (ii) quattro monitor rotti che avrebbero fatto decidere un gate al contrario, (iii) un punto singolo di guasto nella rete di sicurezza (il trasporto degli allarmi), (iv) tre lead reali tutti bloccati da qualcosa che non e' la ricerca. Il suo valore e' DIFENSIVO ed e' reale: ha impedito decisioni sbagliate. E nulla di sepolto sotto uno «SCARTATO» merita di essere riesumato: il candidato piu' forte non promosso vale +0,014 €/g de-luckato e gira la cella sbagliata. 📌 La riga che chiude cinque ondate e 57 filoni: la ricerca ha smesso di essere il vincolo binding il 26/07, e ora cinque ondate lo hanno CONFERMATO invece che ribaltarlo. I vincoli binding restano due: il capitale che entra e il conto che non sparisce.

  • 🚨 IL PIANO AL NETTO DI TUTTO — la tabella congiunta (2026-08-22, r0822d_piano_vero.py). QUESTA SOSTITUISCE OGNI TABELLA DI TRAIETTORIA PUBBLICATA SOPRA. Le due correzioni misurate al piano — fisco d'accumulo (07/08) e funding (22/08) — erano state applicate separatamente allo stesso numero lordo, e la tabella con entrambe non esisteva. Registro §36. Replica 6/6 prima di pubblicare, due esatte AL DOLLARO sul vintage 07/08 ($272.061 lordo, $258.338 netto fisco). ⚠️ Sulla serie di oggi la stessa riga da' $278.033 (+2,2%) — 15 giorni di dati in piu', data/raw/ gitignored (stessa lezione GTAA del 07/08) → ogni terza cifra di un muro e' rumore, e i confronti fra lenti vanno fatti sullo stesso vintage.

    lente (de-luck ×0,89) drift perpetua muro €250/m da $635: P(20a)
    L0 LORDO (26/07) 17,11% 10,68% $278k 90% (pubbl. 92%)
    L1 +FISCO (07/08) 17,11% 7,52% $264k 49% (pubbl. 52%)
    L2 +FUNDING (22/08) 15,19% 9,06% $328k 63%
    🚨 L3 CONGIUNTA 15,19% 6,35% $313k 14%
    L3b congiunta, funding "strumento vero" 1,39%/a 15,87% 6,72% $296k 26%
    🚨 IL MURO E' UNA MEDIANA, E LA SUA BANDA E' ESPLOSIVA (misurato dal critico, 23/08).
    La SE del drift L3 e' 5,151%/anno (block bootstrap 20g; replicata su un'altra lente a 5,09):
    **+1 SE → $204.517 · p90 → $186.623 · PUNTO $313.143 · p10 → $1.141.172 · 1 SE → $709.753 ·
    2 SE → il traguardo NON ESISTE a nessun capitale.** «€500/mese → P(20a) 85%» diventa **~0% a
    1 SE**; «€250/mese → 14%» diventa 96% a +1 SE. 📌 **Meccanismo: il muro e'
    prelievo/perpetua e la perpetua si annulla molto prima del drift → e' un 1/x su una quantita'
    che va a zero, quindi l'errore e' asimmetrico verso l'alto.** 🚨 **E il progetto ha pubblicato la
    risoluzione MONTE CARLO del muro (0,7%) accanto a un numero la cui incertezza di PARAMETRO e'
    cento volte piu' grande: ha misurato la precisione del simulatore e mai quella del suo input.**
    ⚠️ La SE del block-bootstrap e' un limite inferiore (variabilita' dentro gli stessi 7,4 anni,
    non il cambio di regime). **REGOLA: il piano si dimensiona sul VERSAMENTO, che e' certo, non sul
    muro.**
    🚨 **LE DUE CORREZIONI NON SI COMPENSANO: SI SOMMANO — e nel VERSAMENTO necessario il congiunto e'
    +10% PEGGIORE della loro somma.** Il meccanismo "meno drift → meno plusvalenza → meno imposta"
    esiste (+9,97% di capitale recuperato; il fisco toglie il 50,9% a funding OFF e il 46,0% a
    funding ON) ma la funzione versamento→probabilita' e' CONVESSA e ne ribalta il segno.
    Interazione misurata in tre monete: +9,97% sul capitale · **$815 sul muro (0,26%, SOTTO la
    risoluzione MC)** · +26 €/mese sul versamento (+10%, segno stabile su 3 semi).
    **REGOLA: non contare su una compensazione fra correzioni misurate separatamente — la si misura, e
    in piu' di una MONETA, perche' un'interazione piccola cambia segno con la moneta.**
    QUANTO VERSARE, al netto di tutto (da $635, nessun lump):
    orizzonte P=50% P=75% P=90% totale versato @P=90%
    --- --- --- --- ---
    10 anni €1.323 €1.534 €1.733 $229.189
    15 anni €656 €784 €920 $183.129
    20 anni €360 €445 €541 $143.804
    Il solo funding aggiunge 1,27× / 1,33× / 1,40× sopra la lente fisco-only.
    RENDITA €/g mediana a 20 anni: €250/m → 31,85 €/g, P(≥50/g) 8,8% · €500/m → **63,05, P
    77,1%** · €800/m → 100,50, P 99,2%.
    📌 IL LUMP, mai entrato nelle tabelle nette: €10.000 oggi + €250/m porta P(20a) da 14% a 45%
    (€5.000 → 30%). E' la leva piu' grande misurata dopo il versamento mensile stesso.
    📌 LA RISPOSTA ALLA DOMANDA DEL PROGETTO: *€250/mese da $635 → 23,4 anni (mediana
    incondizionata; 22,1 condizionata all'arrivo), P(20a) 14% [banda "strumento vero": 22,2 anni,
    26%]. Per €50/giorno in 10 anni servono €1.733/mese a P=90%, totale versato $229.189.*
    A 10 anni si versano $229k per arrivare a ~$313k: il rendimento fa il 27%, i bonifici il 73%
    ⚠️ CORREZIONE 23/08: il 73% e' l'INTERO ORIZZONTE, non il versato fino all'arrivo. Il
    contatore versato di accumula e' uno scalare che non si ferma al traguardo (stessa
    famiglia del bug paid catturato il 25/07, in un altro punto): il versato fino all'arrivo e'
    $190.265 = il 61%, con P(traguardo) 91%. E «€X/mese» versa ogni 30 GIORNI
    121/182/243 versamenti invece di 120/180/240 (+0,83/+1,11/+1,25%), in ogni tabella dal 25/07.
    Entrambi i difetti vanno a favore del piano. —
    forma piu' netta della lezione gia' scritta: *a orizzonte corto non fai lavorare la strategia,
    COMPRI il capitale coi bonifici.*
    ⚠️ Cosa NON e' incluso, di proposito: il rischio di venue, che e' rovina e non costo
    (a p=5% il mediano e' zero a ogni calendario) — resta sul suo asse separato.
    Smentitori dichiarati: il funding pre-2022 e' proxy inverse sul 40% del campione (se il
    lineare 2019-21 fosse costato quanto il 2022+, la colonna vera e' L3b); il modello fiscale tassa
    la variazione annua di valore = limite superiore; il bootstrap gira su 7,4 anni con due tori.
  • ⚖️ CANALE FUNDED — GATE PROP-01 CHIUSO 3/3 in una notte, e il numero onesto e' 2,6% (2026-08-22). Registro §29-32, §37. Libro, pesi, cron, config INVARIATI. Il gate nato ieri con due gambe datate ad anni e' stato chiuso tutto oggi, e ogni chiusura ha peggiorato il numero:

    gamba criterio esito
    (a) LISTINO ≥10 delle 13 gambe shortabili PASS 13/13 — misurato sul venue (Bybit instruments-info, 833 strumenti), non sul sito
    (b) ANCORA SKH01 delta appaiato > +0,05 sui 23 offset PASS 23/23, +0,116, 230/230 celle congiunte — ⚠️ ma «23/23» vale ~2 osservazioni, vedi sotto
    (c) CAPITALE riformulata, vedi sotto PASS 2/2
    📌 La (c) e' stata RIFORMULATA perche' era una constatazione, non un criterio — e la sua forma e'
    imposta dal costo della misura: l'EV costa una corsa di script (zero dollari), la
    rimborsabilita' del deposito costa $579 e si puo' misurare solo COMPRANDO → un gate d'attesa su
    quella sarebbe superabile solo dopo averlo violato. Quindi:
    (c1) ECONOMICA — EV del biglietto > 0 con la quota trattata come SPESA PERSA, alla cella
    d'ancora mediana (non canonica), col funding dentro, lente accoppiata. Oggi $+1.615.
    (c2) DI SOPRAVVIVENZA — prezzo del biglietto ≤ 2 versamenti mensili del piano in corso
    (il piano d'accumulo e' la leva dominante misurata, e zero e' assorbente). *Oggi **$579 contro
    $1.090***. (c1) e' scritta perche' la rimborsabilita' NON decida: il rimborso e' **un regalo, non
    un'ipotesi su cui si e' scommesso**.
    🚨 **IL NUMERO, e la catena di un giorno solo: P(≥50 €/g) da €600 in 36 mesi = 42% → 7,8% → 4,4% →
    2,6% [1,5%, 4,7%], con P(zero) 40,3%.** Nell'ordine: universo fuori campione (42% del J stava in 6
    gambe che nel 2021-23 non esistevano) · banda d'ancora di SKH01 (canonica al 91° pctl) · funding
    (dJ 0,049 su 69/69 celle appaiate).
    📌 EV del biglietto POSITIVO in tutte e tre le convenzioni sul deposito (spesa persa +$1.615 ·
    rimborso al pass +$1.919 · rimborso al primo payout +$1.835). ⚠️ **E il progetto conteneva GIA' due
    modelli contraddittori della quota:** r0725_hyro:200 la rimborsa al pass, pc.simulate mai
    — e il numero operativo usciva dal secondo.
    🚨 XS01 PAGA il funding, non lo incassa — meccanismo DIMOSTRATO: `max ΣW = 2,8e-17`
    (dollar-neutral esatto) ⇒ **il livello del funding non entra, entra solo la DISPERSIONE
    cross-sezionale**, e il momentum compra i perp col funding piu' caro+1,45%/anno
    [IC95 +1,18/+1,72; banda onesta +0,69/+1,45 se HL e' ~2,1× il venue]. *L'ipotesi opposta ("market-
    neutral ⇒ si compensa") era esplicita nel briefing ed e' falsa.*
    📌 Piu' leva sul funded ALZA E[payout] e ABBASSA P(payout): sono due obiettivi diversi, e chi
    vuole il rimborso non vuole la leva massima.
    IL CONFRONTO CHE DECIDE (36 mesi, $654, stesso bootstrap appaiato, funding e fisco in entrambe):
    versamento strada mediana
    --- --- ---
    €0 BIGLIETTO $132
    €0 LIBRO $787
    €500/m BIGLIETTO $39.820
    €500/m LIBRO $22.444
    **`IL BIGLIETTO CONTRO IL VERSARE: MEGLIO — ma solo perche' il piano di versamento c'e', e la ragione
    non e' il rendimento, e' il NUMERO DI VOLTE CHE SI PUO' GIOCARE.`** Senza versamenti la stessa
    scommessa perde la mediana 6× e vince la media 12×: una lotteria a EV positivo che un conto da
    $654 puo' giocare una volta sola. *(Il libro da solo fa P(≥50/g) 0,0% a 36 mesi per struttura:
    non e' un difetto del libro, e' l'orizzonte.)*
    ⚠️ Cio' su cui poggia tutto, dichiarato: il drift di XS01 misurato su 13 gambe su 19; la
    morte-firm ~10%/anno e' un'assunzione (se fosse ≫ l'EV si azzera **senza che nulla nel
    modello lo segnali**); il cap $200k/trader limita il canale per struttura.
    ⚠️ Un numero netto catturato PRIMA di pubblicarlo: il "capitale d'incrocio €1.000-2.000" **non e'
    un meccanismo** — la ricchezza terminale della strada-biglietto e' bimodale, P(cassa < $249) si
    muove liscia (56,3 → 0,0%) mentre la mediana salta di un ordine di grandezza appena quella
    massa passa il 50%. Li' la mediana non e' robusta, ed e' esattamente il tipo di numero netto che
    si sarebbe finito per citare come soglia di progetto.
  • 💡 EVITARE IL FUNDING — datati SCARTATI, ma lo SPOT e' un LEAD e la domanda fiscale vale piu' del risparmio (2026-08-23, r0822e_funding_avoid.py). Registro §39. Libro/pesi/cron/config INVARIATI. Primo filone della sessione che poteva restituire drift invece di toglierlo. Il segnale resta CONGELATO (TSMOM 30/90/180, vol-target 20%): cambia solo lo strumento.

    variante ShFULL ShHOLD drift Δdrift muro
    A) perp (oggi) 1,513 1,154 17,08% $325,0k
    D) TP01 datato + SKH01 perp 1,507 1,118 17,53% +0,47% $319,5k
    E) TP01 SPOT + SKH01 perp 1,649 1,203 18,63% +1,55% $289,6k (10,9%)
    F) nessun carry (irreale) 1,692 1,214 19,24% +2,16% $276,6k
    DATATI: NON CONVIENE. La tesi condizionale regge (funding condizionale 1,94×/2,59×
    l'incondizionato — replica indipendente del 1,86-2,55× — contro basis 1,47×/1,66×: in
    livello i carry sono identici, il datato vince solo perche' si riprezza meno), ma il
    vantaggio e' tutto 2019-2023, ~0 o avverso dal 2024 → ShHOLD 0,034 negativo a 0/23 offset e
    gate iso-volatilita' FALLITO. SKH01 sui datati peggiora (turnover 48-57×/anno contro
    6,6-8,4× di TP01 → lo stesso mezzo spread gli costa 7 volte tanto).
    💡 LEAD: lo strumento a carry ZERO esiste ed e' lo SPOT (BTC_USDC/ETH_USDC, taker 0,0
    oggi, min 0,0001). TP01 e' long-flat e supera 1,0× nello 0,102% dei giorni → il tetto non morde;
    +1,55%/anno di drift a volatilita' IDENTICA (supera il gate iso-vol), muro 10,9%.
    ⚠️ NON e' un candidato, tre ragioni dichiarate: (a) SKH01 non e' esprimibile sullo spot
    (long/short); (b) la fee 0 e' dichiarata temporanea e fee_watch non sorveglia lo spot
    se sparisse, 13% del vantaggio (misurato); (c) 🚨 **la domanda fiscale aperta vale PIU' del
    risparmio**: se i derivati sono c-quater (26%) e lo spot c-sexies (33%), **7 punti su un CAGR
    del 17,9% = ~1,25%/anno**, cioe' piu' di quello che lo spot porta → **la domanda al
    commercialista viene PRIMA di qualunque prova**, ed e' la stessa gia' aperta dal 07/08.
    🚨 MURO EREDITATO FALSIFICATO (correzione a §34, scritto poche ore prima): *"tutti i futures
    datati Deribit sono INVERSE, non esiste una linea USDC datata"* e' FALSO — esistono **16 datati
    USDC su BTC/ETH** (il piu' vecchio BTC_USDC-25SEP26, creato 2026-05-07), taker **identico al
    perpetual**, min 0,0001 BTC / 0,001 ETH. Verificato con GET pubblica. **La svista e' di
    NAMESPACE:** get_instruments?currency=BTC non li ritorna, stanno sotto currency=USDC
    e il coordinatore ha commesso la stessa svista al primo controllo, ottenendo 0. **Il muro vero e'
    un altro: 3,5 mesi di vita e ZERO roll trimestrali mai eseguiti.** *(6ª volta nell'ondata che
    l'eseguibilita' non e' il vincolo.)*
    📌 **REGOLA: il carry si misura sul LOG del rapporto dei prezzi, mai sulla media aritmetica delle
    differenze** — quella contiene (var A var B)/2, che qui vale **1,48%/2,60% l'anno = 2-4×
    l'effetto cercato**. Controllo che lo rende visibile: col metodo aritmetico il perpetual
    "sovra-rende" il proprio indice di +0,4/+0,5%/anno, col log ~0. **Stessa forma della regola UCITS
    del 26/07**, in veste nuova.
    ⚠️ BUG in famiglia gia' nota, e NON visto dal numero: fund_*.parquet etichetta l'indice
    all'istante T, al.get(a,'1h') la barra all'inizio → appaiarle sfasa di un'ora
    (corr 0,996 al lag +1, ~0 al lag 0), gonfia la sd della base da 8 a 68-86 bps e produceva un
    finto +0,32%/anno nel verso atteso. 📌 **Si e' visto dalla VOLATILITA' (+1,07pp su una strategia
    identica), non dal numero.** Il pezzo vero vale +0,07%/anno. **REGOLA: due serie temporali dello
    stesso progetto possono avere convenzioni di etichettatura diverse — verificare col LAG, non
    fidarsi dell'indice.**
  • Soffitto strutturale BTC/ETH-direzionale ~1.3 superato SOLO espandendo a un meccanismo diverso: cross-sectional su universo Hyperliquid certificato (XS01) → portafoglio Sharpe ~1.55.

  • Sweep "strategie alternative" (2026-06-20) — 104 ipotesi / 153 agenti / NIENTE di nuovo regge. Ricerca onesta a largo spettro su BTC/ETH+DVOL (harness condiviso vettoriale leak-free scripts/research/alt/altlib.py, 104 script in scripts/research/alt/runs/): 11 famiglie (breakout, trend non-TSMOM, mean-rev gated, DVOL/vol, cross-asset pairs, stagionalità, overlay rischio, opzioni modellate, microstruttura, ML walk-forward, combo). 16 promettenti, 1 sola sopravvissuta alla verifica avversariale (3 scettici) e comunque NON deployabile. Conferma forte del soffitto ~1.3: ogni PASS era hold-out-fitting o TP01/TSMOM travestito (trend-beta del toro). Unico LEAD: STA05 (EWMA-cross ensemble, long-short) — leak-free, plateau, corr hold-out 0.53 a TP01, il blend 0.75·TP01+0.25·STA05 alza l'hold-out 0.31→0.59 (full 1.30→1.24, DD 14→16%); MA hold-out corto (536g) → forward-monitor, non sleeve. Lezione harness: valutare lo Sharpe MARGINALE vs baseline TP01 (non assoluto) + esigere plateau e jackknife drop-one-month sull'hold-out prima di PASS (hanno ucciso 13/14 falsi positivi). Diario 2026-06-20-alt-strategies-100agent-sweep.md.

  • MARGINAL SCORER (implementato 2026-06-20) — la lezione "Sharpe marginale, non assoluto" è ora codice in scripts/research/alt/altlib.py: study_marginal(name, target_fn) valuta un candidato direzionale BTC/ETH sia in assoluto sia rispetto al baseline tp01_baseline_daily() (corr, uplift del blend OOS, beta+alpha residua) e ritorna earns_slot = (abs!=FAIL) AND (marginal==ADDS). Regola: una nuova strategia direzionale si giudica su earns_slot, non sullo Sharpe assoluto (gli overlay-su-TSMOM ereditano lo Sharpe di trend e prendono PASS fasulli — es. CMB04 PASS assoluto → NEUTRAL marginale). Demo marginal_demo.py, test tests/test_marginal_scorer.py. ⚠️ INDURITO 2026-06-21 (onda ortho): la versione fisso-HOLDOUT + jackknife-mese era ingannabile — 17/18 book relative-value "ADDS" su una sola finestra 2025 (ETH-bleed dove TP01 è debole). Tre gate nuovi in marginal_vs_tp01: (1) persistenza multi-cut (uplift positivo a più date di taglio, non solo 2025); (2) edge in-sample (has_insample_edge: lo Sharpe standalone PRE-holdout dev'essere ≥0.5 — un low-corr a Sharpe ~0.3 "aggiunge" solo matematica di diversificazione, riportata via null_pctl_* vs un asset-rumore a corr-zero); (3) hedge vs alpha (is_hedge: un low-corr che paga SOLO quando TP01 è debole — corr(Sharpe-TP01, uplift annuo) molto negativa — è un hedge, non alpha). Verdetti nuovi: HEDGE, NOISE. Sull'onda ortho lo scorer indurito collassa 17/18 → 1 (dvol_spread, unico con edge in-sample reale; comunque forward-monitor per multiple-testing/storia DVOL corta). Lezione: un nuovo sleeve si giudica su edge-in-sample + persistenza multi-cut + non-hedge, non sull'uplift di una finestra fortunata.

  • HARNESS REALISM (codificato 2026-06-21, onda intraday) — due gate nuovi in altlib.py, test tests/test_harness_realism.py:

    • day_boundary_robust(target_fn, tf) — un effetto ora/sessione/giorno il cui uplift marginale si inverte spostando il confine del giorno UTC di poche ore è un artefatto di etichettatura calendario (ha ucciso open_drive: +0.23 a 00:00 → 0.33 a +8h → ARTIFACT-RISK). Un segnale di prezzo è INVARIANT (spread 0); un effetto calendario vero è ROBUST (resta positivo; es. prevday_range_breakout). Regola: ogni segnale calendar/session/hour passa questo test prima di crederci.
    • eval_weights_smallcap(df, target, capital=600, min_order=5) — a ~$600 un ribilanciamento di nozionale < min_order non si esegue; la fee proporzionale che eval_weights applica a migliaia di micro-trade sub-dollaro (tipici di un overlay vol-target) è finzione. Salta i sub-min_order e riporta lo Sharpe haircut reale vs modellato. Vale per OGNI sleeve a questo capitale, TP01 incluso — lo Sharpe netto onesto a $600 è quello small-cap, non quello modellato.
  • SELECTION-ON-HOLDOUT gate (codificato 2026-06-29, filone B intraday ERM) — terzo gate in altlib.py, test tests/test_harness_realism.py. Il lead ERM faceva earns_slot=True MA lo script di scoperta sceglieva la cella per min_hold massimo su 60+ celle = selezione-sull'hold-out: scegliendola in-sample-only ne esce un'altra (trend-beta corr→TP01 0.53, NEUTRAL) e il deflated-Sharpe crolla (DSR 0.0-0.24 su 122 trial). study_marginal da solo non lo vede (giudica UNO stream, non come è scelto). Tre funzioni: deflated_sharpe() (Bailey & Lopez de Prado, PASS ≥0.95), select_cell_insample() (cella scelta col solo Sharpe pre-HOLDOUT), e il gate combinato study_family_honest(name, factory, grid, tfs)earns_slot_honest = earns_slot[cella in-sample] AND deflated-Sharpe≥0.95. Regola: una strategia direzionale grid-searched si giudica con study_family_honest, non chiamando study_marginal sulla cella a max hold-out. Chiude il punto cieco gemello di CC01 ("Sharpe implausibile"). Diario 2026-06-29-intraday-regime.md (analisi scripts/research/intraday_regime_analysis.py).

  • Onestà sul target €50/giorno: NON raggiungibile su 2000 in 1-2 anni (servono ~130k di capitale o un DD da rovina). La leva non è la scorciatoia; la via è target-vol + capitale + tempo. La strategia che guadagna esiste, ma a ~+€1.5/giorno su 2000.

Script ricerca: scripts/research/track{A,B,C,D,E}_*.py + trackD_timing.py.

Obiettivo

Ricerca: riconoscimento pattern frattali per trading algoritmico su crypto. Target dichiarato €50/giorno partendo da €1.000. Onestà prima di tutto: nessun numero va creduto finché non è netto fee, out-of-sample, robusto su griglia, e su dati certificati + liquidi + eseguibili.

Stack

  • Linguaggio: Python 3.11+ — Package manager: uv (pyproject.toml, uv.lock)
  • Dati: Parquet in data/raw/ (gitignored). Solo BTC/ETH (5m/15m/1h).
  • Analisi/ML: numpy, pandas, scipy, scikit-learn
  • Fonte dati storici: Deribit mainnet via ccxt (pubblico, tokenless)

Struttura (post-reset)

src/data/downloader.py     → load_data(asset, tf): legge i parquet certificati da data/raw/
src/strategies/base.py     → Strategy (ABC), Signal, BacktestResult, YearlyStats
src/strategies/indicators.py → indicatori condivisi (ema, atr, keltner, ...)
src/strategies/trend_portfolio.py → TP01: strategia DIFENSIVA robusta (PORT LF1d, >=12h), causale
src/portfolio/             → PORTAFOGLIO DI STRATEGIE estensibile (Sleeve + StrategyPortfolio)
  portfolio.py             → combina N sleeve per peso su griglia giornaliera; metriche FULL/hold-out/anno
  sleeves.py               → REGISTRY sleeve attivi: TP01 33 / XS01 15 / VRP01 12 / SKH01 20 / GTAA01 20. Aggiungere = una riga
src/fractal/               → indicatori frattali (patterns.py, indicators.py, similarity.py)
src/backtest/engine.py     → engine di backtesting riusabile
src/backtest/harness.py    → harness ONESTO (load BTC/ETH, backtest_signals no-leakage, OOS)
src/version.py             → APP_VERSION (legge il file VERSION)
scripts/research/          → ricerca: track{A-I}_*.py + options_vrp_*.py + fetch_dvol.py
scripts/portfolio/         → run_portfolio.py (report) + xsec_*.py (ricerca/affinamento XS01)
scripts/live/paper_portfolio.py → paper/forward-only del book attivo TP01+XS01 (1d) (no esecuzione reale)
scripts/analysis/          → SOLO i tool dati certificati:
  rebuild_history.py        → (ri)costruisce lo storico da Deribit mainnet (base 5m + resample)
  certify_feed.py           → certifica il feed (integrità, coerenza resample, spike, cross-venue)
  audit_feed.py             → audit per-barra vs riferimento esterno
  multi_source_check.py     → cross-check multi-venue (quale venue è "vero")
data/raw/                  → btc/eth × {5m,15m,1h} (gitignored). UNICO dato attivo.
data/instruments_registry.json → registry strumenti (reference)
docs/diary/                → diario di ricerca (1 voce: il reset; aggiungere dopo ogni esperimento)
Old/                       → ARCHIVIO: tutto il vecchio (strategie, live, ricerca, dati, diari)
VERSION                    → semver (2.0.0)

Comandi

uv sync                                                       # installa dipendenze
uv run python scripts/analysis/rebuild_history.py --asset BTC ETH   # (ri)costruisci storico da Deribit mainnet
uv run python scripts/analysis/certify_feed.py                # certifica i feed (locale + cross-venue)
uv run python scripts/analysis/certify_feed.py --local        # solo check locali (veloce)
uv run python scripts/research/trackD_trendport.py            # backtest strategia vincente (full report)
uv run python scripts/research/trackD_timing.py               # vincitrice su 15m/1h/4h/1d + PnL/DD/trade per anno
uv run python scripts/analysis/fetch_hyperliquid.py          # fetch+certify universo Hyperliquid (Cerbero mainnet) -> data/raw/hl_*
uv run python scripts/portfolio/xsec_research.py             # ricerca cross-sectional su Hyperliquid (XS01)
uv run python scripts/portfolio/run_portfolio.py             # report del PORTAFOGLIO attivo (TP01+XS01)
uv run python scripts/live/paper_portfolio.py               # avanza il paper del book TP01+XS01 (forward-only, 1d)
uv run pytest                                                 # test
from src.data.downloader import load_data
df = load_data("BTC", "1h")   # OK. load_data("SOL", ...) -> FileNotFoundError (guardrail: solo dati certi)

IL DATO — fonte di verità (regola di prim'ordine)

  • La verità è Deribit mainnet, perché è dove (in futuro) eseguiamo. Cross-check multi-venue: Deribit mainnet è a 0-1 bps dal consenso. Binance NON è la verità (è USDT, ~10 bps fuori, e sotto depeg USDT fino al 3% off) → usare Binance/Coinbase SOLO come audit indipendente, mai come ancora per "ripulire" i dati.
  • Aggiornare lo storico SOLO con rebuild_history.py (ccxt Deribit mainnet, base 5m unica + resample → coerenza interna garantita). MAI il vecchio downloader Cerbero (token testnet = feed farlocco: è la causa della contaminazione).
  • Certificare sempre dopo un rebuild con certify_feed.py (integrità OHLC, zero gap, coerenza resample maxΔ≈0, spike = solo crash reali, accordo cross-venue per-anno vs Coinbase USD).

Universo ricercabile certificato

  • BTC / ETH: puliti (2-6 bps vs Coinbase USD su tutta la storia), liquidi (~0% barre flat a 1h), storia lunga (2018/2019→oggi) → ogni timeframe (5m/15m/1h). È l'unico dato in data/raw.
  • Alt Deribit (SOL/XRP/ADA/LTC/DOGE/BNB): FUORI. Illiquidi (LTC 5m 82% barre flat, run ~3 giorni), divergenti, o non certificabili. Archiviati in Old/data/raw.
  • Universo Hyperliquid (Cerbero MCP MAINNET): 19 alt liquidi a 1d, dal 2024 — BTC/ETH/SOL/BNB/XRP/ DOGE/AVAX/LINK/LTC/ADA/ARB/OP/SUI/APT/INJ/TIA/SEI/NEAR/AAVE. Certificati (fetch_hyperliquid.py): flat 0%, cross-venue 4-9 bps vs Binance, >1% ≈0% → data/raw/hl_*_1d.parquet. Caveat: storia nativa solo ~2.5 anni (2024-2026; pre-2024 = backfill, vol 0). Abilita le strategie CROSS-SECTIONAL (impossibili a 2 asset). NB: Cerbero col token TESTNET = farlocco; col token mainnet (.env.mainnet) = reale, ma SEMPRE da certificare (cross-venue + liquidità). ⚠️ CORREZIONE estrazione (2026-06-20): il backfill NON è solo pre-2024 — cerbero MCP padda con barre SINTETICHE (volume 0, prezzi copiati da Binance → matchano cross-venue e non sono flat) ogni asset listato su HL dopo lo START. Il flat+cross-venue da soli non lo vedono: il rivelatore è il VOLUME. fetch_hyperliquid.py ora (1) taglia il run iniziale a volume 0, (2) scarta chi resta < 365g reali (es. AXS 83% sintetico → fuori), (3) gata i gap vol=0 interni. Universo certificato = 51 (era 52). I 19 major di XS01 hanno 0 backfill → invariati (strategia live non toccata). Verificato direttamente su cerbero MCP. Diario 2026-06-20-cerbero-backfill-fix.md.
  • CATENA OPZIONI REALE — RACCOLTA PROPRIA dal 2026-07-30 (cerbero-bite ASSORBITO e dismesso). /opt/docker/cerbero-bite (progetto separato) accumulava dal 2026-06-09 la catena Deribit mainnet BTC+ETH; è stato ELIMINATO il 2026-07-30 (container, volume, immagine e cartella rimossi, 12 GB liberati; codice conservato su Gitea Adriano/Cerbero-Bite, ultimo commit di dismissione) e la raccolta è passata dentro PythagorasGoal:
    • raccolta: scripts/live/collect_chain.py, cron 25 * * * * (scripts/cron_chain.sh) → data/raw/cb_chain/YYYY-MM-DD.parquet. Entrambe le ali, scadenze ≤95g, OI≥100, ~570 strumenti a giro, ~3 min. Minuto :25 scelto, non arbitrario: :00 era la raffica di bite, :07 è cron_book (feed 5m di SKH01, la cosa che non deve trovare l'IP occupato).
    • archivio ereditato: scripts/analysis/import_cb_archive.py (una-tantum) → cb_chain/bite_archive.parquet (1.23M righe, 2026-05-01+) e cb_market_snapshots.parquet (17.402 righe, 2026-03-26+: DVOL, RV30, funding perp e cross, dealer net gamma, gamma flip, rischio liquidazioni, giorni all'evento macro — dati che il progetto non ha altrove). Snapshot sqlite integrale in /opt/docker/backups/manual/cerbero-bite-20260730/ (SHA256).
    • certificazione: scripts/analysis/certify_cb_chain.py; harness scripts/research/cblib.py (load_chain() unisce archivio + raccolta, dedup su (ts, strumento)).
    • battuta di cuore: ogni giro scrive data/chain_collect/runs.jsonl, sorvegliato da monitor_health (cadenza 1h, max_age_h=3) — un collettore fermo non produce niente, e il niente si legge come "nessun dato quel giorno".
    • BACKUP (aggiunto 2026-07-30): data/raw/ è gitignored → la catena non è in git, e il backup rotativo della VPS non copriva PythagorasGoal. Aggiunta do_pythagoras a /opt/docker/scripts/backup.sh (daily 04:00, retention 7/28/185 g): salva solo il dato non ricostruibile — catena + contesto, data/paper_* e data/chain_collect (serie forward-only che alimentano i gate pre-registrati: non sono ricalcolabili), data/options_daily, data/live, venue_watch, fee_watch, config/live.json. ~28 MB. Esclusi di proposito i ~110 MB ricostruibili (rebuild_history.py, fetch_dvol.py, fetch_hyperliquid.py, fetch_ib_equities.py, cache). La funzione fallisce rumorosamente se la catena è assente o vuota, e verifica il tar prodotto (controllo positivo provato in entrambi i versi). ⚠️ /opt/docker/scripts non è un repo git: quella modifica vive solo su disco.
    • Dopo un riavvio della VPS la raccolta riprende da sola (cron di sistema enabled+active, nessuna dipendenza da docker o da cerbero-mcp: API pubblica Deribit diretta). Verificato con env -i che il giro funzioni nell'ambiente nudo di cron. Finestra scoperta: fino al :25 successivo, senza recupero — un'ora persa resta persa (il collettore non fa catch-up). TRE DIFETTI DI BITE NON REPLICATI (misurati il 30/07): (a) una chiamata per strumentoget_order_book?depth=3 dà già quote+greche+IV+OI+book+underlying, bite ne faceva due con rischio di disallineamento; (b) pacing (token bucket 4/s + backoff) invece della raffica — il carico non è mai stato il problema (~570 chiamate/ora = 0.16/s distribuite), bite le sparava in ~26s (~44/s) auto-saturandosi il rate limit per-IP; misurato sul nostro giro: 574 chiamate, 0 risposte 429; (c) quote_status esplicito in {ok, no_quote, error} — "book vuoto" (fatto di mercato) e "chiamata fallita" (fatto di infrastruttura) sono cose diverse, e book_depth_top3 è NULL su errore, mai 0. ⚠️ Le righe ereditate da bite hanno quote_status='unknown': bite non registrava il perché, e si dichiara l'ignoranza invece di inventare uno stato. 🚨 BUCO DI COLONNA nell'archivio ereditato, trovato il 2026-08-22 e mai registrato prima: bite_archive ha index_price e underlying_price 100% None (1.232.212/1.232.212). Il sottostante esiste solo dal 2026-07-30 (raccolta propria, 18,2% delle righe) e book_depth_top3 solo nel 67,2%. Chiunque calcoli moneyness o riprezzi sull'archivio pre-30/07 sta usando una colonna che non c'è — e il file si legge senza errori, quindi il difetto è silenzioso. Ed è CHIUDIBILE senza dato nuovo: il forward si ricostruisce con la parità put-call dalla catena stessa — verificato contro l'osservato su 6.578 coppie: |errore| mediano 0,023%, p95 0,147%, corr 1,000000 → rende la superficie utilizzabile su tutti i 75 giorni invece che 23. (Lo smile, che non richiede il forward, esiste invece su 113 giorni dal 2026-05-01; la superficie completa solo da 2026-06-09, perché prima bite raccoglieva una sola scadenza per giro — misurato da tre agenti indipendenti.) ⚠️ La famiglia raccolta è quella inverse (get_instruments?currency=BTC|ETH): la superficie USDC-lineare non è nell'archivio, e ogni conclusione su di essa nel progetto è oggi un controfattuale costruito sui mid inverse, non una misura. Puntare il collettore anche su currency=USDC costa +587 chiamate/giro (+90%) 🚨 CORRETTO 2026-08-23 (§51): sono +117 chiamate = +18%. Il 587 era il conteggio grezzo (1.140 strumenti USDC ≤ 95g = +81%) senza il filtro OI≥100 che il collettore applica davvero, e quel filtro taglia il 90% della famiglia USDC: con gli stessi filtri del collettore vivo sono 113 strumenti contro 649 inverse ( verificato al venue da due percorsi indipendenti; replica esatta di §8 — su Deribit USDC l'OI e la negoziabilità sono anti-correlati). Il giro passerebbe da 652 chiamate/163 s a 769/192 s, dentro la finestra del :25 e senza toccare cron_book al :07. Resta una decisione sul rate-limit per-IP, che ha già causato un guasto il 29/07 — ma di un ordine di grandezza più piccola di come era stata scritta, ed è un numero di oggi (cresce con la liquidità USDC, va ri-misurato prima di accendere). NON assorbito, e perché: il motore credit-spread ETH (il progetto ha già la regola "niente short-vol da modello in deploy"), la GUI, kill switch/dead-man/audit (PythagorasGoal ha venue_watch/edge_watch/monitor_health/fee_watch), dvol_history (fetch_dvol.py ha storia più lunga: 2020+ contro 2026-05), decisions/positions (59 righe a capitale $52, 0 posizioni). Test tests/test_collect_chain.py (11) + tests/test_cb_chain_vrp.py (13). ⚠️ Prima di cancellare la sorgente (verifiche nel diario 2026-07-30-assorbimento-cerbero-bite.md): snapshot completo e non solo integro (4 tabelle su 4 con conteggi identici al volume vivo e ai parquet); i 10,6 GB di backup interni non contenevano dati unici (stessa riga più vecchia in tutti gli snapshot + conteggi monotoni ⇒ nessuna potatura); zero dipendenze a runtime. ⚠️ cerbero-mcp è un progetto DIVERSO e serve a PythagorasGoal (Hyperliquid, percorso del conto) — resta acceso; la rete traefik che condividevano è external: nel compose di bite, quindi down -v non la tocca. REGOLA: prima di cancellare una sorgente si verifica che la copia sia COMPLETA, non che esista — un hash prova che il file non è corrotto, non che contenga tutto. Perché si MEMORIZZA invece di interrogarla: una catena opzioni non è ricostruibile a posteriori — Deribit non serve book storici, un'ora non raccolta è persa per sempre, e non c'è un secondo venue da cui recuperarla. Certifica 4 difetti: quote vuote, book incrociato, premio non monotono nello strike, depth==0 (ambiguo by design: chiamata fallita e book vuoto danno lo stesso valore → si riporta, non si ripara). ⚠️ GUASTO IN CORSO dal 2026-07-29 05:00 UTC — status QUOTE-VUOTE. Il collettore persiste la riga anche quando il ticker fallisce (rate-limit Deribit per-IP: ~650 risposte 429 in ~26s a ogni giro, 96% al minuto :00, generate dalla spazzata full-chain che si auto-satura) → bid/ask/iv/delta NULL e conteggio righe INVARIATO (13k/giorno prima e dopo). Tasso di quote vuote per settimana: 0.4·0.7·2.2·1.5·0.5·0.4·0.3 → 22%; giorno peggiore 51.7% BTC / 30.6% ETH. Risolto dal cambio di collettore (30/07): la raccolta propria è paced e ha fatto 574 chiamate con 0 risposte 429. REGOLA: una riga presente non è un dato presente — contare ciò che è QUOTATO, non ciò che è SCRITTO (3ª occorrenza dopo paper_dvolspread e fresh_5m). REGOLA: un guasto IN CORSO si misura al GIORNO PEGGIORE, non in media — la prima stesura confrontava "tutto" con "ultimi 7g" e diluiva un guasto di 2 giorni al 13.5%, commettendo a 7 giorni lo stesso errore che dichiarava di evitare a 3 mesi. Diario 2026-07-30-vrp-quote-reali.md.

Metodologia obbligatoria per ogni nuova strategia

  1. Ingresso eseguibile: direzione e prezzo decisi con dati fino a close[i], mai close[i-1] con direzione presa da i; mai entry sull'estremo (high/low) di una candela.
  2. Backtest NETTO dopo fee realistiche Deribit (0.10% RT taker; maker ~0%) + leva.
  3. Out-of-sample held-out + robustezza su griglia parametri (entrambi gli asset, tutte le celle positive) + sweep fee (0.00-0.20% RT, margine ampio).
  4. Liquidità & plausibilità (lezione v2.0.0): incrociare ogni edge con la liquidità reale del book (quota di barre flat) e con la plausibilità del prezzo (cross-venue). Un edge full+OOS robusto su un book fermo o su wick fantasma NON è un edge.
  5. Strategia in scripts/strategies/ (codice univoco), test in tests/, diario aggiornato.

Lezioni critiche (da NON ripetere — la storia di questo progetto)

  • Feed contaminato → libreria fasulla (v2.0.0). Print fantasma testnet + Binance/USDT hanno prodotto edge inesistenti (+201%/+1238%/+16492% "OOS"). Tutti spariti sul feed reale. Lezione: il dato viene prima della strategia; certificare sempre.
  • Look-ahead squeeze (storico). L'intera famiglia squeeze-breakout aveva accuratezze 76-82% che erano artefatto: decideva la direzione con la candela di breakout i ma entrava a close[i-1]. Con ingresso onesto: lancio di moneta. (Dettagli nei diari in Old/.)
  • Entry sugli estremi di candela. Strategie che entrano a close quando close è all'estremo del range (≤0.1% o ≥99.9%) gonfiano i ritorni in modo irrealistico (ETH 2024: +30.848% → +2.725% rimuovendoli). Spesso è un artefatto di dato o di entry non eseguibile.
  • Mean-reversion vs breakout. Sui dati storici l'unica direzione che mostrava edge era la mean-reversion (i breakout rientrano) — MA anche quegli edge erano per lo più artefatto del feed: da riverificare da zero su dati certi.
  • Fee = vincolo di prim'ordine. 0.10% RT baseline. Molte operazioni = morte per fee.
  • Leva: testare 3x; 5x raddoppia il drawdown. I numeri a leva alta NON sono il caso base.
  • Data leakage con rendimenti log: returns[k] = log(close[k+1]/close[k]) usa close[k+1]. I feature devono fermarsi a returns[i-2] se il prezzo corrente è close[i-1]. Verificare SEMPRE.

Convenzioni

  • Strategie in scripts/strategies/ con codice univoco; scartate documentate nel diario.
  • Diario in docs/diary/YYYY-MM-DD.md, aggiornato dopo ogni esperimento significativo.
  • Nessun segreto nei commit (token/chiavi). .env e .env.mainnet sono gitignored.
  • Versionamento: VERSION (semver) + scripts/bump_version.py. src/version.py lo legge.

Archivio Old/

Tutto il lavoro pre-reset (preservato in git per consultazione storica): strategie (Old/scripts/strategies), stack live e portafogli (Old/src/live, Old/src/portfolio, Old/scripts/portfolios), ricerca/gate (Old/scripts/analysis), dati non certificati (Old/data), 60+ diari (Old/docs/diary), test (Old/tests). Consultabile come riferimento ("come facevamo X"), ma nessun edge lì dentro è fidato finché non è ri-validato su dati certi.