2beb11b7649b80701c807782fa4f957870e5f8ef
353 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Adriano Dal Pastro
|
2beb11b764 |
fetch IB: client in readonly — via due righe d'errore da 63 notti su 63
`fetch_ib_equities.py` si connetteva senza `readonly`, e ogni notte il log del
cron si prendeva
open orders request timed out
completed orders request timed out
126 righe in 63 giri. Due errori innocui ripetuti per sempre sono il modo in cui
un errore VERO smette di farsi notare (P14): su `cron_daily.log`, 126 dei 146
match di "error" erano questi.
CAUSA, letta nel sorgente di ib_async e non indovinata: in `IB.connectAsync` le
richieste "open orders" e "completed orders" esistono SOLO se il client non e'
readonly (`if not readonly: reqs[...]`), e sul gateway paper non rispondono.
Questo client scarica storico e non manda ordini mai: `readonly=True` e' insieme
la cura del rumore e la dichiarazione corretta di cosa fa. Tolta la CAUSA, non
filtrato il messaggio — filtrarlo avrebbe nascosto anche il giorno in cui quel
timeout significasse qualcosa.
VERIFICATO con un A/B sul solo flag, contro il gateway vero:
· readonly=False -> le due righe compaiono, e si apre sul gateway il dialogo
modale "API client needs write access action confirmation" (visto nei log del
container, resta su ~75s);
· readonly=True -> nessuna delle due righe, nessun dialogo.
⚠️ CIO' CHE NON E' STATO VERIFICATO, e va detto: in nessuna delle quattro prove
fra le 13:05 e le 15:35 UTC il gateway ha servito storico — 0 barre con ENTRAMBI
i flag, quindi la causa non e' questa modifica, ma non ho potuto confermare
end-to-end che il fetch continui a riportare barre. La conferma e' il log del
cron di stanotte: se SPY/QQQ/IWM/TLT/GLD/HYG tornano con le loro barre e senza
le due righe di timeout, e' a posto; se tornano tutti a 0, si revoca il flag.
Il fallimento e' comunque innocuo: con 0 barre lo script NON sovrascrive i
parquet (verificato: eq_spy/eq_qqq intatti dopo i tentativi falliti).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
21fe289383 |
research(gtaa): cosa cambia togliendo GTAA01 — +0.11 di Sharpe a iso-rischio, sul filo
Misura chiesta prima di decidere del gate (A): se togliere lo sleeve non
cambiasse niente, la domanda sul gate sarebbe accademica. Portafoglio di
RICERCA a 5 sleeve (33/15/12/20/20), NON il book live (dove GTAA01 non c'e').
Due lenti, ed e' la seconda che decide (M6: un diversificatore a basso CAGR si
giudica a iso-rischio, mai a iso-nozionale; M5: "meno drawdown" si testa a
iso-rischio o si sta comprando de-levering):
· iso-nozionale: CON Sh 2.28 CAGR +19.2% DD 6.1% vol 7.8%
SENZA Sh 2.16 CAGR +23.8% DD 7.8% vol 10.1%
-> togliendolo si guadagna DRIFT e si compra VOLATILITA'.
· iso-rischio (×0.77): SENZA Sh 2.16 CAGR +18.0% DD 6.0%
-> Δ Sharpe +0.121, Δ maxDD +0.02pp.
Hold-out 2025+: Δ +0.247. Per anno: GTAA01 aiuta in 6/8. Correlazione col resto
del portafoglio +0.087 — e' davvero altro. Standalone Sh 1.06, CAGR +5.8%.
⚠️ E LA BANDA DI FASE, che e' la ragione per cui questo numero va citato con la
sua incertezza: il Δ sulle 5 fasi va da +0.095 a +0.124 e supera la soglia
dichiarata (0.12) in 2 fasi su 5. Il SEGNO e' stabile — GTAA01 aiuta in ogni
fase — ma il verdetto BINARIO dipende dalla notte in cui lo si legge. Sanity:
la fase 0 riproduce lo sleeve di produzione bit-exact (max|Δ| = 0.00e+00).
Lettura: il contributo e' reale e sempre positivo, e vale ~+0.11 di Sharpe, cioe'
ESATTAMENTE quanto lo spread fra le tre baseline che il progetto gia' si porta
dietro (0.12, §2). Non e' "GTAA01 e' inutile": e' "sta al limite di cio' che
questi dati risolvono".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
801bd13f10 |
allarmi: il marcatore "gia' detto" si scrive DOPO l'invio, non prima
Debito §5.2 chiuso su decisione dell'operatore. `run_once` salvava lo stato coi marcatori `alerted` gia' a True e l'invio lo faceva il chiamante DOPO: col 6,9% di invii falliti misurato (2 su 29), un 🚨 perso restava perso per l'EPISODIO INTERO — l'ora dopo lo stato diceva "gia' detto" e usciva WATCH/MUTO. Gli episodi storici durano 200-2.324 ore, quindi il buco non era teorico. - `run_once(state_path, sender=None)`: il sender e' INIETTATO, non importato — e' cio' che tiene la funzione testabile senza rete d'uscita, che era la ragione del disegno precedente. Senza sender il comportamento resta quello di prima e il report lo DICE (`invio`), invece di lasciar credere che qualcosa sia partito. - Su invio fallito si disfano SOLO i marcatori "gia' detto", non le misure: · asset in ALERT -> alerted=False, l'ora dopo ri-allerta; · lock MAINT/ALERT -> alerted_soft/hard=False ma le ORE restano a correre, cosi' una manutenzione che sfora la grazia sale ad ALERT anche col trasporto giu' (disfare anche le ore congelerebbe l'escalation proprio mentre non si riesce a parlare); · lock RIENTRATO -> si ripristina l'intero LockState, perche' il rientro si annuncia una volta sola e senza le ore non ci sarebbe piu' niente da dire. - `notify(..., tentativi=)`: il retry esisteva in `send` e non arrivava qui. venue_watch ora manda con 3 tentativi. - L'esito dell'invio finisce nel log del cron invece di sparire. 5 test nuovi. Il primo e' quello che conta — dopo un invio fallito, l'ora dopo ri-allerta — col suo controllo positivo (un invio riuscito consuma l'allarme UNA volta sola), senza il quale "ri-allerta sempre" passerebbe. Suite: 782 passati, 2 falliti (i due del gate GTAA, non toccati qui). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
c21a0d4058 |
research(gtaa): criterio (C) — la mediana delle 5 fasi regge come strumento, e sceglie il 60%
Analisi richiesta prima di decidere che fare del gate (A). Il criterio: a cadenza di produzione, la banda si sceglie sulla MEDIANA delle 5 fasi di ribilanciamento invece che sulla fase capitata (M7: su ancore appaiate la statistica e' la mediana). Toglie la componente di FASE; resta quella di DATO. ⚠️ DICHIARATO IN TESTA ALLO SCRIPT: (C) e' stato scelto DOPO aver visto la tabella delle fasi di r0828_gtaa_band_phase. Sceglierne uno nuovo guardando l'esito del vecchio e' selezione. Quindi (C) misura lo STRUMENTO — risoluzione e potenza — e NON valida la proposta del 27/07. Pavimento tenuto a 0.01, quello che il test si diede il 07/08: il metro non si ritocca sul risultato. ESITO, coi tre criteri calcolati a runtime: (i) scelta stabile su 10 notti : SI — ['60%'] in tutte e dieci (ii) margine sempre >= 0.01 : SI — minimo 0.0197 (fase singola: 0.0026, e sotto il pavimento in 4 notti su 10) (iii) potenza (in-sample ≠ hold-out) : SI — al buio 60%, sull'hold-out 40% Lo strumento funziona: l'escursione dello Sharpe in-sample su 10 notti cala del 74-99% per ogni banda (60%: da 0.1120 a 0.0006). MA LA CELLA CHE SCEGLIE NON E' LA PROPOSTA. Al buio esce il **60%**; il 25% vince **0 notti su 10**. Da tenere accanto: sull'hold-out il 60% e' penultimo (0.7430 contro 0.9315 del 40%), coerente con lo Spearman IS/OOS ~0 misurato il 07/08 — la scelta in-sample non predice, e non va letta come "la banda giusta". CONTORNO che vale piu' del verdetto: le 5 serie di fase correlano **0.988**, quindi N_eff = 1.01. La mediana di 5 fasi e' UNA osservazione: toglie l'artefatto, non compra precisione. Va citata come robustezza alla fase, mai come campione (§2: «positivo in N/N ancore NON e' N osservazioni»). Nessuna decisione presa qui: il gate (A) non e' toccato e i due test restano rossi in attesa della scelta dell'operatore. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
31f82e1730 |
research(gtaa): il gate (A) della banda e' una moneta — la finestra "congelata" rotola ogni notte
Il 28/08 falliscono `test_la_banda_proposta_e_quella_scelta_al_buio` e
`test_il_margine_del_blind_non_e_un_arrotondamento`, a codice fermo dal 07/08
(nessun commit su src/portfolio/gtaa.py ne' su r0727_gtaa_band_gate.py). Al buio
esce il 60% invece del 25%, con margine 0.0074 — sotto il pavimento di 0.01 che
il test si era dato. Questo script chiede, per la terza volta sullo stesso
parametro, se il criterio misura cio' che dichiara. Replica bit-exact della
produzione verificata a fase 0 / taglio 0 (max|Δ| = 0.00e+00 su 7.544 barre).
(0) LA FINESTRA IN-SAMPLE NON E' FERMA. IB serve una finestra ROTOLANTE di 30
anni. SPY e' l'unica gamba al muro (30.0 anni), e nel cron log la sua data
d'inizio avanza di un giorno di borsa ogni notte: 1996-07-02 il 24/06,
1996-09-04 oggi. Il pre-2015, che tutto il progetto tratta come finestra
congelata, perde il giorno piu' vecchio ogni notte. QQQ e IWM arriveranno
allo stesso muro fra 2,5 e 3,7 anni.
(1) L'AMPLIFICATORE E' LA FASE. `_gated_returns` ribilancia su `i % every == 0`,
indice di POSIZIONE nell'array: se la prima barra scivola, si ri-fasa ogni
decisione di trent'anni. Il progetto sapeva che la fase conta
(`r0726_loo_deluck.gtaa01_at(ph)`, 5 ancore) ma la assumeva fissa alla
canonica 0. Non lo e': la fase canonica cambia da sola ogni notte.
MISURE. Sulla finestra CHIUSA pre-2015, che non puo' acquisire dati nuovi, lo
Sharpe si e' mosso fino a 0.0760 fra il 07/08 e oggi. Su 10 notti consecutive
la banda scelta al buio e' 25% / 40% / 60% — la proposta vince il 40% delle
notti — e il margine sta sotto il pavimento in 4 notti su 10 (minimo 0.0026).
A dato FISSO, muovendo la sola fase, il verdetto cambia lo stesso (25% su 3
fasi, 60% su 2): l'imputato e' la fase, non le barre perse.
VERDETTO calcolato a runtime coi criteri dichiarati in testa (M13): il gate (A)
NON ha risoluzione. Il verdetto non e' una proprieta' della banda, e' una
proprieta' della notte in cui lo si legge. La banda al 25% non e' ne' confermata
ne' smentita: non e' decidibile cosi'.
Lo script misura e basta. Ritirare il criterio, come si fece il 07/08 col
confronto fra ranghi, e' una decisione dell'operatore e non e' presa qui.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
e5052a690f |
usde: da patch d'emergenza a struttura — config, modulo unico, sorveglianza
- config/live.json sezione `usde` (unica autorita', P1): indice, haircut 10%, tetto allerta quota 50%, soglie depeg 0.99/0.95 coi criteri dichiarati (P6) - src/live/usde.py: config + catena di prezzo (indice pubblico -> ticker -> 1.0 dichiarato) + valutazione PURA; shadow._collaterale_usde ora deriva da qui - scripts/live/usde_watch.py + cron_usde.sh (12:35 UTC, dopo la finestra reward): reward per delta netto trade (P12: senza inventare attribuzioni), depeg (crit ripetuto, resto a transizione, P9), quota anche per deriva passiva (N4); applica il verdetto di eligibilita' pre-registrato (>=1 reward entro 29/08) - serie data/live/usde_watch.jsonl sotto monitor_health (max 30h, P5: un watch fermo non deve leggersi come "va tutto bene"); baseline 14:17Z registrata - GATE USDE-01 in CLAUDE.md §4; test 775 (+17 in tests/test_usde_watch.py) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
562e95338b |
ricerca: USDE come collaterale a rendimento — analisi da candidato + test di eligibilita' pre-registrato
Verificato sul venue: apr 4.0 (netto fee), spot USDE_USDC spread ~3bps fee zero, haircut 10% (non morde al nostro profilo di leva), indice usde_usd multi-exchange con mediana+clamp (la differenza strutturale dal caso Binance 10/10/2025). Rischi dichiarati R1-R4, p non stimabile -> la leva di controllo e' la QUOTA (N4). Aritmetica: a $5k/quota 50% ~$101/anno; -100% = 25 anni di resa, non si recupera. Pre-registrato il test di eligibilita' (~$500, 3 giorni, regola dichiarata prima). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
3034bfdc58 |
gate XSR01: riscrittura DICHIARATA (opzione A dell'operatore) + haircut con script
Decisione operatore 26/08, a 58 giorni dall'esito, in direzione che stringe: (1) capitale deploy $5k -> $20k — riconcilia il gate (25/07) con la decisione vincolante "100% Deribit fino a $20k" (26/07), posteriore, che governa (M28); deploy XSR01 e scelta del venue ora coincidono in un punto solo. (2) gamba haircut: numero decisivo da r0826_xsr_haircut.py (N11) a pavimento $10 (il vero, HL-EXEC), citato con la frazione di ordini eseguiti (P7). Misurato: FULL 968 barre floor $10 -> haircut -1,1% con 22% di eseguiti (la guardia da sola era vacua: un libro fermo ha haircut piccolo); ticket mediano $3,34/gamba, 84% sotto $10 — sostituisce il "$14,41" senza script. (3) contesto 1.82 -> 1.79 (lente dei gate). Soglie numeriche INVARIATE. Chiude il debito S5.3. Diario 2026-08-26-xsr01-gate-riscritto.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
d597fc64e8 |
monitor: advance() consuma solo barre CHIUSE — serie rigenerate, guardia PREMATURO, 4 debiti chiusi
S5.1 RIPARATO E RIGENERATO. Filtro condiviso src/live/paper_guard.py (barra open-labeled chiusa = ts + cadenza <= adesso) importato da tutti e 6 i monitor; serie rigenerate dallo stesso start_ts con scripts/live/paper_regen.py (evidenza in *.pre_regen_20260826.*): statarb +1,95 -> -1,61 (il ribaltamento del gate 27/09 previsto dall'audit), dvolspread -14,73 -> -4,41, xsr -4,98 -> -2,72, prevday invariato. Nessuna data di gate si sposta. Guardia cablata in monitor_health: stato PREMATURO (ultima barra che chiude dopo l'mtime, grazia 5 min, open_labeled=False per collect_chain) — sul dato vivo segnala i 5 rotti e tace sui 2 sani; dopo la rigenerazione 7/7 OK. paper_portfolio non rigenerato (GTAA su ADJUSTED_LAST: replay != serie registrata, P12), tolta la coda non chiusa. D6 pagata di nuovo nel fix: asi8 in pandas 3 e' in us, non ns — blindata con test su tre risoluzioni. S5.12 ESTESO: conftest devia anche trades.db (wrapper su connect: il default e' catturato alla definizione) e docs/journal/; book_executions.jsonl sorvegliato con impronta inizio/fine suite. S5.5 FATTO: test_leva_massima cancellato con nota (misurava frac*n_asset: con una chiave di scala avrebbe continuato a passare smettendo di controllare). S5.9 INDAGATO E RIPARATO (r0826_skh_band_drift): il dato regge (taglio 02/07 riproduce l'audit 1,6376, in-sample identico su ogni taglio); la deriva era la finestra hold-out — e la sola settimana 15-22/08 vale +0,35 di Sharpe hold-out. Il test ora taglia il feed al 02/07 e verifica la riproduzione stretta. Suite: 751 passati, 0 falliti. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
f10d847816 |
ricerca: XSR01 sotto la lente RENDITA (filone 70) + cosa compra un versamento da $3k
XSR-RENDITA (r0825_xsr_rendita.py): prima valutazione di XSR01 sul criterio della perpetua. A iso-nozionale alza il muro; a iso-rischio lo abbassa del 20,6% MA il null mostra che il meccanismo vale 0,8% (mescolare i rendimenti non cambia nulla) e un conto remunerato allo stesso tasso lo eguaglia a vol zero senza secondo venue. A drift zero il muro SALE: si compra un drift scorrelato, non la scorrelazione. L'haircut non pareggia un conto al 4% nemmeno a zero. Vincolo binding: capitale ($60k per un 25% sopra C*). Corretta in CLAUDE.md la riga Sharpe 1,82 (terza lente; la lente dei gate da' 1,79 alla scoperta / 1,56-1,63 a oggi). VERSAMENTO-3K (r0825_versamento_3k.py): $2.065 -> $5.065 appaiato sugli stessi path del piano = 5,5 mesi di versamenti anticipati; 10a $114.929 -> $122.491 (+6,6%); $15k in 1,3a e $20k in 1,9a. P(cap >= $5k al gate XSR01 del 23/10): 0% -> 100% -- il lump rende il gate leggibile senza rendere XSR01 comprabile: la decisione sulle soglie (S5.3) va presa PRIMA che il lump atterri. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
ee5c6ed539 |
ricerca: il piano a 10 anni dal conto vero, l'ETF-quando-flat SCARTATO, slippage rifatto
Giornata partita da "stato trades" e finita sul disegno del sistema. Versamento di 1.400 USDC atterrato alle 11:03:35Z (equity $667,88 -> $2.066,88); il giro delle 11:47 ha ribilanciato correttamente e ha ripiazzato i disaster-SL alla taglia nuova -- prima volta che il ramo riparato stamattina gira sul serio. (1) PIANO A 10 ANNI DAL CONTO VERO -- r0825_piano_10a_500.py (nuovo) Le tabelle pubblicate partono da $600/$635: rifatte su $2.067, lente L3 CONGIUNTA. Replica superata: chiede EUR 1.718/m dove la tabella da $635 chiedeva EUR 1.733. EUR 500/mese per 10 anni -> mediana $114.934, rendita 18,35 EUR/g, P(>=50 EUR/g) = 0,0% su 3.000 traiettorie. Il bersaglio con EUR 500/m arriva al 17o anno. L'EQUIVALENZA CHE ORDINA IL PIANO: EUR 100/mese in piu' == +4,07%/anno di drift, cioe' +27% su TUTTO il drift del libro. A 10 anni i bonifici fanno il 59%. Tutta la leva autorizzabile vale quanto EUR 100-150/mese: k=1,25 (+15,6%) vale MENO di EUR 100/mese in piu' (+19,1%), e si porta dietro il peggior giorno al 21,48%. E il libro a k=1 rende MENO dell'S&P (15,19% vs 17,40%): il vantaggio sta nello Sharpe (1,35 vs 0,89) e senza leva NON si converte in rendimento. Senza leva il libro non si giustifica come veicolo di ACCUMULO -- si giustifica come veicolo di RENDITA, dove serve 2,5x meno capitale ($254k contro $646k) perche' la perpetua vive sul DD. (2) "ETF QUANDO IL LIBRO E' FLAT" -- SCARTATO, r0825_capitale_fermo.py (nuovo) Il libro e' flat il 28,0% dei giorni (2,7% nel 2021, 77,0% nel 2022, 75,6% nel 2026); live, esposto 14 giorni su 64, leva lorda mediana 0,00x e max 0,52x su un tetto di 1,0x -- il cap non ha mai morso, il vincolo e' il segnale. A ISO-RISCHIO il dinamico PERDE: Sharpe 1,01 contro 1,40 del 50/50 e 1,35 del libro. E il null a maschera casuale (400 estrazioni, stessa quota, blocchi 20g) lo mette al 30o percentile: fa PEGGIO di commutare a caso. A iso-nozionale sembrava vincere (drift 17,09%, il piu' alto) perche' aveva la vol piu' alta: e' la trappola di M6, il de-levering e' il PRIMO test. E IL MECCANISMO CHE SEMBRAVA OVVIO NON ESISTE. Aggregato: SPY 4,91% nei giorni flat contro 21,48% negli altri (-16,57%), e la storia si scrive da sola. FALSA: scomposta per anno il segno ALTERNA (3 su, 4 giu') e il 2022 -- l'anno che doveva reggerla -- ha il segno OPPOSTO. Artefatto di composizione: i giorni flat stanno negli ANNI brutti per l'azionario, non nei GIORNI brutti. M9 ha fatto il suo lavoro su di me. (3) SLIPPAGE RIFATTO ALLA TAGLIA VERA -- r0822_slip_audit.py riparato 26 fill (erano 18), $6-$319. I due piu' grandi mai eseguiti sono di oggi e hanno preso 1,01% e 0,54% della loro barra 5m, con il print a meta' del range (q=0,50). Il caso peggiore resta un fill da $74 del 18/07 al 21,9%: un sabato, nastro inesistente. L'attrito non e' funzione della TAGLIA ma di taglia/volume-della-barra -- l'estrapolazione lineare che prevedeva ~71% a questo capitale e' refutata dalla misura diretta. NB non e' "assente", e' "non ancora testato": manca un fill grande in una barra sottile, e il weekend e' dove TP01 fa il 38% del proprio gross. DIFETTO P1 RIPARATO: l'equity era CABLATA a 636.0 con un commento che diceva di leggerla dal watermark. Il giorno del versamento avrebbe stampato $636 sbagliando di 3,3x proprio la sezione che esiste per dire QUANDO la misura scade. Riparata leggendo il watermark -- e poi riparata di nuovo, perche' i fill del campione sono stati eseguiti a conti diversi ($597-$2.067) e una base sola e' sbagliata comunque la si scelga. Ora la normalizzazione e' PER FILL, e a $600 riproduce il 22,0% originale. DUE ERRORI MIEI, CATTURATI PRIMA DI PUBBLICARLI - maschera VUOTA vestita da risultato: la prima stesura di r0825_capitale_fermo prendeva i giorni flat dalla serie DE-LUCKATA, ma `deluck` sottrae una costante e lo zero esatto sparisce -> maschera vuota, dinamico identico al book, e lo script ha stampato tabelle piene e un p-value. Lo ha rivelato solo la riga "0 = 0.0%". REGOLA: stampare la CARDINALITA' di una maschera prima di usarla. - il meccanismo falso della (2), demolito dalla scomposizione per anno. Suite: 730 passati, 1 fallito -- quello gia' noto di 5.9 (deriva dati, non codice). Watermark del libro live sopravvissuto intatto alla suite (fixture autouse di stamattina). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1 |
||
|
Adriano Dal Pastro
|
426735448e |
live: diagnosi del guasto venue, disaster-SL scoperto, isolamento per asset, cron :47
Nato da "stato trades" durante una manutenzione Deribit (system_maintenance 11051,
08:57-09:20 UTC). Contati i log invece che ricordarli: 1.499 giri dal 23/06, 3 con
manutenzione, 5 traceback duri — e 4 dei 5 sono il NOSTRO gateway, non il venue.
Le release Deribit escono il martedi' alle 09:00 UTC: il cron al :07 ci cadeva dentro
per costruzione (21/07, 11/08, 18/08, 25/08).
DIAGNOSI (src/live/venue_probe.py, nuovo)
Sonda l'API PUBBLICA Deribit senza gateway e senza credenziali, e classifica il guasto:
VENUE_MANUTENZIONE / VENUE_GIU / GATEWAY / IGNOTO. Prima ogni causa stampava la stessa
riga ("conto non leggibile (offline)") con nota di diagnosi CABLATA — P4 violata, e il
18/08 il codice 11051 era gia' dentro il processo senza arrivare a chi decideva la
gravita'. Parte solo dopo un guasto: sul percorso sano costa zero. P1 rispettata: la
firma 11051 si importa da venue_watch.is_maintenance, non si ridichiara.
P9: la manutenzione dentro lo slot declassa il titolo a info, ma solo su EVIDENZA della
sonda (mai sull'orologio) e solo dentro la durata annunciata — oltre, RIALZA. Un gateway
rotto di martedi' mattina resta al massimo.
DISASTER-SL SCOPERTO (src/live/execution.py)
ensure_disaster_sl cancella i bracket incoerenti PRIMA di ripiazzarne uno: fra le due
chiamate la posizione e' senza stop. Se il ripiazzamento sollevava, l'eccezione risaliva
a main() e il guasto peggiore aveva la faccia di un errore qualunque. Ora: due tentativi,
poi stato `naked`, distinto da `place-failed` (P5). Non e' "non sono riuscito a
proteggere": e' "ho tolto la protezione e non sono riuscito a rimetterla" -> allarme
massimo, mai declassato. La SEQUENZA non e' stata invertita: piazza-poi-cancella sembra
piu' sicuro ma "sembra" non basta con soldi veri senza misurarlo.
ISOLAMENTO PER ASSET (scripts/live/book_execute.py)
Il 21/07 un 502 dentro ensure_disaster_sl su BTC ha ucciso il giro intero: nel log ETH
non compare — ne' ribilanciato ne' verificato nella protezione. Ora un asset che esplode
non ferma il ciclo, e il giro degradato esce con codice 2.
CRON :07 -> :47
Il vincolo vero non era ":07" ma "fuori dai ~26s del minuto tondo" (rate-limit per-IP
auto-saturato dal collettore catena, misura del 30/07). Il :47 lo soddisfa e in piu' sta
fuori dallo slot di release. PREVISIONE DICHIARATA (M12): 3 delle 4 finestre osservate
sono rientrate entro l'ora -> il :47 ne avrebbe scavalcate 3 su 4; se martedi' prossimo
becca comunque la manutenzione, la previsione e' sbagliata.
WATERMARK AVVELENATO DAI TEST (tests/conftest.py, nuovo)
Trovato addosso: lanciando la suite, data/live/equity_seen.json passava a $5.000 e il giro
successivo mandava un allarme Telegram FALSO ("USCITA DI FONDI -86,6%"). Non cosmetico:
cap_fallback = min(cap_config, watermark x frac) sarebbe passato da $334 a $2.500/asset,
~7,5x di leva su un conto da $668, sul ramo eq_fallback che allerta e NON blocca — cioe'
i test potevano armare il pericolo che il watermark esiste per impedire. Riparato con una
fixture AUTOUSE, non per-test: chiedere a ogni autore di ricordarsene ha gia' perso il
26/07 e il 21/08. Resta esposto lo stesso errore su trades.db e book_executions.jsonl.
BLOCCATO, NON RINVIATO
Il fallback diretto ai privati Deribit richiede chiavi API create dall'operatore: in
locale esiste solo CERBERO_TOKEN. Il gateway resta un punto singolo di guasto non
aggirabile (CLAUDE.md 5.11). La sonda dice di chi e' il guasto, non lo aggira.
Test: 20 nuovi, nessuno tocca la rete; controllo positivo fatto (5 su 7 falliscono contro
il codice vecchio). Suite 730 passati, 1 fallito — quello gia' noto di 5.9 (deriva dati).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1
|
||
|
Adriano Dal Pastro
|
2751a7efd0 |
journal: la voce del giorno IN CORSO non si presenta piu' come una giornata
cron_daily (00:30 UTC) faceva DUE chiamate al giornale: chiudeva IERI (giusto)
e apriva OGGI. La pagina di oggi nasceva con ~30 minuti dentro e nessuno la
aggiornava fino alla notte dopo.
Il difetto non era il dato mancante: era che la pagina non lo diceva dove si
legge. Aveva TUTTE le sezioni di una chiusa -> passava ogni controllo di
completezza e freschezza, e la parzialita' stava solo in §Salute, quinta
sezione su otto. Stessa famiglia di "una barra presente non e' una giornata
presente", in veste nuova: la pagina e' presente, il giorno no.
Taglia misurata sul caso reale di oggi: la pagina congelata alle 00:37 diceva
"giorno: $+0.54 (1 letture)" e la regola [pnl] chiosava "senza operare". Alle
08:54 il libro aveva fatto 3 fill, 2 round-trip e +$25.86 ($642.56 -> $667.88).
Avrebbe raccontato una giornata ferma per tutta una giornata operativa.
Riparato in due pezzi indipendenti:
1. la pagina dichiara la parzialita' nel TITOLO e nella prima riga —
"PARZIALE (giorno in corso)", copertura esplicita (N giri su 24), il fatto
che non si aggiorna da sola, e quali numeri sono di quella frazione;
2. tolta la seconda chiamata dal cron. In docs/journal/ restano solo giorni
chiusi; lo stato corrente si prende da journal.py a mano (pagina marcata)
o da trades.db, che cron_book sincronizza ogni ora.
Scelta dichiarata: NON si rigenera ogni ora. Costerebbe una riga in cron_book
ma riscriverebbe un file tracciato da git 24 volte al giorno per un consumatore
che non esiste (l'analista legge il giorno chiuso). Se un domani servisse, la
strada e' RIGENERARLA, non congelarla: e' scritto nel commento del cron.
Prove (test_journal 28 -> 31): una accende la marcatura, una la tiene spenta su
un giorno chiuso (una marcatura sempre accesa non si legge), una e' guardia sul
SORGENTE di cron_daily.sh — ogni chiamata a journal.py deve avere --giorno
esplicito, perche' senza argomenti scrive OGGI.
Regolare docs/journal/2026-08-25.md rigenerato: ora si dichiara PARZIALE (9/24).
NON riparato, e registrato come debito aperto in CLAUDE.md §5:
test_wave_0726::test_t1_canonical_riproduce_il_backtest_ufficiale fallisce, e
falliva gia' prima di questa modifica (verificato con git stash sull'albero
pulito). Sharpe hold-out SKH01 canonical 1,9223 contro la banda cablata
1.3 < h < 1.9: il codice non e' cambiato, sono cambiati i dati (data/raw e'
gitignored, il cron lo ricostruisce ogni notte). La banda NON e' stata
allargata — lezione 07/08. Suite: 710 passati, 1 fallito.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
782c0ce4bc |
analista: manda l'analisi giornaliera su Telegram, con l'esito registrato
La notifica porta una testata coi numeri che si leggono senza aprire nulla
(equity, delta del giorno, cumulato, posizioni, leva, fill e round-trip) e
sotto l'analisi del modello.
Il trasporto Telegram e' pero' il punto singolo di guasto gia' misurato in
questo progetto: un tentativo, nessun retry, esito mai registrato, 6,9% di
invii persi (2/29). Su un messaggio al giorno sono ~25 messaggi persi
all'anno, quindi qui sono state fatte due delle tre riparazioni dichiarate
il 2026-08-23 e mai eseguite:
(a) `send(text, tentativi=1)` — retry OPZIONALE con backoff. Il default resta
1, cosi' il comportamento e' invariato per tutti i chiamanti esistenti:
alzarlo per tutti cambierebbe la latenza degli allarmi di venue_watch e
book_execute su un percorso con soldi veri, e non e' una modifica da fare
di straforo dentro un'altra funzionalita'. L'analista chiede 3.
(b) `ultimo_errore()` — il motivo si registra nel punto in cui l'eccezione
veniva ingoiata, e NON sopravvive a un invio riuscito. Regola gia'
codificata il 29/07 su un altro percorso e mai applicata al notifier.
La terza (marcare `alerted=True` solo a invio riuscito in venue_watch) cambia
il comportamento degli allarmi e resta una decisione dell'operatore.
L'esito finisce nel DB in tre stati: inviata / non configurato / FALLITA col
motivo. Un invio perso che non lascia traccia, il giorno dopo, non si
distingue da "non e' successo niente".
E se l'analisi manca, il messaggio parte lo stesso dicendo PERCHE': senza
quel ramo un guasto del modello si leggerebbe come una giornata senza nulla
da dire. Taglio a 4096 caratteri dichiarato, mai silenzioso; HTML del modello
neutralizzato.
708 test passano. Strategia, pesi, config INVARIATI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
f5d9409213 |
analista di bordo: un modello scrive la prosa del giorno, in un campo suo
Aggiunto il quarto livello della pagina, tenuto separato dagli altri tre: numeri -> misurati dal feed e dal DB Lettura -> regole deterministiche, ognuna col suo id Analisi -> questo: prosa di un modello, che puo' sbagliare Nota -> l'operatore NON scrive dentro `nota`, che era la richiesta letterale: quel campo e' dell'operatore, ed e' cio' che a rileggere il giornale fra sei mesi permette di sapere chi ha scritto cosa. L'agente ha `analisi`, marcato col modello, con l'ora e con l'esito del controllo sui numeri. Gira via `claude -p` (verificato con env -i che risponda nell'ambiente nudo di cron), una chiamata al giorno sul giorno CHIUSO, tolte le tool. Tre guardie, una per ogni modo in cui una prosa generata rovina un registro: - NUMERO INVENTATO: numeri_non_supportati() estrae ogni cifra dall'analisi e verifica che compaia in cio' che il modello ha ricevuto. Oltre tre numeri liberi l'analisi e' RIFIUTATA e la pagina resta senza. E' un controllo debole per costruzione, e lo dichiara: prende l'invenzione, non il ragionamento sbagliato. - COMMENTO DI SE': senza_analisi() toglie dalla pagina la sezione dell'agente prima di dargliela. Al primo giro reale il modello aveva letto la propria uscita precedente e prodotto un paragrafo sull'avviso che si era preso il giorno prima — un ciclo di retroazione che in poche settimane avrebbe riempito il giornale di meta-commento, e che nessun controllo automatico puo' distinguere da prosa valida. - ANALISI DI IERI SPACCIATA PER OGGI: se il modello non risponde, la pagina resta VUOTA e il perche' viene registrato (stato + motivo). Il silenzio non diventa continuita'. Corretto anche un falso positivo mio: il tripwire validava sulla sola pagina mentre il prompt include anche il blocco storico, quindi bocciava un'equity vera. Una guardia piu' stretta del contratto produce allarmi che si impara a ignorare. Ogni guardia ha un test in entrambe le direzioni. 695 test passano. Strategia, pesi, config INVARIATI. Nessun ordine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
10c373075c |
libro di bordo: DB dei trade allineato col tempo + giornale giornaliero
I trade erano salvati, ma non allineati col tempo: book_execute.py scriveva ts_utc = pd.Timestamp(r['last_data']), cioe' la data della BARRA DI SEGNALE. 19 righe su 19 a 00:00:00, e un trade (ETH 0.04 @ 1869.74) registrato SEI GIORNI prima di essere eseguito — fill vero 2026-07-14T14:00, scritto 08/07. L'ora vera esisteva solo in logs/cron_book.log, che e' gitignored, fuori dal backup e ruotabile: la cronologia reale del libro live viveva in un file che una rotazione avrebbe cancellato senza che nessuno se ne accorgesse. - src/live/tradesdb.py: parser del cron log (ora vera + contesto del segnale), FIFO con fee pro-quota, riconciliazione a tre fonti, sqlite in data/live/ (dentro il perimetro del backup). Le tre fonti si INCROCIANO e non si sovrascrivono: reconcile() riporta le divergenze e non ripara niente da solo. Il venue e' autorevole ma TRONCA (1 trade su BTC, 0 su ETH): dichiarato. - scripts/live/trades_db.py: --sync (idempotente, in cron_book ogni ora), --report, --reconcile. - src/live/journal.py + scripts/live/journal.py: una voce al giorno in docs/journal/YYYY-MM-DD.md — mercato (ritorni, RV30, TSMOM sugli orizzonti di produzione, DVOL con eta'), libro (TP01/SKH01, target, posizione, leva), P&L (equity del venue come autorita', scomposizione locale), salute. NIENTE narrativa automatica: il campo `nota` e' l'unico posto per il testo libero ed e' dell'operatore, mai riscritto da un ricalcolo. - book_execute.py: ts_utc = ora vera del fill, bar_ts = barra. Test di regressione sulla sorgente: se qualcuno rimette last_data, il test lo dice. - 62 voci di giornale ricostruite dall'arming a oggi. Tre difetti trovati dai test mentre scrivevo, non a occhio: il renderer cadeva in KeyError se mancava il blocco mercato (un giornale che non si scrive non e' un giornale); "24 giri attesi" su un giorno IN CORSO produceva un allarme a ogni esecuzione; e libro e P&L leggevano due istanti diversi, quindi la stessa pagina mostrava due equity. Strategia, pesi, config INVARIATI. Nessun ordine. 659 test passano. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
8c0b5f97ee |
registro: chiusi §58-69 — dodici verdetti, 0 candidati, e due appoggi tolti a decisioni gia' prese
I dodici filoni della sesta ondata erano rimasti `_in corso_`: la sessione si e' chiusa dopo che gli agenti avevano scritto gli script e prima che i verdetti fossero consolidati, e i loro messaggi finali sono persi. I numeri qui NON vengono da quei messaggi: vengono dalla riesecuzione dei dodici script (07:38-08:06 UTC, sequenziale, log in logs/r0823b/ che e' gitignored). E' il motivo per cui l'ondata non e' andata persa: ogni script calcola il proprio verdetto a runtime. Cosa tocca decisioni gia' prese: - §67 il gate pre-registrato XSR01 del 23/10 legge un monitor tarato sul pavimento del venue sbagliato (C* $15-20k, non ~$3k) - §64 la raccomandazione di §51 (raccogliere la catena USDC) non e' giustificata dalla ragione che porta: le due superfici sono la stessa - §60 la politica MISTO scelta il 25/07 non e' piu' l'ottimo (oggi MISTO-A) - §63 domanda fiscale NUOVA, diversa da quella aperta il 07/08 Il risultato piu' grande e' di §58: l'obiettivo del progetto ha DUE definizioni operative in uso che danno 33,9% contro 0,33% sulla stessa domanda, e non era mai stato detto quale si stesse ottimizzando. r0823b_quasi_passati.py (§68) terminava con IndexError: Griglia.combo() indicizzava con self.idx (2720 giorni) un sottoinsieme di 958 righe. Corretto col parametro idx esplicito piu' un controllo di lunghezza; la rinormalizzazione e' riga per riga, quindi i valori sono quelli dell'intento dell'autore. La correzione e' del coordinatore, non dell'autore, ed e' dichiarata nel registro. Libro, pesi, cron, config INVARIATI. Nessun ordine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
37c83c11c9 |
critico di chiusura: il muro $313k e' una mediana con banda [$187k, $1,14M], e «N/N ancore» vale ~2 osservazioni
Ultimo agente dell'ondata 2026-08-22/23. Sola lettura, nessun file di produzione toccato.
Attese a priori dichiarate nel docstring: A1/A4/A5/A6 confermate, A2 e A3 REFUTATE.
REPLICHE (prima di ogni accusa, tutte riuscite):
- libro 75/25 path live: drift 19,23%/17,07%, Sharpe 1,692/1,513, funding -2,1597%/anno
- i quattro muri L0/L1/L2/L3 riprodotti al dollaro: $278.033 / $264.373 / $327.617 /
$313.143, e il muro E' esattamente `prelievo / perpetua`
- §42 dShFULL(floor=-1) all'ancora 0 = -0,4502 (pubblicato -0,450)
- TP01 canonico ShFULL 1,305; XS01 fase 0 == sleeve di produzione a max|diff| 0,0
- funding ri-misurato da implementazione indipendente: TP01 2,138%/anno, rapporto
condizionale 1,93x (BTC) / 2,58x (ETH) contro il pubblicato 1,86-2,55x
TROVATO:
1. Il muro $313k non ha mai avuto una banda. Propagando SOLO la SE del drift (5,151%/anno,
block bootstrap; §53 la misura 5,09 su altra lente) va da $204k (+1 SE) a $707k (-1 SE),
p10-p90 [$187k, $1,14M], e a -2 SE il traguardo NON esiste a nessun capitale. La riga
«EUR500/mese -> P(20a) 85%» diventa ~0% a -1 SE. L'ondata ha pubblicato la risoluzione
Monte Carlo del muro (0,7%) e mai quella del suo input, che e' 100x piu' grande.
2. «positivo in N/N ancore/fasi» non e' N osservazioni: N_eff misurato 1,6-2,1 (24 ancore
TP01, corr 0,63) e 1,2-1,5 (10 fasi XS01, corr 0,79), con controllo positivo 24,5 / 1,00.
La componente comune NON si cancella nella differenza appaiata (corr 0,59) -> A3 refutata.
E la banda d'ancora non e' un IC: per la stessa grandezza l'IC95 bootstrap e' 4,3x piu'
largo e contiene lo zero. I verdetti reggono, la precisione dei numeri no.
3. Tre baseline diverse sotto lo stesso nome «libro 75/25»: 1,68 (hourly, tutti i muri),
1,80 (canonical, §41/42/49/50/54), 1,63 (mediana d'ancora, §8/25) — spread 0,12 di Sharpe
e 1,7pp di maxDD, piu' grande di quasi tutti gli effetti misurati.
4. «Soffitto direzionale ~1,15» contro 1,639 (§23) e 1,621 (§54) nella stessa ondata: seconda
refutazione indipendente dell'argomento aritmetico di §12.
5. «EUR X/mese» versa ogni 30 GIORNI (12,17 versamenti/anno, +0,8-1,4%); e il contatore
`versato` non si ferma al traguardo -> a 10 anni i bonifici fanno il 61%, non il 73%.
6. MDE: la catena opzioni misurata da me da' 77 giorni di superficie (registro 74-75, ok)
= MDE 4,3 di Sharpe -> ogni SCARTATO di §4/§5/§7/§11 che poggia su uno Sharpe e' un
non-risultato su quell'asse. §21 XS01-OOS, pilastro del canale funded, ha effetto +1,12
contro un MDE di 1,13.
7. Errore mio catturato in sessione: la prima stesura de-luckava una serie gia' de-luckata
(0,89^2) e stampava un finto +31,5% sul muro; il valore vero della scelta di modello e'
+4,0%.
RISPOSTA AL MANDATO: no. La somma di TUTTI i lead positivi dell'ondata, se fossero
autorizzati e additivi (non lo sono), vale +0,036 EUR/giorno a $635. EUR250 -> EUR500 al mese
porta P(20a) dal 14% all'85%. Il valore dell'ondata e' difensivo ed e' reale; il mandato
«arrivare ai 50 giornalieri velocemente» ha risposta negativa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
73207f79b9 |
research(costo-capitale): il costo d'esecuzione e' una funzione del capitale, e il muro non si muove — a $635 il vincolo e' il pavimento min_order, di segno opposto
§55 COSTO-CAPITALE. Tutti i muri pubblicati ($272k/$278k/$313k/$325k, traiettorie, versamenti) sono calcolati con un costo d'esecuzione COSTANTE, mentre un muro che si raggiunge accumulando attraversa tutte le taglie. Qui il costo diventa una funzione, misurata camminando il libro Deribit vero. [VENUE] 50 istantanee di BTC_USDC-PERPETUAL / ETH_USDC-PERPETUAL in 35 minuti (domenica notte UTC = la finestra piu' sottile della settimana, quindi conservativa). Mezzo spread 0,0065 / 0,0207 bps = UN TICK; costo sotto ~2 bps fino a $500k per ordine; il libro visibile finisce a $2,8M (BTC) / $1,2M (ETH). [CALC] Muro L3 congiunta $313.143 -> $315.080 col costo endogeno (+0,6%, DENTRO la risoluzione Monte Carlo del muro stesso, punto fisso convergente in una iterazione). La traiettoria EUR500/mese non si muove (P(20a) 85,1% -> 84,7%). Saturazione a ~$9,5M per argmax di C x drift(C) e a $10M per il primo 1% di nozionale non eseguibile in un istante: due definizioni indipendenti nella stessa decade, oltre un ordine di grandezza sopra il muro. Il gradino di leva sopravvive (k* 12,50x -> 12,25x alla taglia del muro; morde solo a $5M, dove crolla a 1,75x). Le due riserve degli scettici sono misurate e non mordono qui: il costo che si annullava in §52 e' quello dello SPOT (spread 100-500x piu' largo), e la partecipazione del 21,9% di §53 e' la quota di una barra 5m a volume basso — l'ordine di oggi e' lo 0,13% (BTC) / 0,43% (ETH) della profondita' a 1 bps. Trovato per strada, ed e' il fatto piu' utile: alla taglia di OGGI il costo che le tabelle non contengono ha segno NEGATIVO. Il drift a $635 e' 13 bps/anno PIU' BASSO che a $5.000 per il pavimento min_order, ~2x cio' che lo slippage costa fra $313k e $1M. Repliche 8/8 (TP01/SKH01/libro bit-exact; $272.061 e $258.338 al dollaro; accumula bit-exact; walk_cost_bps identica a §52) + R9 k* = 12,25x come FD.k_star, e due controlli POSITIVI obbligatori. Due errori miei catturati e pubblicati: banda p10/p50/p90 che si incrociava oltre il libro visibile (tre oggetti-curva separati), e un controllo positivo DEGENERE per costruzione (un costo costante sparisce da un drag differenziale). Sola lettura, nessun ordine, solo GET pubbliche. Libro, pesi, cron, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
bf617b75ff |
research(xs-ampiezza): NO — la caduta di XS01 su 11 gambe non era ampiezza, e' selettivita' piu' un IC che li' vale zero
L'ampiezza effettiva (participation ratio) scende solo da 9,34 a 7,23 (-23%) mentre lo
Sharpe scende dell'86%: sotto IR = IC*sqrt(ampiezza) la sola ampiezza spiega il 14% del
divario, e NESSUNA delle costruzioni dichiarate la muove (7,13-8,47). Il demeaning — la
mossa che creo' XSR01 — e' un NO-OP ALGEBRICO su XS01, perche' i pesi sommano gia' a zero
per costruzione (max|sum w| = 2,8e-17, serie identiche a 2,2e-16): non e' un risultato
debole, e' un'identita' che vale a ogni universo e per sempre.
Il divario sta altrove, ed e' due cose. (a) SELETTIVITA': k=5 su 11 gambe tiene 10
posizioni su 11 e non seleziona niente; k=5 non e' un parametro invariante di scala, fu
tarato su A=19. Congelando il QUANTILE invece del numero la mediana delle 10 fasi passa
da -0,04 a +0,69 (delta appaiato +0,83, positivo in 10/10 fasi, plateau su k in {1,2,3},
mentre su 19 gambe k non conta) contro +1,15 dell'universo pieno. (b) IC: -0,027 (t -0,88)
sulle 11 contro +0,057 (t +2,29) sulle 19, sotto TUTTI i 40 sottoinsiemi casuali da 11 —
e sui 9 alt maturi presi da soli e' NEGATIVO (-0,065, t -2,07) mentre le 8 mancanti da
sole non ce l'hanno (+0,008). L'informazione vive nel CONTRASTO fra le fasce: XS01 e' in
buona parte una rotazione major-maturi contro alt-recenti, non una selezione dentro una
fascia. §50 lo chiamava "sfortuna di listino" al 9° pctl dello Sharpe: sull'IC il
sottoinsieme di Deribit e' fuori dalla banda, per una ragione strutturale.
E tutto il recupero sta sotto la risoluzione del campione, per quattro strade: MDE
dell'hold-out ~2,3 di Sharpe su 1,64 anni attivi; lo spread di coda che dovrebbe pagarlo
ha t 0,2-0,6 contro 1,91 dell'universo pieno; il null di permutazione a fee zero (p
de-luckato sulle 10 fasi: mediana 0,130, sotto 0,05 solo nel 40%) separa il candidato dal
rumore su 19 gambe e non su 11; il deflated-Sharpe sulle 80 celle dichiarate FALLISCE
(0,158, massimo atteso dal rumore 1,065 contro candidato 0,459).
Due errori catturati su me stesso. (1) La selezione in-sample-only NON e' stabile alla
dichiarazione della griglia: con k in {2,3,4,5} la cella al buio era resid k=2 (HOLD
+1,33), aggiungendo k=1 diventa white k=1 (HOLD -0,53) — con ~1 anno di in-sample
(SE(Sharpe) 1,7) la procedura onesta e' una monetina. (2) La prima misura di
eseguibilita' usava |dW| invece di |d(W*scale)| e dava "100% eseguito": la posizione in
dollari e' W*scale e il vol-target muove il nozionale ogni giorno anche a pesi fermi.
Corretta, riproduce le due popolazioni di §45 per via indipendente (11,9% degli ordini =
62,5% del nozionale). A $635 passa l'83% del nozionale: il muro non e' il capitale.
Venue letto ora: 14/19 quotate (SUI 18/08, APT 21/08 senza NESSUNA quota, AAVE 15/08),
11 da >=1 anno, lotti $0,01-$7,72. Solo 2 delle 11 gambe netterebbero col libro live.
Replica bit-exact contro sleeves._xsec_returns (max|dif| = 0,0); controlli positivi su
tutti e tre i rilevatori (ampiezza su matrici note, IC con un segnale che bara = +1,000,
null di permutazione che separa 19 da 11). Sola lettura, nessun ordine, output
riproducibile a meno del timestamp.
Libro, pesi, cron, config INVARIATI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
aaddd2c93c |
research(prevday): §54 GATE PREVDAY-01 scritto — il lead piu' forte gira la cella SBAGLIATA
Chiude un buco di PROCESSO: PREVDAY sta in forward-monitor dal 2026-06-21 senza gate
pre-registrato e senza deflated-Sharpe, mentre XSR01/DVOLSPREAD/STATARB ne hanno uno.
FAMIGLIA DICHIARATA PRIMA E CONTATA AL RIALZO: anchor{1,2,3,5} x k{0..1.00, 7} x
short{T,F} x min_hold{0,24,72} x tf{1h,4h} = 336 celle (le 11 gia' spese in giugno da
prevday_turnover e le >=8 della scoperta sono tutte DENTRO). Screen dichiarato: i 16
agenti dell'onda intraday + le 104 ipotesi del 20/06.
IL RISULTATO PRINCIPALE — la cella scelta AL BUIO (in-sample-only) NON e' quella che
gira: e' 4h LONG-FLAT (short=False), mentre il monitor gira 1h LONG-SHORT, che sta al
rango 186/336 in-sample e FALLISCE il DSR (0.905 contro 0.993 della cella al buio).
La gamba SHORT — l'intera ragione per cui PREVDAY fu promosso a LEAD — e' esattamente
cio' che la selezione onesta non compra. E il rovescio: la cella al buio sta a corr
0.641 da TP01 contro 0.152 della congelata (diversifica di meno).
BANDA D'ANCORA: PREVDAY UN'ANCORA CE L'HA (l'ora del confine-giorno) e §50 l'ha tenuta
FERMA. De-luckata sullo spazio congiunto (TP01 x24 · SKH01 x23 · PREVDAY x24, 300
estrazioni, differenze APPAIATE): dShFULL +0.191 -> +0.100, dShHOLD +0.362 -> +0.246 al
peso 15% — meta'. Il SEGNO regge al 100% delle estrazioni; la TAGLIA no. Replica
indipendente di §50 a candidato fermo: +0.191/+0.362 contro i +0.192/+0.363 pubblicati.
Standalone: canonica al 96o pctl delle 24 ancore (ShFULL 1.236 contro mediana 0.963).
MDE: 63 giorni = 0.17 anni -> SE(Sharpe) 2.41 naive / 4.23 Lo, t 0.85 / 0.48, IC95 largo
16.6 punti. Per distinguere uno Sharpe vero di 1.2 dal nulla all'80% di potenza servono
9.4 anni. Il forward serve a UCCIDERE, non a promuovere. E il "+2,04" pubblicato e' su
lente ORARIA: sulla lente giornaliera del progetto e' +1.56.
DSR: attesa a priori REFUTATA. Non si ribalta col conteggio (11 -> 560 celle costa 0.009);
si ribalterebbe solo con sd(trial) >= 0.363 contro 0.267 misurata. Su famiglia OMOGENEA il
deflated-Sharpe e' cieco sul conteggio ma NON vacuo: la cella mediana della stessa
famiglia fallisce (0.863).
INTEGRITA' (sola lettura provata con md5+mtime): 1512 barre su 1512 ore, 95.6%
ricostruibili bit-a-bit; le 67 divergenti sono 1.06/giorno all'ora del cron = ~32
min/giorno non registrati (contro i 4 min/GIORNO REGISTRATI di paper_statarb, §32).
paper_prevday e' sano, ma non al 100%.
FUNDING (mai in nessun backtest): -1.37%/anno di sleeve. La gamba short NON compensa —
incassa solo 0.26-0.46x l'incondizionato mentre la lunga paga 1.25-1.69x.
weights_tilt_null PASS a ogni peso, ma frac_random_beat_hold = 0.91: "migliora
l'hold-out" e' un claim generico su questo libro.
GATE PREVDAY-01: decisione 2027-06-21, 7 condizioni (DSR>=0.95 sulla famiglia
ri-dichiarata + sensibilita' alla partizione pubblicata; cella al buio == congelata,
altrimenti si ri-congela e il forward RIPARTE DA ZERO; delta di libro appaiato > +0.05
positivo al >=90%; weights_tilt_null; ADDS non-hedge sulla cella al buio;
day_boundary_robust != ARTIFACT-RISK; Sharpe forward > 0, soglia debole di proposito),
veto d'integrita' >=80% di barre ricostruibili, kill a Sharpe < -0.50 su >=180 giorni
attivi. Oggi 8/10 condizioni; le 2 che mancano sono la stessa cosa.
Nessun file di produzione toccato, nessuna proposta di cambio al libro live.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
f5ebe689da |
skeptic(spot): il lead REGGE a $600 e si ANNULLA alla taglia del muro che sposta
§52 SKEPTIC-SPOT — attacco deliberato a §39/§45 (spot al posto del perpetual per la gamba TP01). Sei attacchi, replica bit-exact prima di ognuno (max|dif| = 0.0 su tp01_realistic; +2,106% di sleeve e +1,580% di libro protetti da assert). Esiti: 1 allineamento REGGE · 2 controfattuale INCRINA · 3 tetto 1,0x REGGE · 4 spread/profondita' INCRINA · 5 haircut REGGE · 6 disaster-SL REGGE. Il risultato che cambia una conclusione e non una presentazione: il differenziale di cammino spot-vs-perp e' +0,72 bps a $600 (-0,04%/anno) e +25,66 bps a $272k (-1,54%/anno = il 97% del lead lordo). Il +1,55% e' misurato a una taglia a cui l'esecuzione e' gratis e speso dentro un muro da $290k, dove non lo e': il muro NON si sposta del 10,9% pubblicato. Trovato invece che la storia dello spot ESISTE (get_tradingview_chart_data serve BTC_USDC/ETH_USDC dal 2023-04-24, 29.196 barre orarie, 0 gap): §39 la dichiarava assente. TP01 girato sul prezzo spot VERO contro il perp, 24 ancore appaiate, da' +0,166%/anno di sleeve con la banda che contiene lo zero (16/24) -> il controfattuale sul PREZZO e' innocuo. Ma lo strumento non esisteva per il 55,3% del campione e nel 2023 aveva ~9% di ore senza scambi: il lordo passa da +1,580% (7,4 anni) a +1,450% (era spot) a +1,180% (era liquida, 2024+). Attacchi falliti, e vanno detti: il tetto 1,0x non morde (3 giorni su BTC, tutti nel 2018-11 e in PERDITA: troncare avrebbe fatto guadagnare); nessun haircut <=100% rende binding il margine (copertura 50,0x replicata al decimo); il disaster-SL tolto a TP01 vale 0,15%/anno ammortizzato allo scenario operativo. Tre errori miei, catturati e dichiarati nello script: (a) confrontavo il costo di SPREAD dello spot con la banda NETTA di §45 — mele contro pere, nel verso che mi conveniva: like-with-like le due bande si sovrappongono; (b) l'aritmetica del margine metteva SKH01 a 1,0x su ciascun asset invece che sul proprio sleeve (25,0x invece di 50,0x: §45 aveva ragione); (c) ammortizzavo su 7,4 anni la coda di un blackout da 30 giorni preso come argmax, ottenendo 1,97%/anno = il 127% del lead da un evento mai accaduto. Squalificato dal proprio controllo positivo: gli stimatori di spread da OHLC (Roll, Corwin-Schultz) attribuiscono 4-16 bps al perpetual, che e' a un tick -> numeri cancellati, non riportati. Correzione a §45: «lo spot non si liquida» e' falso — BTC/ETH hanno in_cross_collateral_pool: true, quindi sono collaterale liquidabile (non binding). Numero onesto rivisto: [+1,38%, +1,58%]/anno a $600, -0,11%/anno a $272k. Sola lettura provata (git status -- src/ config/ scripts/live/ tests/ data/ vuoto), 0 ordini, solo GET pubbliche con pacing e astensione nei minuti :05-:10 e :24-:30. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
caa7cc4020 |
research(book-3rd): nessun terzo sleeve ammissibile oggi, e per sette candidati ci sono sette muri diversi — nessuno dei quali e' il capitale
§50 BOOK-3RD. Domanda: con ~$635 su Deribit, qual e' il MIGLIOR terzo sleeve realmente
eseguibile del LIBRO LIVE a 2 sleeve (`deribit_book_sleeves`, TP01 75 / SKH01 25) — e se la
risposta e' "nessuno", a quale capitale cambia? Un solo script, nessun file di produzione
toccato, nessun ordine.
REPLICA DI CONTROLLO PRIMA DI OGNI DELTA: ShFULL 1,813 / ShHOLD 1,437 / maxDD 9,42%
riprodotti al terzo decimale; replica ancorata (h=0, off=0) bit-exact contro lo sleeve di
produzione (max|dif| = 0,0), idem XS01, VRP01 e STATARB (0,746 contro il motore originale).
IL VINCOLO MAI MESSO IN TABELLA — IL NETTING. Letto dal sorgente: `book_net_target` somma i
due sleeve in UN numero per asset e `build_book_order` manda UN ordine, quindi un terzo
sleeve DIREZIONALE su BTC/ETH non paga un min-order proprio (misurato: 163 -> 344 ordini/anno
a $635, ma il turnover sale solo del 14%; e per disuguaglianza triangolare le fee modellate
per-sleeve sono un LIMITE SUPERIORE). Il rovescio: non puo' avere un proprio stop. Un terzo
sleeve su ALTRI strumenti richiede una riga in `_CONTRACT` = codice su un percorso con soldi veri.
LA MISURA (1000 estrazioni congiunte TP01 x24 · SKH01 x23 · candidato, mediana delle
DIFFERENZE APPAIATE, funding dentro, peso 15%):
PREVDAY +0,192 ShFULL / +0,363 ShHOLD / +1,31pp drift — eseguibile, netta, ADDS, e SENZA
gate pre-registrato: e' il piu' forte ed e' il meno disciplinato.
STATARB +0,159 / +0,081 / -0,12pp — gate aperto 27/09; NEUTRAL, robust_oos FALSE.
VRP01 +0,121 / +0,067 / +0,19pp — fermo per REGOLA, non per lotto (sotto).
XS01(19) +0,110 / +0,378 / +0,79pp — NON eseguibile: Deribit non quota 5 delle 19 gambe.
DVOLSPREAD +0,073 / +0,062 / -1,12pp — gate aperto 24/10; il maxDD PEGGIORA sopra il 15%.
XS01-D(11) -0,024 / -0,128 / -0,73pp — l'unica versione eseguibile oggi PEGGIORA il libro.
DUE FATTI DI VENUE, LETTI DALL'API E NON DALLA MEMORIA:
(a) il muro del LOTTO di VRP01 era misurato sulla famiglia INVERSE, che un conto USDC non
puo' marginare: sulla USDC-lineare il lotto ETH e' $242 (non $1.832) e il BTC $772 (non
$6.210) -> 1 lotto ETH = peso 12% gia' da ~$2.000. Cade il lotto, NON la regola
"niente short-vol da modello in deploy". 5a occorrenza dello schema `fee_watch`.
(b) Deribit quota 14 dei 19 major di XS01, ma 3 sono listati fra il 15 e il 21 agosto (APT
non ha nemmeno una quota). Sulle 11 con >=1 anno di listino il meccanismo collassa, e il
null dei sottoinsiemi (100 estrazioni da 11 fra le 19) separa le due cause: il
sottoinsieme MEDIANO fa gia' 0,548 contro 1,265 (62% della caduta = AMPIEZZA, non
riparabile col capitale) e quello di Deribit sta al 9° percentile (il resto = QUALI
gambe mancano). Aspettare 2-3 listing non basta.
`weights_tilt_null`: 25/28 PASS — e il numero da leggere non e' quello ma `frac_random_beat_hold`,
che arriva a 0,94: dove vale cosi', "questo candidato migliora l'hold-out" e' un claim GENERICO.
Il gate ha potenza (fallisce su XS01-D a 10/15/20%), ma resta necessario e non sufficiente.
LA SCALA: non esiste una soglia di capitale che ammette un terzo sleeve. Il capitale sposta
solo VRP01 (~$2.000 gamba ETH, ~$6.440 gamba BTC), che e' fermo per una regola. Le due date
che contano sono un GATE (27/09, gratis) e la DECISIONE DI VENUE ($20k), che e' cio' che
riapre XS01 sulle 19 gambe.
ONESTA': attesa a priori dichiarata prima di misurare, esito A1 confermata, A2 meta' giusta,
A3 e A4 REFUTATE, A5 confermata al rovescio. Caveat pubblicato: sono 7 candidati x 4 pesi = 28
configurazioni sullo stesso hold-out, nessuna passata per un deflated-Sharpe DI SCREEN — il
modo giusto di usare la tabella e' scegliere un candidato per una ragione dichiarata PRIMA.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
e7ee0738a3 |
scettico(leva): il gradino 1,25x REGGE 5 attacchi su 6 — k max difendibile 1,40
Filone §53 SKEPTIC-LEVA. Sei attacchi con soglie dichiarate PRIMA, 10 numeri
pubblicati riprodotti prima di attaccarli. Sola lettura, zero rete, 127 s.
A1 DRIFT REGGE — il gradino diventa dannoso solo sotto +1,42%/anno di drift
(-2,70 SE, 0,25° pctl bootstrap a blocchi): fuori da IC95
[+4,78%] E da IC99 [+2,36%]. Il libro puo' perdere il 90,6%
del suo drift e il gradino resta non dannoso; il PEGGIOR
triennio mai realizzato (+5,35%) ci sta 3,8x sopra.
A2 SINISTRO REGGE — Delta g(1,25) > 0 in 5/5 finestre giudicabili (2020-21 tolto
compreso). QUALIFICA misurata: nel biennio MOBILE peggiore
(dal 2021-10, drift -0,45%) il gradino COSTA -0,31%/anno =
-0,62% cumulato. Non falsifica per il criterio (li' perde il
LIBRO), ma il numero e' quello. Rapporto guadagno/costo 13:1.
A3 CODA REGGE — con Hill xi=0,43 (piu' severo del +0,34 pubblicato) il peggior
giorno strutturale a 1,25x e' 17,90% (<50%) e P(dimezzamento
10a) 0,100% contro 0,000%. CORREZIONE a §33: la coda muove k*
di 4,6 unita', non "1-2" — la conclusione regge (il drift ne
muove 6,2) ma il numero pubblicato e' ottimista ~3x.
A4 LENTE REGGE — sotto la lente accoppiata il ricarico del maxDD CALA con k
(1,2358 -> 1,2297 -> 1,2237): moltiplicativo, verso favorevole.
E la frequenza del disaster-SL e' invariante a k PER
COSTRUZIONE (innesco sul MARK, test di ri-piazzamento
RELATIVO): il numero di §40 va moltiplicato, non rifatto.
A5 INVARIANTE INCRINA — completo sul percorso FIDATO (0 violazioni su 576 combo:
il vero e' n_asset*min(WEIGHT*(W_TP01*lev+W_SKH), frac)*scala,
quindi l'invariante e' un LIMITE SUPERIORE). Ma nel ramo di
FALLBACK il denominatore del rapporto e' il WATERMARK, non
l'equity: leva vera fino a 5,00x GIA' a k=1,00 e 6,25x a 1,25.
La scala non apre il buco, lo MOLTIPLICA -> la guardia G3
della SPEC non e' una raffinatezza ed e' NON OPZIONALE, ma non
e' una chiusura. E il fattore 0,30 non e' un tetto di perdita
(§40: stop rotolante, passano -60% dall'ingresso).
A6 FUNDING REGGE — rifatto col funding DENTRO e proporzionale a k (r_k = k*(r-f),
lineare per costruzione): il gradino vale +3,49a (muro mobile)
/ +2,10a (muro congelato) contro +2,98a / +1,82a sulla lente
pubblicata. Il funding NON riduce il gradino: lo AUMENTA in
anni, perche' peggiora il caso base (17,28a contro 14,81a).
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.
RICONCILIAZIONE: il «+1,8a / +EUR164» pubblicato NON era una discrepanza, era una
CONVENZIONE non dichiarata — e' la lettura a MURO CONGELATO (de-leva al traguardo),
riprodotta a 0,02a (+1,82a). Col muro che si muove con k il gradino vale +2,98a. La
differenza fra le due letture (1,2 anni) e' piu' grande di quasi tutti gli effetti
che questo progetto misura: va dichiarata. Il +EUR164 e' invece +EUR144 misurato
direttamente — la differenza E' l'ipotesi di linearita' dell'interpolazione.
K MASSIMO DIFENDIBILE = 1,40 (morde il peggior giorno strutturale <= 20%, soglia
AGGIUNTA da questo scettico); coi soli vincoli gia' dichiarati dal progetto sarebbe
1,67 (G6, il disaster-SL). Il 1,50x NON sopravvive: sfonda il 20% (21,48%) e sta al
90% del tetto G6. La scaletta SCALA_LADDER a 1,25 resta giusta: e' l'unico gate che
il progetto ha contro un parametro che nessun altro gate vede.
NON PORTATI: banda d'ancora del guadagno in ANNI (23x24 congiunte, fuori budget);
slippage a taglia crescente (la partecipazione 21,9% di una barra 5m diventa 27,4%
SUBITO, non a $5.000: va misurata PRIMA del gradino); costo di margine sopra 1x
(non esiste su perp lineare marginato); coda di venue (vive sul suo asse).
Nessun file di produzione toccato: git diff sui tracciati e' vuoto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
58395a594e |
research(§47): l'ensemble d'ancora e' ESEGUIBILE a ogni capitale — ma su TP01 vale +0,014 di Sharpe, e il segnale sta su SKH01
VERDETTO: ESEGUIBILE MA INUTILE SU TP01 — nessun cambio al libro.
La domanda mai chiusa: invece di de-luckare il NUMERO, si puo' de-luckare
l'ESECUZIONE (N tranche, N ore, 1/N di size)? Tre risposte:
(i) batte l'ancora MEDIANA: si', di +0,014 di Sharpe FULL. E l'algebra dice
che non puo' fare di piu': la posizione dell'ensemble e' la MEDIA delle
posizioni, il lordo orario e' lineare -> lordo_ens == media dei lordi
(max|dif| 1.4e-17, verificato). Tutto il guadagno e' vol (-1,1%); il
drift si muove di +0,013% = solo fee-netting. Cio' che compra davvero
non e' nella colonna Sharpe: sd(ShFULL) 0,061 -> 0, sd(ShHOLD) 0,112 -> 0.
(ii) batte la CANONICA che gira oggi: NO sull'hold-out (-0,223), SI su FULL
(+0,024) e IS (+0,071). I due numeri non sono due stime della stessa
cosa: +0,44 e' un'estrazione gia' avvenuta (98 pctl di 24), +0,21 e' cio'
che si ottiene senza estrarre. La stima onesta del futuro e' +0,21.
(iii) eseguibile da quale capitale: da TUTTI, gia' a $635.
PREMESSA DEL 02/07 REFUTATA, CONCLUSIONE INTATTA. Il 02/07 boccio' il
tranching perche' "i delta per-ancora (~$1-2) sono sotto il min-order $5".
Ma `book.build_book_order` banda la posizione NETTA e manda UN ordine per
asset per giro: un delta per-ancora non e' mai un ordine. Il tranching non
moltiplica gli ordini per K, e la degenerazione non avviene (retention
0,88-1,06 a $635; a K=24 il path eseguito segue l'ideale MEGLIO che a K=1,
corr 0,9986 vs 0,9954). Cio' che lo boccia e' la taglia dell'effetto, non
l'esecuzione — e la ragione conta, perche' quella vecchia cadrebbe al primo
esecutore che mandasse un ordine per tranche.
FUNDING: canale chiuso per ALGEBRA, non per piccolezza. funding = pos*f e'
lineare in pos -> funding_ens == media esatta (max|dif| = 0). Il rapporto
condizionale 2,25x non si attenua (2,25 -> 2,26 da K=1 a K=24): la
correlazione esposizione-funding vive alla scala del regime, non dell'ora.
DOVE STA IL SEGNALE: SKH01, l'unica ancora a cui il 02/07 non porto' mai
questa domanda. Sulla lente del path che gira, mediana delle 23 fasi ShFULL
0,974 -> ensemble 1,286 (+0,312), maxDD 23,3% -> 16,6%: 20x TP01, perche' i
suoi trade sono DISCRETI (spostare la griglia cambia QUALI trade esistono).
Dentro il libro pesa il 25% e li' non si distingue da zero. 23 e' PRIMO ->
sulla griglia 30m non esiste sotto-ensemble simmetrico.
Contro-intuitivo misurato: tranciando entrambi gli sleeve gli ORDINI salgono
6,5x (197 -> 1283/anno) ma le FEE SCENDONO ($5,76 -> $5,29/anno) — su un
venue a fee proporzionale si paga il nozionale, e mediare 23 fasi trasforma
un +-1,0x che sbatte in una posizione frazionaria. Su un venue a pavimento
fisso il segno si ribalterebbe.
BARRIERA (canale funded): [A7] refutata sulla regola misurabile e con un
meccanismo — il lato binding non e' la barriera (-6%, P(breach) 0-7%) ma il
BERSAGLIO (+10%): meno vol allontana dal traguardo quanto dalla barriera, e
l'ensemble sta al 31 pctl su P(pass). MA la regola che il 22/08 ha misurato
uccidere e' la daily-loss a UN giorno, che close-only non puo' vedere
(cieca, non conservativa). Sul p1 giornaliero — cio' che quella regola legge
— l'ensemble batte il 66% delle configurazioni. Dichiarato come indizio.
COSTO VERO, e non e' negli ordini: 23 ancore su 24 di TP01 richiedono barre
di oggi, cioe' `fresh_5m` — il path che il 26/07 ricade in silenzio sul
certificato e che il 29/07 ha fallito 6 giri su 8. E' l'unica delle tre
obiezioni del 02/07 che sopravvive intatta.
Repliche prima di ogni delta: h=0 == tp01_baseline_daily; guardie di
causalita' su tutte le ancore; `banded()` == `r07.smallcap_net` bit-exact
(0.0e+00, stessi ordini); K=4 == EW di 4 book (2.2e-16 sul daily);
offset 0 == `sleeves._skyhook_returns()` (0.0e+00). I livelli del 02/07 sono
derivati col dato: dichiarato, non nascosto.
Due errori miei catturati e congelati in commento: (a) confrontavo
`turnover_per_year`, che eval_weights ARROTONDA, accanto a una
disuguaglianza stretta -> sembrava violata; (b) i percentili di coda usavano
un solo segno per tre colonne di cui due sono ritorni e una una frequenza ->
stampavo 34 dove il valore vero e' 66, cioe' "peggio della mediana" per un
numero migliore della mediana. E il criterio N_max SATURA (6/6 celle a ogni
capitale): un gate che passa sempre non misura niente, e lo dice il codice.
Book, pesi, ancore, cron, config INVARIATI. Nessuna proposta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
5700280f65 |
research(tail-hedge): REFUTATO — la copertura di coda ALZA il maxDD del libro, 0/162 celle
§46. Prima misura del progetto sull'acquisto di put deep-OTM come assicurazione statica
sul libro (TP01 75 / SKH01 25), senza delta-hedge e senza pretendere alpha. Motore prezzi
RIUSATO da VRP01 (_bs_put/_strike_from_delta su DVOL reale). Griglia dichiarata prima:
3 delta x 3 tenori x 3 budget x 2 roll = 54 celle per lente di f (162 in tutto).
VERDETTO: il null del de-levering non arriva nemmeno a essere il gate che decide — la
premessa cade prima. Il maxDD SCENDE in 0/54 celle a OGNI lente di f (compresa f=1.00,
cioe' regalando alla copertura il prezzo di modello): 9,42% -> 9,53-10,37%. Meccanismo:
il bleed del premio cade DENTRO i drawdown, che su questo libro sono lunghi e poco
profondi, mentre il payoff cade su singoli giorni di crollo che NON sono il fondo del
drawdown. Beta del libro al sottostante +0,076 (il 19/05/2021 il mercato ha fatto -21,1%
e il libro -2,0%): la put protegge una perdita gia' ridotta di ~10x dalla strategia
stessa, quindi coprirla costerebbe ~1/beta volte il budget.
ATTESA A PRIORI, riportata anche dove sbagliata: (c) REFUTATA nella forma scritta — 15/20
dei peggiori giorni SONO crolli, e lo short-squeeze che avevo in mente sta fuori finestra;
(b) e (a) confermate, e (b) e' il meccanismo operativo.
f MISURATO OGGI sulle quote vere (420 put con bid E ask, catena USDC): 1,89 / 1,27 / 1,06
a delta -0,05 / -0,10 / -0,15 — piu' mite del 2,23-5,85 del 30/07, e il verdetto non
cambia. Struttura del modello che vale come risultato: f si paga solo sulla parte di
valore che converge a INTRINSECO, quindi un roll anticipato non lo paga (sensitivita' con
f asimmetrico riportata).
ESEGUIBILITA': corregge un muro ereditato. Comprare un'opzione costa il PREMIO, non il
NOZIONALE — i "lotti da migliaia di dollari" del 22/08 sono il collaterale per VENDERE.
Il lotto minimo BTC_USDC (0,01) costa $1,79-7,93; la copertura diventa comprabile a ogni
roll da ~$9,2k (30g, delta -0,05) a ~$38,8k (7g, delta -0,15). Secondo muro, STRUTTURALE:
il tick da 5 USDC — piu' la copertura e' deep-OTM (cioe' economica) piu' il tick domina.
CANALE FUNDED: sull'unica regola binding (max-loss 6% statico) la copertura va nel verso
sbagliato — alza il maxDD e quindi abbassa la leva ammessa (k 0,629 -> 0,594-0,620).
DUE ERRORI MIEI CATTURATI PRIMA DI PUBBLICARE, entrambi dal controllo e non a occhio:
(1) il controllo positivo "payoff gratis" FALLIVA perche' non accreditavo il valore
dell'asset regalato, mentre il MTM successivo ne addebitava il decadimento -> il free
lunch costava quanto il premio. Un controllo positivo rotto dichiara guasto l'apparato.
(2) la prova di causalita' dava 1,28e-04 ("DIVERGE"): confrontavo fino al taglio, ma il
prefisso si ferma un roll prima -> differiva per ASSENZA di un roll, non per
look-ahead. Finestra corretta: 0,00e+00 esatto.
(3) e un errore di CRITERIO: contavo "vittoria" anche dove il maxDD PEGGIORA, dove il null
del de-levering e' degenere (k=1) e un Δdrift>0 risponde a una domanda di alpha, non a
questa. Col criterio corretto le "3/54 vittorie" a f=1 diventano 0/54.
Controlli 3/3 OK (free lunch e f=0,1 riconosciuti, f=10 rifiutato). Causalita' esatta.
Lente wick accoppiata riusata da r0725_prop_coupled, copertura 100% del pannello.
Distorsioni dichiarate: finestra 2021-03+ (il DVOL non esiste prima, quindi marzo 2020 e'
FUORI CAMPIONE); spread misurato sui soli strumenti con bid E ask = pavimento che favorisce
la copertura; 3-5 breach in 5,4 anni non distinguono le varianti.
Libro, pesi, cron, config INVARIATI. Nessun ordine.
|
||
|
Adriano Dal Pastro
|
7d4f0c328e |
research(§49 TP01-TWIN): un ENSEMBLE di 5 meccanismi di trend NON protegge piu' di TP01 — REFUTED
Domanda: TP01 e' il 75% del libro live e dipende da UNA definizione di trend (TSMOM
30/90/180). Sostituirlo con un ensemble di meccanismi diversi ma tutti long-flat (Donchian,
incrocio EWMA, canale di Keltner, Kaufman/KAMA) migliora la PROTEZIONE — che e' il suo
compito — a pari drift e a pari costo? NON e' la domanda `marginal_vs_tp01` (secondo sleeve):
e' la STESSA quota di libro espressa da piu' meccanismi, quindi `weights_tilt_null` non si
applica (il vettore dei pesi e' identico nei due bracci).
Esito: REFUTED. Libro, pesi, cron, config INVARIATI.
Entrambe le attese a priori, scritte prima di misurare, sono REFUTATE:
(A1) "correlano 0,85-0,95, l'ensemble e' TP01 con piu' fee" -> 0,795 sui rendimenti e 0,608
sulle POSIZIONI; KEL/KAU stanno a 0,51-0,53 da TSMOM. Meccanismi genuinamente diversi:
il filone non si chiude sulla matrice, va misurato fino in fondo.
(A2) "meno DD sara' de-levering" -> k_isovol 0,990: NON C'E' NIENTE DA DE-LEVERE. Vol
identica (12,1 vs 12,0%), esposizione media PIU' ALTA (0,152 vs 0,141), tempo a mercato
70% vs 55%. Il null non e' "superato", e' SENZA POTENZA, e va detto cosi'.
Muore invece sulla DISTRIBUZIONE della protezione (criterio (B) di edge_watch importato dal
sorgente di produzione) e sul costo al libro:
- per anno x 24 ancore: l'ensemble protegge PEGGIO in 2022, 2024, 2025 e 2026 a 0/24 ancore
(degradazione UNANIME, non fortuna d'ancora) e meglio in 2019-2021 e 2023. I quattro anni
in cui perde sono i quattro PIU' RECENTI. Nel 2022 (DD buy&hold 68%, il sinistro maggiore)
il rapporto passa 0,04 -> 0,13 = 3,2x peggio.
- 73/192 celle ancora-x-anno a favore dell'ensemble (TSMOM meglio nel 62%); rapporto MEDIO
0,18 -> 0,21 (peggiora, 0/24 ancore favorevoli).
- costo sul LIBRO 75/25: Sharpe hold-out delta appaiato -0,127, favorevole 3/24.
- 0/30 delle 31 composizioni possibili batte TSMOM da solo su protezione E hold-out insieme:
il compromesso non e' di questo ensemble, e' della famiglia.
- e il criterio che si voleva migliorare NON E' BINDING: TSMOM ha rapporto peggiore 0,635
contro la soglia 0,75 in 192 celle su 192.
ERRORE MIO catturato in sessione e riportato nello script: la prima stesura decideva sul CASO
PEGGIORE (max degli 8 rapporti), che migliora 0,56 -> 0,49, e avrebbe stampato "PROMOSSO A
LEAD". Il massimo di 8 numeri non e' una statistica: si era mosso perche' era migliorato UN
anno (il 2023, che deteneva il massimo) mentre 4 su 8 peggioravano. Secondo errore corretto:
il tempo a mercato era calcolato sulla serie 50/50 (non-zero se lo e' UNO dei due asset) e
dava 66,8/79,4% contro i 55,4/70,3% di eval_weights nella stessa pagina.
Onesta' verso l'ensemble: l'ancora canonica h=0 e' la MIGLIORE delle 24 per lo Sharpe hold-out
di TSMOM (100 pctl, replica indipendente della fortuna d'ancora del 02/07 e 26/07), quindi il
divario a h=0 (-0,37) e' gonfiato: il numero da citare e' la mediana appaiata, -0,067.
Fatto trasferibile: mediare meccanismi di trend NON diversifica il rischio di trend. Cinque
segnali guidati dallo stesso prezzo divergono solo ai BORDI del trend — cioe' nei ribassi — e
la media li tiene mezzi-lunghi mentre il singolo e' gia' flat. Piu' meccanismi = ingresso e
uscita piu' morbidi, non piu' assicurazione. Cio' che NON si conclude: che la monocultura sia
sicura — servirebbe un regime in cui il TSMOM fallisce, e in 7,4 anni non c'e'.
Controlli: replica bit-exact vs sleeves._tp01_returns (max|diff| = 0,0); criterio (B) 8/8 su
TP01 come pubblicato e 0/8 su buy&hold; stimatore di correlazione validato su corr(TP01,SKH01)
= +0,095 contro +0,09 pubblicato; il null del de-levering DEVE scattare e scatta su un
de-levering vero (target_vol 10%); causality_ok max_tail_diff 0,0 su 5/5 + ensemble.
DSR di famiglia 0,999 PASS ma dichiarato NON decisivo (famiglia omogenea -> sr0 piccolo per
costruzione); trial contati al rialzo 22 + 31 composizioni = 53.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
9cb3465374 |
research(volvol): la vol-of-vol e' una variabile NUOVA che guarda INDIETRO — SCARTATA, quinto lato del filone DVOL chiuso
§48 VOLVOL. Il DVOL era stato usato in quattro modi, tutti sul LIVELLO o su una differenza
di livelli (VRP01 gate IV-rank, DVOLSPREAD, TP01xDVOL, DVOL-direzionale). Mai il secondo
momento. Qui si apre e si chiude.
ORTOGONALITA' (il gate, misurato PRIMA di costruire qualsiasi strategia): PASS con margine.
Max |corr| = 0.396 su 6 referenze x 6 celle; contro il LIVELLO del DVOL sta a 0.13-0.21 e
contro l'IV-rank di VRP01 a 0.01-0.24. **La meta' "ridondante" dell'attesa a priori e'
REFUTATA**: e' davvero una quinta variabile, non una quarta riscritta.
LEAD-LAG: e' un termometro, e peggio di quanto l'attesa dicesse. Il picco di
corr(VoV_t, |r|_{t+k}) non e' a lag 0 ma a lag **-5/-10**, con la curva monotona da +0.17
a lag -10 fino a +0.02 a lag +10: non accompagna il movimento, lo INSEGUE. E al netto di
RV_t e DVOL_t la correlazione con la vol futura a 10g e' **NEGATIVA** (-0.069 BTC /
-0.090 ETH). Controllo positivo del rilevatore superato 2/2 nei due versi.
GRIGLIA dichiarata prima e contata al rialzo: 3 finestre x 3 soglie x 4 usi = 36 celle
(27 direzionali + 9 sull'arm VRP). Tenuta piccola di proposito: su 168 trial il massimo
atteso dal puro rumore e' Sharpe 1.572, sopra il soffitto direzionale.
- study_family_honest: cella scelta in-sample-only SIZE w=10 p=0.50, marginal NEUTRAL,
**DSR 0.448 FAIL** (0.441/0.381/0.228 a N=36/72/168) -> earns_slot_honest=False.
- La spia T1 in chiaro: la cella scelta ha **corr->TP01 0.995 SULL'HOLD-OUT** (0.667 sul
pieno). E' TP01 con un nome diverso. Per uso: RISKOFF/SIZE ereditano lo Sharpe del trend
(mediana IS 0.40/0.66), **DIR — l'unico uso in cui la variabile decide da sola — ha
mediana IS -0.24 e 5 celle su 9 con FULL negativo**.
- Arm VRP01, replica del sleeve **bit-exact 2/2** prima di ogni delta: 5/9 celle battono il
canonico (moneta), maxDD giu' in **9/9** = de-levering puro, e contro gate CASUALI che
saltano lo stesso numero di settimane la mediana e' 0.71/0.72 con **0/9 celle al 95° pctl**.
5° fallimento consecutivo di un gate nuovo su VRP01 dopo i 4 del 03/07.
IL NUMERO CHE CHIUDE, e non e' quello della griglia: il candidato migliore batte TP01 nudo
di **+0.034 di Sharpe su una finestra il cui MDE e' 1.51 — fattore 44**. Su questo dato la
domanda non e' rispondibile in positivo nemmeno in linea di principio. A chiudere sono le
due misure che hanno potenza e non dipendono da nessuna cella scelta: la parziale negativa
e il **controllo NON CAUSALE** (stessa cella con vol-of-vol che sbircia: **-0.292** sotto
TP01) -> non e' che la si stima male, e' che la variabile non contiene l'informazione.
Errori catturati su me stesso: (a) la lettura di §1 era CABLATA e diceva "il legame piu'
forte e' con la vol realizzata" mentre la tabella diceva SPREAD -> ora e' calcolata;
(b) il null del gate casuale estraeva le settimane INDIPENDENTEMENTE per gamba mentre il
gate vero e' guidato da due DVOL correlati -> bracciato coi due estremi, e la differenza
e' risultata immateriale (0.71 vs 0.72, sovrapposizione vera 0.29), ma andava misurata e
non assunta (nel 25/07 lo stesso errore valeva 2-3x); (c) un conteggio off-by-one su DIR.
Eseguibilita' a $635 NON e' il vincolo (haircut -0.002, turnover 4-5/anno): 8ª volta
nell'ondata che muore sull'edge e non sulla taglia del conto. causality_ok OK, oracolo OK.
Book, pesi, cron, config INVARIATI. Nessuna scrittura, nessuna rete, 20s di corsa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
e2aee5730b |
research(newdata): raccogliere 2 fonti su 10 — il criterio di ricostruibilita' ne uccide 4 da solo
§51 NEWDATA-SCOUT. La scorta di dati e' esaurita (§43), quindi la domanda cambia: non "cosa abbiamo e non guardiamo" ma "cosa NON abbiamo che vada iniziato OGGI". Ogni riga della colonna ricostruibilita' e' PROVATA con una GET pubblica + controllo positivo, non dedotta. VERDETTO: raccogliere la catena opzioni USDC-lineare (+117 chiamate/giro = +18%, non +90%); il book depth L2 come CAMPAGNA A TERMINE, non come collettore. Tutto il resto: no. - tape/liquidazioni Deribit: muro di ritenzione misurato fra -24h e -26h (non ricostruibile), ma il MDE lo manda al 2032 come segnale -> non raccogliere. E il campo `liquidation` non si e' fatto vedere in 1000 trade: non si accende una raccolta su un campo che non si sa se scatta. - §10 proponeva un collettore di OI perpetual "perche' oggi ripartirebbe da zero": MISURATO, non riparte da zero — Bybit serve >=800 giorni di OI perpetual gratis (timestamp verificati dentro la finestra chiesta), e la famiglia funding e' chiusa su 4 lati -> testare prima. - Binance OI/taker/long-short: muro vero a 30 giorni (l'API RIFIUTA, non risponde vuoto), ma MDE 6 anni + venue USDT -> no. - funding, DVOL, macro: ricostruibili E famiglie chiuse -> doppia eliminazione. Correzione a un numero pubblicato: la catena USDC con gli STESSI filtri del collettore vivo (<=95g, OI>=100) sono 113 strumenti, non ~587; l'origine del 587 resta ignota e lo dico. Il +117 e' un numero di OGGI e cresce con la liquidita' USDC: va ri-misurato prima di accendere. Bug catturato in sessione: urlopen solleva su HTTP 400, quindi il RIFIUTO di Binance veniva ingoiato come guasto di rete e il muro si ribaltava in silenzio in "RICOSTRUIBILE" — stessa conflazione error/no_quote gia' codificata in collect_chain. Guardia sulle finestre di cron verificata in entrambi i versi; MDE replica la convenzione §43 (1,40 a -> 1,66). Sola lettura sul disco, nessun ordine, nessuna chiave. Libro, pesi, cron, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
279c70222b |
research(§45): il percorso --no-net non deve crollare — apr assente si DICHIARA, non si formatta
Trovato dallo smoke test a cache fredda: senza get_currencies la sezione 1f cadeva su TypeError formattando None. Un'analisi che non puo' girare offline non e' riproducibile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
13daccf6de |
research(§45): SPOT-NETTING — il margine non uccide il lead, il CODICE si'; e separare le gambe non aggiunge niente
Filone §45: quanto vale, e quanto costa, spostare TP01 sullo SPOT Deribit separandolo
da SKH01 (oggi nettati su un unico strumento). Solo misura, nessun file di produzione
toccato, nessun ordine.
Q1 MARGINE — il venue NON blocca: BTC/ETH sono `in_cross_collateral_pool: true`
[VENUE], lo spot ha `max_leverage: 10` (vive dentro il conto marginato, non in un
wallet a parte) [VENUE], e il margine iniziale misurato sul conto reale e' il 2,00%
del nozionale [CONTO: equity-available su 2 posizioni] -> nel caso peggiore la gamba
SKH01 resterebbe marginata 50x dal solo USDC libero, a QUALUNQUE capitale (il
rapporto e' invariante in E). L'haircut non e' leggibile e non e' binding.
A bloccare e' il CODICE: `shadow._equity` legge solo `account_summary('USDC')` e
`position_usd` matcha per instrument_name -> comprando spot il libro leggerebbe il
25% del conto vero e non vedrebbe la gamba. Non e' un cambio di strumento, e' un
cambio del percorso di sizing del live.
Q2 VALORE — T1 riprodotto (+0,051/+0,057 contro `hourly`, pubblicato +0,054/+0,061)
MA contro `fastdetect`, che il 26/07 stabili' essere il path del live vero, vale
-0,048 FULL (6/23 offset): sbloccarlo e' un DECLASSAMENTO. Il netting perso non
costa commissioni (-0,216% di equity/anno: e' un risparmio) ne' ordini (-6,3/anno):
costa tracking (+12%) e spread ([0,139%,0,250%]/anno). I due si compensano quasi.
Il valore vero e' il funding e basta: +1,58%/anno lordo di drift di libro.
Q3 — `fee_watch` DERIVA i suoi strumenti da `src.live.book.INSTRUMENT`: una gamba
spot sarebbe invisibile (stesso difetto corretto il 21/08 sugli inverse). Riga
dichiarata, non scritta. `convenzione('BTC_USDC')` = 'ignota' -> servirebbe anche
una terza famiglia o il cross-check sui fill resta muto.
Q4 — la liquidazione MIGLIORA (il 75% del libro esce dal perimetro; uno spot non si
liquida) ma la gamba TP01 resterebbe senza disaster-SL; il fisco PEGGIORA di
0,83%/anno se i derivati sono `c-quater`, e i comparti si SEPARANO (le minusvalenze
del perp smetterebbero di compensare le plusvalenze spot): costo nuovo, mai contato.
IPOTESI MIA NATA E REFUTATA: «convertire USDC in spot rinuncia all'interesse». Il
venue dichiara USDC `apr` 3,40; sul log del cron, 6 run flat (il piu' lungo 257 giri
= 10,7 giorni) mostrano equity INVARIATA al centesimo contro i +$0,59 attesi ->
limite superiore su qualsiasi interesse < 0,029%/anno. L'obiezione e' morta.
⚠️ Due istantanee del libro a 4 minuti danno differenziali di spread 2,27 e 4,08 bps
(+79%) e il contributo netto dell'esecuzione CAMBIA SEGNO fra le due: e' dichiarato
come banda, non come punto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
696f2e5bdd |
research(§43 DATA-UNUSED): inventario dei dati mai letti + l'unica ipotesi che ne esce, misurata
FASE 1 — censimento di data/ e di CHI lo legge (indice di 647 .py, Old/ escluso). Colonne MAI lette: 26 su 31 di CoinMetrics (fra cui FlowIn/FlowOutExNtv, 2018-2026 al 100%), `fetch_errors_json`, `iv_90d`. Tutto il resto con storia vera e' gia' stato analizzato: cio' che resta non letto e' telemetria a finestra corta (catena opzioni 113 g, 0DTE 30 g, vol_term 58 righe). Corretti in sessione due difetti dell'inventario stesso: la ricerca a SOTTOSTRINGA dava `iv` in 571 file, e le chiavi derivate dall'etichetta producevano due falsi "NESSUNO" su famiglie realmente lette (eqx_, fut_deribit/fund_). FASE 2 — EXFLOW: il turnover LORDO sugli exchange. SCARTATO. La famiglia exchange-flow fu uccisa il 24/07 sullo STOCK (SplyExNtv). Misurato prima di riaprirla: `In-Out` e' la derivata dello stock (corr +0.999 BTC / +0.752 ETH) mentre `In+Out` e' ortogonale (+0.035 / +0.080) — il 94% del flusso si cancella, quindi il lordo e' algebricamente assente da cio' che era stato provato. Griglia dichiarata prima: 3 variabili x 3 finestre x 2 modi x 2 segni = 36 celle, +4 gia' spese su EXS = 40 trial. (1) La cella scelta al buio fa Sharpe FULL 0.951 contro un massimo atteso dal PURO RUMORE di 1.009: sotto la soglia che una griglia di monete raggiunge da sola (DSR 0.437 a N=36, 0.411 a N=40). (2) La selezione in-sample torna sul CONTROLLO NEGATIVO messo apposta nella griglia (NETCTL = l'informazione gia' uccisa): il lordo non e' selezionabile, hold-out -0.42, DILUTES. (3) Zero informazione direzionale (|t|<1 su 2 asset x 2 variabili). Il legame col |ritorno| su ETH (Pearson incrementale t +2.70) non sopravvive al rango (Spearman p=0.46) e cambia segno per anno; su BTC e' "significativo" nel verso sbagliato. Sottoprodotti: corr->TP01 0.50-0.65 = replica indipendente del "l'on-chain e' prezzo travestito" del 24/07 su colonne che quell'ondata non aveva letto; haircut 0.000 a $635. Corretti prima di pubblicare due errori miei: il pool "N=12" del deflated-Sharpe erano le 12 celle MIGLIORI (rows e' ordinata) e faceva PASSARE il candidato a 0.975 — con la partizione legittima fa 0.678; e il residuo di vol calcolato a mano invece che per OLS ribaltava il segno su ETH. Solo ricerca: nessuna scrittura, nessun ordine, book/pesi/cron/config INVARIATI. |
||
|
Adriano Dal Pastro
|
fc55698096 |
research(deposit-timing): il timing dei bonifici non paga — 0/12 celle, e il segnale compra davvero il 51% piu' in basso
§44. Prima misura di un calendario di versamento CONDIZIONALE (le 5 leve del piano misurate finora confrontano solo calendari deterministici). 12 celle dichiarate prima: buy-the-dip x4 soglie, risk-off (TP01 a 0x), valore-medio x3, anti-dip x4. Stesso flusso di cassa per tutte (EUR X/mese sul conto corrente); cio' che cambia e' quando entrano nel libro, con la liquidita' in attesa a 0% reale. Lente L3 CONGIUNTA (funding + fisco), muro $313k, block bootstrap 3000 percorsi. Replica 4/4 prima di ogni delta: muro $313.143, riga EUR250/m 23,4a / P(20a) 14,4%, riga EUR500/m 17,3a / 85,4%, e P0 del motore col buffer di cassa BIT-EXACT contro PN.accumula. SCARTATO. 0/12 in ogni lente (mercato vero, IID, drift dimezzato, EUR250, EUR500); migliore -0,03% appaiato contro una risoluzione MC della differenza appaiata di 2,0pp, e su una cella che aspetta 1 giorno = P0 travestito. Il meccanismo, misurato invece che assunto: buy-the-dip 20% compra davvero 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%. Comprare meglio e comprare tardi sono la stessa mossa. Sotto la soglia bassa si ribalta: dip 5% compra a 1,009, cioe' PIU' IN ALTO — una condizione poco profonda non compra il calo, ritarda dentro la salita. Due errori catturati su me stesso da un controllo: (i) il ritardo-gemello dava "informazione" +11,5% sul mercato vero e mi avrebbe fatto scrivere che il dip predice — sotto IID, dove non c'e' niente da prevedere, la stessa colonna vale +14,9%, quindi e' meccanica (attesa variabile contro fissa); (ii) senza la colonna dell'attesa avrei letto P4 anti-dip come "stesso segno => rumore": e' piatto perche' in un mercato che sale la sua condizione e' quasi sempre gia' vera (16 giorni contro 3682). Rischio di venue separato dal timing: la cassa fuori dall'exchange riduce la penalita' di +2,4pp a p=1% e +3,8pp a p=2% su dip 10%, contro una penalita' di timing di -15,7pp, e P(libro azzerato) e' identica per tutte le politiche. Ordine di grandezza: la migliore politica di timing vale -0,1pp di P(20a); passare da EUR250 a EUR500 al mese vale +71pp. Solo script di ricerca. Book/pesi/cron/config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
96d37c7013 |
research(tp01): sizing conviction-aware SCARTATO — l'ottimo del knob sta ai due estremi opposti nelle due meta' del campione
§41 TP01-SIZE. Domanda: esiste una size che risponde alla CONVINZIONE (invece che
solo alla vol realizzata) e che, A ISO-VOL, alzi il drift di TP01? Sarebbe un
miglioramento k-indipendente sul 75% del libro live. Risposta: NO.
Griglia dichiarata PRIMA di guardare: 60 celle (rho = g(1/3)/g(1) x q = esponente
del vol-targeting), TF 1d, 24 ancore, segnale CONGELATO. Replica bit-exact del
canonico max|diff| = 0.0 su target_series E sui rendimenti di sleeve.
- FATTO STRUTTURALE che corregge la premessa: la convinzione NON vale {1/3,2/3,1}.
La media di 3 segni sta in {-1,-1/3,0,+1/3,+1} -> il bucket 2/3 e' ARITMETICAMENTE
IMPOSSIBILE. La famiglia ha UN grado di liberta' (rho), non tre: potenza/floor/
soglia sono la stessa cella riparametrizzata.
- NULL DEL RE-LEVERING misurato in forma pura: togliere il vol-targeting (q=0) porta
il CAGR da 16,32% a 46,75% (+186%) e a ISO-VOL fa -2,40pp. Era TUTTA leva.
- Il meglio dell'intera griglia e' +0,30pp di CAGR iso-vol. La cella scelta AL BUIO
(rho=0,25 q=1,25) peggiora l'hold-out del LIBRO in 0/24 ancore e il suo maxDD in
24/24, contro +0,19pp di CAGR.
- Spearman(ShIS, ShHOLD) = -0,527 sulle 60 celle: qui scegliere in-sample e' PEGGIO
di una moneta. Meccanismo misurato: Spearman(rho, ShHOLD) = +1,000 a TUTTI e sei i
q (monotono), mentre in-sample e' a gobba -> la convinzione e' informativa
in-sample e ANTI-informativa in hold-out. Nessuna cella e' proponibile.
- L'unica con guadagno hold-out robusto e' il BINARIO rho=1 (dShHOLD +0,243, 24/24),
che perde FULL e drift iso-vol e si potrebbe scegliere solo guardando l'hold-out.
- deflated-Sharpe 0,999 PASS ma QUASI VACUO (famiglia omogenea, sr0 0,197):
sensibilita' pubblicata, FALLISCE a sr0 >= 0,9. Conferma §10 dell'ondata 22/08.
- Controlli positivi 3/3 (de-levering puro, oracolo look-ahead con causality_ok=False,
anti-controllo rho=3). Eseguibilita' a $635: haircut 0,001 -> non e' il vincolo.
- Sottoprodotti: banda d'ancora del canonico ricalcolata su dati odierni (hold-out
canonico 0,441 = 96° pctl, mediana onesta 0,219) e altlib.tp01_baseline_daily NON
e' bit-exact col sleeve (1 ulp su 68,5% dei giorni: _to_daily fa (1+r).prod()-1).
Book, pesi, cron, config INVARIATI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf
|
||
|
Adriano Dal Pastro
|
3e3b41d842 |
research(tp01-ls): la gamba SHORT del trend a 1d e' SCARTATA — toglie drift a 0/24 ancore
§42 TP01-LS. Meccanismo TP01 di produzione CONGELATO, un solo grado di liberta': il pavimento della direzione TSMOM (floor 0 / -1/3 / -2/3 / -1, 4 trial dichiarati prima). Replica bit-exact 3/3 a 0.0 (floor=0 == CANONICAL long_only=True, floor=-1 == long_only= False, sleeve 50/50 == src/portfolio/sleeves._tp01_returns) + 4a replica candidate_daily vs tp01_baseline_daily a 0.0. Controlli positivi 4/4 (causality_ok su variante leaky, implausible_sharpe su serie senza perdite, gate iso-vol su leva pura, anchor_luck_delta A-vs-A). Esito: la short NON paga il proprio costo. dDRIFT appaiato -1.91%/anno positivo in 0/24 ancore, dShFULL -0.354 (0/24), maxDD +8.80pp (24/24); gate iso-volatilita' FAIL (dCAGR -6.19% a pari vol); senza il 2022 il divario RADDOPPIA (dShFULL -0.406, 0/24); anni positivi 2/8 (2022 +1.84, 2025 +0.27) e non compensano gli altri sei; marginal_vs_tp01 = NEUTRAL su tutte e tre le celle (multicut False, corr 0.79-0.93, alpha -2.6%/anno); la cella scelta AL BUIO in-sample e' IL CANONICO mentre quella scelta sull'hold-out e' floor=-1/3 = firma di selezione-sull-hold-out. Non e' morte-per-fee: a fee ZERO 1.338 contro 0.904. Attesa a priori del coordinatore CONFERMATA e superata. Unica metrica nel verso della short: dShHOLD +0.292 in 23/24 ancore — ma l'hold-out e' 1.6 anni, non e' selezionabile in-sample, e all'ancora canonica non si vede (-0.008: caso speculare della lezione 26/07). Libro 75/25 con SKH01: dSh -0.356 in 0/24, e la gamba short isolata ha Sharpe -0.335 con corr +0.10 a SKH01 (non ridondante, solo perdente). Trovato per strada: src/live/book.py clippa gia' TP01 con max(tp_frac, 0.0) -> il long-flat e' cablato anche nell'esecutore, non solo in CANONICAL. Nessun file di produzione toccato. Libro, pesi, cron, config INVARIATI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018M8Ncho6QV9FWLdyy4VyQf |
||
|
Adriano Dal Pastro
|
9973b04bc1 | research(wave-0822): SL-ANCHOR — il nodo sciolto dal LOG (la SPEC lo diceva non misurabile); rotolante ma il timore e' refutato, e il docstring della cadenza e' una trappola | ||
|
Adriano Dal Pastro
|
f5d88f10bb | research(wave-0822): FUNDING-AVOID — datati scartati, SPOT e' lead (+1,55%/anno a iso-vol) ma la domanda fiscale vale piu' del risparmio; corretto il muro USDC di §34 | ||
|
Adriano Dal Pastro
|
ef30c20af5 | research(wave-0822): SCALE-SPEC — chiave specificata, il tetto va sul PRODOTTO, e il test di guardia non si rompe ma smette di controllare; corretto un mio numero conflato | ||
|
Adriano Dal Pastro
|
df08460af0 | research(wave-0822): GATE-C — gate riformulato senza date, PASS 2/2; XS01 PAGA funding; il biglietto batte il versare solo perche' il piano esiste | ||
|
Adriano Dal Pastro
|
758bcce97f | research(wave-0822): PIANO-VERO — la tabella congiunta fisco+funding; EUR250/mese passa da P(20a) 92% a 14-26%, e le correzioni si sommano invece di compensarsi | ||
|
Adriano Dal Pastro
|
ee5cbb2c08 | research(wave-0822): FUNDING misurato — 2,16%/anno di drift, muri +17,5%; esposizione e funding sono correlati e la stima ingenua sottostima di 2x | ||
|
Adriano Dal Pastro
|
d930492d47 | research(wave-0822): CC01 riaperto col 2022 dentro — resta scartato, ma la liscezza era una proprieta' della COLONNA (HL 4,2 bps vs Deribit 106,2) | ||
|
Adriano Dal Pastro
|
73ae21c955 | research(wave-0822): WORST-DAY — la riserva sulla leva e' mal tarata di 2-4 ordini di grandezza, ma il knob di scala NON ESISTE; e il funding non e' in nessun backtest | ||
|
Adriano Dal Pastro
|
ebc8cf7d7c | research(wave-0822): GATE PROP-01 gamba (b) PASS 23/23 — e la distorsione su SKH01 dichiarata due volte e' refutata; P(50/g) 7,8% -> 4,4% | ||
|
Adriano Dal Pastro
|
dd4391b55b | research(wave-0822): GATE-RECON — il difetto ribalta STATARB (+1,96 -> -2,02), la premessa della rigenerazione e' confermata per via diretta | ||
|
Adriano Dal Pastro
|
e460caf667 | research(wave-0822): PROP-RECAL — il 42% del numero funded stava in 6 gambe che fuori campione non esistono; P(50/g) 42% -> 7,8% | ||
|
Adriano Dal Pastro
|
fd37add518 | research(wave-0822): BIN-FREQ — direzione reale (0/72 sul segno inverso), taglia = selezione; e due premesse del briefing refutate | ||
|
Adriano Dal Pastro
|
74539db8b8 | research(wave-0822): DEPEG — XS01-OOS sopravvive al falsificatore di venue; il caso peggiore non e' il depeg ma il 2025-10-10 | ||
|
Adriano Dal Pastro
|
82ccff2553 | research(wave-0822): TP01-SINISTRO — l'allarme e' falsificato nel verso; il rischio dell'ottimo funded e' XS01, non TP01 | ||
|
Adriano Dal Pastro
|
93ce12931a | CLAUDE.md: ritiro una regola mia — dealer_net_gamma non e' il GEX invertito, e' una convenzione dichiarata nel sorgente su questa VPS |