95424f0755a795dedba686a87d90d26ad84fbea6
667 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Adriano Dal Pastro
|
95424f0755 |
docs: il README era fermo a 15 giorni PRIMA del reset — riscritto contro lo stato vero
Ultimo commit del README: 2026-06-04. Reset v2.0.0: 2026-06-19. Per 75 giorni la prima pagina del repo ha pubblicato la libreria pre-reset (FADE/HONEST/PAIRS/TSMOM/SHAPE, PORT01-06) con Sharpe 7,84/10,06 e CAGR ~79% come risultati correnti — cioe' esattamente i numeri che §2 elenca sotto "non citare", dalla libreria che il reset aveva dichiarato artefatto. Meta' dei file citati non esiste piu' (strategies.yml, portfolios.yml, scripts/waste, scripts/portfolios, src/live/multi_runner.py), e l'esecuzione descritta era su TESTNET, che e' la causa del reset. - README riscritto (423 -> 152 righe): cosa gira adesso (TP01+SKH01 75/25, ~$2.050, cadenza oraria :47), i numeri nella lente di §2 (TWR +10,6%, non la crescita del conto), la riga che ordina il piano, il metodo e i suoi sei requisiti, il dato, la struttura VERIFICATA file per file, i comandi, i gate con le loro date, l'obiettivo con la sua onesta'. - CLAUDE.md §0 e memoria 40: registrato il difetto e la lezione — un reset invalida anche i documenti che nessuno rilegge; l'inventario di cosa cita numeri morti va fatto il giorno del reset, non 75 giorni dopo per caso. - Diario 02/09c: sezione col confronto riga per riga; coda dichiarata (l'inventario completo degli altri documenti pre-reset non e' stato fatto). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu |
||
|
Adriano Dal Pastro
|
de83909db9 |
un flag sconosciuto non e' l'azione di default: guardia su 18 script, indice USDE orario, pulizia
MISURATO oggi durante la revisione: `trades_db.py --help` non stampava l'uso, cadeva in sync() e riscriveva meta.ultimo_sync. Nessuno dei 18 script di scripts/live/ usava argparse: un flag sbagliato era il ramo else. Su journal.py avrebbe scritto pagina e riga di DB, su analista.py avrebbe speso una chiamata al modello e mandato un Telegram. - src/live/cli.valida: prima istruzione di ogni __main__, prima di connect()/sync/rete. --help -> 0 con l'uso; flag ignoto, valore mancante o posizionale -> 2 con l'elenco dei previsti (P4). NIENTE argparse: cambierebbe messaggi, codici d'uscita e --help di script che il cron gia' chiama. - 18 script cablati (i 3 che scrivono + 14 + cc01), flag invariati. - tests/test_cli_flag.py (30): elenco DERIVATO dalla cartella (P1), valida come prima istruzione, uso che documenta i flag, e i flag che il CRON usa davvero restano accettati (P15/P16); end-to-end su --help e flag ignoto con trades.db non toccato (M15). Verificato a mano: monitor_health --quiet, trades_db --sync --quiet, book_execute dry-run. Debito §5.15, primo passo: balance_watch (orario) registra `usde_usdc` a ogni campione — None con la ragione se illeggibile, mai 1,0. Il cablaggio nel bound quando la serie ha storia. Pulizia dalla revisione: tests/helpers.carica_script al posto della 15a copia del loader importlib (5 file del libro live); il fill di prova via upsert_fills invece di un INSERT che lasciava verified NULL; asserzioni non ancorate al padding; movimenti_capitale accetta le righe gia' lette (una SELECT invece di due ai due lati di una scrittura del cron). Test 910 verdi (+52). Diario 2026-09-02c. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu |
||
|
Adriano Dal Pastro
|
1279ea605a |
revisione 02/09, seconda tornata: il classificatore dei movimenti era cieco ~23 ore al giorno
Il feed 1h certificato si ferma alle 00:00: per le letture successive `asof` dava la stessa barra a t0 e t1, mercato "fermo" = 0, e qualunque calo >=10% del giorno sarebbe stato un "movimento" scorporato come prelievo (giornale dal 25/08, report da oggi). Con feed assente tutto era "ambiguo" e il report stampava e1/e0-1 sotto l'etichetta TWR. - journal.movimenti_capitale: stato "mercato non misurabile" (feed fermo/assente/barra mancante) => ambiguo con la ragione; leva_tetto = min(frac x n x scala, LEVA_LORDA_MAX) (P1). - journal.rendimento_twr: salto non classificabile => twr E trading None con motivo. - journal.pnl_giorno CHIAMA rendimento_twr (prima rifaceva cum - certi: "entrambi la chiamano" era falso); la pagina stampa il TWR; analista qualifica il cumulato "di cui versati". - trades_db --report: la classe di ogni salto con la sua misura (mercato max a leva piena). - book_execute docstring: banda dello stop -33,5%/-26,5% (era invertita), "non costa ordini" -> micro-ordini di ri-taglia (22/48, C2), latenza <=1h solo con feed fresca, conteggi di r0823 al posto di "raddoppia" (2 contro 1 e' rotolante vs pavimento sulla riga 4h; la peggiore misurata e' 24h). - test_book_cadenza: LTF_MIN importato da skyhook; tutte le righe attive della crontab (una sola); tre stati dello skip (col progetto ma senza cron_book => ROSSO); slot di release testato con venue_probe (il :07 come controllo positivo); parser regolare, passo > 0. - r0823_sl_anchor: guardia sul :47 (era sul vecchio :07), prosa al passato; cron_chain.sh idem. - CLAUDE.md: §5.7 frase invertita corretta, §5.14 limite vero (non l'artefatto della fixture), §2 ora della LETTURA (13:47Z), nuovo debito §5.15 (USDE fuori dal bound di mercato). - diari: tempi "scritto" corretti coi commit; sezione "Seconda tornata". Test +11 (858 verdi). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XDJsH3iDSaBns3ccpPBwiu |
||
|
Adriano Dal Pastro
|
835e0c8666 |
revisione 02/09: il rotolante si CONTROLLA ogni ora (non "si ri-ancora"), TWR con limiti dichiarati e tre stati
Quattro segnalazioni della revisione sui commit di oggi, tutte verificate e riparate. 1. book_execute.py (+ CLAUDE.md §5.7, memoria 40): «il disaster-SL rotolante si ri-ancora ogni ora» era falso — ensure_disaster_sl lascia il bracket finche' lo stop e' entro il 5% e la taglia entro il 10%; il giro orario CONTROLLA, ri-ancora oltre la tolleranza (mark +5,263%/-4,762%). Lo stop siede fra -26,3% e -33,3% dal mark corrente. 2. journal.rendimento_twr: limite dichiarato (D5) — l'intervallo che contiene un movimento certo esce intero dal rendimento, il suo P&L di mercato va in `certi`; errore massimo meta' del movimento per costruzione (25/08: ~$0,5). Non si stima (P12). Segmenti a lunghezza zero non prodotti; nessun tempo a mercato -> 0,0 dichiarato numero. 3. base di equity zero: `twr` E `trading` None con motivo (il salto 0->X e' invisibile al classificatore, `trading` valeva l'intero conto); il report stampa n/d. 4. test_book_cadenza: la guardia estrae ogni prescrizione «ogni/every N unita'» e pretende 60 minuti, con controllo positivo (M15); limite P13 dichiarato. Test +5 (847 verdi). Diari 02/09 e 02/09b con la sezione "Revisione". Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke |
||
|
Adriano Dal Pastro
|
861cc7fc27 |
debito 7: la cadenza del libro e' ORARIA — docstring riscritto, tre fonti tenute d'accordo da un test
Il docstring di book_execute.py prescriveva «ogni ~230 minuti» mentre il cron gira ogni ora (47 * * * *). Era il docstring a sbagliare: sulla riga 4h BTC raddoppia gli scatti del disaster-SL rotolante (r0823_sl_anchor.py), e chi avesse "corretto" il cron verso il docstring avrebbe spostato il libro sulla riga peggiore. - scripts/live/book_execute.py: CADENZA: ORARIA, la riga di crontab, la ragione (giro idempotente, latenza SKH01 <=1h, ri-ancoraggio orario) e il divieto esplicito con la data. - tests/test_book_cadenza.py (10): deriva e confronta docstring, intestazione di cron_book.sh e crontab installata (crontab -l; SALTATO se illeggibile, non verde); parser a 5 campi solo per cadenze regolari; 60 < 230 < 240; minuto != :00. - docs: CLAUDE.md §5.7 chiuso, §13 conteggio 842; memoria 40; diario 02/09b. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke |
||
|
Adriano Dal Pastro
|
2f701b8469 |
debito 14: il report stampa il TWR (+10,61%), non il bonifico (+243%)
`trades_db.py --report` calcolava e1/e0-1 sulla serie grezza di equity: il 96,3% del numero era il versamento di $1.399,39 del 25/08. La riparazione (journal.movimenti_capitale) esisteva e non aveva attraversato il confine fra i due lettori della stessa serie (P1). - src/live/journal.py: `rendimento_twr` — funzione unica, spezza la serie sui movimenti CERTI e moltiplica i segmenti; gli ambigui restano dentro, dichiarati (P12); tre stati. - scripts/live/trades_db.py: report() la chiama; stampa TWR con segmenti datati, movimenti elencati, trading al netto, delta $ etichettato "movimenti INCLUSI"; il % grezzo sparisce. - test: +5 in test_journal.py (incl. riproduzione del +10,80% del diario 01/09, M23), +2 in test_trades_report.py sul testo stampato con connect() deviato in tmp. 832 verdi. - docs: CLAUDE.md §5.14 chiuso, §2 e §13 aggiornati; memoria 40; diario 02/09. Limite ereditato e dichiarato (D5): +10% di trading fra due letture consecutive tocca la soglia del rilevatore e a mercato fermo verrebbe classificato movimento. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke |
||
|
Adriano Dal Pastro
|
bc43218a12 |
docs: soldi fermi §73 — l'operatore sceglie di versare (piano 27/07: €5k dentro, ~€1k fuori)
Conclusione dell'operatore (02/09): "mettere gli XEON su Deribit col sistema attivo". Si', ed e' cio' che la memoria aveva scritto il 27/07. Tre precisazioni, tutte gia' misurate e ora registrate: - €5.000, non €6.043: la protezione venue satura a qualunque quota > 0, l'ultimo migliaio dentro compra ~€100/anno e butta via l'assicurazione; - il "~€600" e' un'attesa a banda larga, non un tasso (libro a mercato il 22% dei giorni, TWR +10,8% in 70g, hold-out TP01 ~+0,05, fisco −30%/10a); - fondo d'emergenza da dichiarare. Nessuna azione di config (cap dinamico, rilevatore collaudato il 25/08). In attesa di importo e data; al deposito una riga di giornale, scritta prima e non ricostruita dopo. N9: le opzioni sicure (+€52-62/anno) sono state viste e messe da parte con motivo. - CLAUDE.md §1: riga "soldi fermi" + indice §1-73 - RESULTS §73 + riga d'indice - memoria 30-piano-capitale-fisco: voce - diario 2026-09-01d: §7 la conclusione dell'operatore - docs/journal/2026-09-01.md (voce del cron, non era committata) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
d95fabf060 |
soldi fermi: i modi esistono e valgono €5/mese — BOT/conto deposito +€52-62/anno, sUSDe distrugge lo split
On-venue chiuso con l'elenco intero: 4/50 valute remunerate = le 4 gia' chiuse il 31/08. L'USDC su Deribit non e' fermo (base di sizing + cuscino). I €6k in XEON sono lo split-cassa. Tassi dal web con fonte (BOT 2,768% asta 08/2026, DFR 2,25%, conti deposito 3,25-3,50%, sUSDe ~9%). In euro netti su €6k: XEON 81, BOT 133, conto deposito 143, sUSDe 350 (ma stesso emittente dell'USDE: split distrutto), libro ~600 (trading, split distrutto). Miglior guadagno sicuro: +€62/anno. €100/mese di bonifico = +4,07%/anno di drift. Non sono pareri fiscali. Nessun ordine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
1c0549080c |
PAVIMENTO-LEVA (§72): il pavimento non licenzia taglia, 0/16 — e corregge §71
Domanda dell'operatore: "possiamo usare quanto conosciamo del pavimento per studiare una strategia". L'inverso di COLLAR01: non "quanto DD mi risparmia il pavimento a taglia fissa" (perdeva contro il de-levering) ma "quanta TAGLIA mi autorizza a DD fisso" — l'unica cosa che il de-levering non puo' comprare (cambia la FORMA, non la proporzione), e la grandezza su cui vive il tetto di leva del progetto (n·frac·scala·sl <= 0,50 => 1,67x). RISULTATO: 0/16. La sola put a premio reale PEGGIORA il maxDD in 16/16 celle (FORTE 51,83% -> 55,4-75,8%; LARGO 71,94% -> 74,8-81,7%), quindi k_f = 1,000 ovunque: niente da licenziare. Monotono nella protezione: piu' la put e' vicina, peggio va — il bleed del premio E' il drawdown. 🚨 CORREGGE §71 (stesso giorno). Stamattina A1 diceva "il pavimento funziona davvero". E' il COLLAR a ridurre il DD, non il pavimento: a premio zero la put lo riduce (51,83 -> 36,76, il controllo), a premio reale lo peggiora => tutto il beneficio e' mangiato dal premio, e oltre. Nel collar la riduzione viene dal TETTO: il suo premio compensa il bleed, e cappare l'upside abbassa il picco da cui il DD si misura — un picco piu' basso, non protezione. Premio di pareggio: 36-79% del reale; il DVOL sta 1,32x sopra la RV, quindi un prezzo equo (~76%) sfiora il pareggio nelle celle migliori e lo manca nelle altre. Il motivo di §46 (beta) non si applica — a beta 1,0 la put paga davvero — ma il verdetto di §46, "il maxDD SALE", si riproduce per un motivo diverso. Corretti il diario di §71 (titolo e A1), RESULTS, memoria. IL MECCANISMO (B2), trasferibile: i drawdown di BTC sono GRIND. maxDD FORTE 2021-07-20 -> 2022-05-06 = 290 giorni; LARGO fino al 2023-10-16 = 818. Una put a 7-14g copre UNA finestra; il DD che conta dura 20-60 finestre; la put scade OTM ogni settimana (para nel 0-9% dei cicli) mentre il premio sanguina. Non protegge nemmeno la finestra peggiore: 14g FORTE -22,9% nudo -> -23,6% col pavimento. Su BTC il pavimento compra protezione contro la cosa sbagliata. LA LICENZA DEL DISASTER-SL E' DI CARTA (B3), scritto prima che sia comodo: con la put a 5d/14g a 21,9% dallo spot, sostituire sl con quella distanza darebbe 2,28x. Ma l'invariante limita UN episodio, la put limita UNA finestra, e il massimo su finestre consecutive non e' limitato da nulla: 1 finestra -23,6% (coperta), 8 finestre -33,6% (non coperte) => a 2,28x un grind di 112 giorni costerebbe il 77% dell'equity. disaster_sl_pct NON si sostituisce con la distanza di un pavimento. Aggiunto a CLAUDE.md §3. GATED SULL'IV (B4) — la copertura dinamica che §46 non aveva provato: put ON solo sotto il 25°/50° pctl di DVOL/RV. Migliora molto (FORTE +3,8% -> +8,4%) ma resta sotto la base (+10,04%) e il DD resta >=. L'incollatura ignora lo spread delle transizioni A FAVORE del gated: perde a maggior ragione. Quattro attese a priori (B1-B4) scritte prima, tutte confermate. NON MISURATO, dichiarato: nessun DSR (cade al primo gate); nessuna lente reale; nessun pavimento a scadenza lunga (30-90g, che coprirebbe piu' finestre di grind) perche' l'operatore ha vincolato a <=15 giorni — e' l'unica variante che B2 lascia aperta, e sta fuori dal vincolo. Libro, pesi, cron, config INVARIATI. Nessun ordine. Test 25/25 sui filoni. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
ec8478308f |
GATE SCALA-01: la chiave di scala esiste, ed e' INERTE (SPEC §8 punti 1-4)
Chiude il debito che CLAUDE.md dichiarava da settimane: la regola "ogni cambio di scala passa dal cap di config, non da target_vol" NON era implementabile perche' una chiave di scala non esisteva — qualunque cambio sarebbe finito su WEIGHT/W_TP01/W_SKH, cioe' codice su un percorso con soldi veri e per giunta nel posto sbagliato (W_TP01/W_SKH sono il RAPPORTO 75/25, non la taglia). Specifica gia' scritta in docs/research/SPEC-scale-key.md (618 righe, 9 condizioni di gate, prototipo). Non ho progettato: ho eseguito i punti 1-4. 🚨 config/live.json NON E' STATO TOCCATO. La chiave e' assente, vale 1,00, e T7 dimostra bit-exact che il libro e' quello di ieri (max|diff| = 0.0). Verificato anche a runtime: book_execute in dry-run da' gli stessi target del cron delle 15:47 (BTC $+355, ETH $+214). LE QUATTRO DECISIONI CHE NON SONO DI COMODO - La scala si applica DOPO il clamp. Prima, il cap se la mangerebbe proprio nei giorni di massima convinzione (a tp=1/sg=+1 il grezzo vale esattamente cap => k_eff tornerebbe a 1,00 a ogni k): sarebbe un cambio di FORMA travestito da cambio di taglia, e la curva g(k) con cui il gradino viene autorizzato non descriverebbe quel libro. Prezzo dichiarato: il cap diventa il tetto del libro UNITARIO, e la guardia sulla leva lorda va ricostruita. - Il tetto e' sul PRODOTTO e sta nel CODICE. Sulla sola chiave lascerebbe aperta la porta accanto (frac 0,625 x scala 1,25 = 1,562x); in config sarebbe un lucchetto con la chiave attaccata. LEVA_LORDA_MAX 1,25 in src/live/book.py => il gradino a 1,50 richiede codice, quindi review. - Fuori scaletta o fuori tetto = STOP, non clamp. book_execute si ferma, non invia, allerta (ScalaNonAutorizzata). E SCALA_LADDER (1,00 · 1,25) rende INESPRIMIBILE "solo un po'": 1,05 non e' prudente, e' fuori scaletta. - La scala vive solo sul percorso fidato (equity illeggibile => 1,00), cosi' "il fallback non e' piu' permissivo" e' vero per costruzione. Ma la VALIDAZIONE avviene sempre: una config rotta non si nasconde dietro un giro in cui l'equity non era leggibile. LA GUARDIA CHE MORDE PER PRIMA non e' il peggior giorno (k <= 3,49x) ma il COSTO di un disaster-SL (k <= 1,67x, 2,1x piu' stringente): l'invariante n_asset x frac x scala x disaster_sl_pct <= 0,50 scatta anche se qualcuno allarga lo stop invece di alzare la scala. TEST T1-T11 (tests/test_book_scale.py, 18 verdi). Il piu' importante e' T1b: a k=1 l'implementazione simmetrica e quella asimmetrica danno lo STESSO numero, quindi un test di simmetria scritto sul caso di default ha potenza ZERO. T1b verifica che le due coincidano a k=1 (il rischio e' reale) e che fuori da k=1 l'asserzione le SEPARI, con un'implementazione asimmetrica scritta nel test apposta perche' fallisca. SORVEGLIANTE scale_watch (cron_daily, 3 domande / 3 azioni / 3 stati, una allerta per streak, marcatore scritto solo dopo invio riuscito — debito #2). Riporta la frequenza del ramo di fallback, che sopra il 2% in 90 giorni invaliderebbe la regola: misurata 0/1.676, coi 19 giri "paper capital" (pre-finanziamento, dove il libro non invia) contati e dichiarati a parte. Non puo' impedire la modifica: la rende visibile entro 24h e attribuibile. CHIUDE il debito #5 di §5: T2/T3 sostituiscono il vecchio test_leva_massima_da_config (che misurava frac x n_asset mentre la grandezza vera e' frac x n_asset x scala), e T11 verifica che sia rimasto cancellato. NON FATTO, deliberato: la chiave in config (punto 2 lo vieta), GATE SCALA-01 (A2 richiede >=30 giorni a 1,00 col sorvegliante attivo — "l'unico modo di scoprire che il sorvegliante e' rotto mentre la leva e' ancora 1,00"), r0726_fee_sensitivity rifatto (A7: serve solo al gradino; a 1,25x una liquidazione costerebbe 1,25% non 1,00%, e ereditarlo sarebbe l'errore). Nessun ordine. Suite: 825 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
05816c49f9 |
COLLAR01 (§71): il pavimento funziona, il tetto lo paga troppo — e cio' che vince e' VRP01
Chiesto dall'operatore in quattro battute: hold BTC long o short coperto in
opzioni, scadenza <=15gg, "ridurre la vincita ma bloccare la perdita" (=>
collar, non put protettiva), entrata gated da indicatori ("forte bull"), e
uscita dalle opzioni fra il 50% e il 75% del tempo.
PERCHE' SI POTEVA RIAPRIRE DOPO §46. §46 (tail-hedge) fu refutato sul beta
+0,076 del libro — "non si assicura un libro che nei crash e' gia' quasi
piatto". Qui il sottostante e' un hold di BTC, beta 1,0: quel motivo non si
applica. E §46 dichiarava non provata proprio la copertura gated su regime.
L'entrata non aggiunge un solo parametro: tsmom_blend media tre np.sign() su
(30,90,180) => valori in {-1,-1/3,+1/3,+1}, quindi "forte bull" = |blend|==1
(52,5% dei giorni) contro il confronto dichiarato |blend|>=1/3 (97,1%).
RISULTATI (lente lunga 2021-03 -> 2026-09, 5,44 anni; griglia 48 celle
dichiarata prima + 36 di estensione dichiarata):
- A1 CONFERMATA: il pavimento FUNZIONA, maxDD scende in 36/48 (§46: saliva
in 162/162). La meta' della domanda ha risposta positiva.
- A3 CONFERMATA: il de-levering lo fa meglio in 45/48. Δdrift/ΔmaxDD 7,90
(gate forte) / 1,98 (largo): 2-8 punti di drift per punto di DD.
- C9 in forma pura: il tetto taglia il 46,2% dei cicli VINCENTI, il pavimento
para il 6,7% dei PERDENTI — 7x piu' spesso sui vincenti: troncatura.
- M1: collar Sharpe 0,508 vs TP01 0,852; TP01+10% => +0,000 di Sharpe e
+2,32pp di maxDD.
IL FATTO CHE VALE PIU' DEL VERDETTO. Le 3 celle vincenti stavano tutte sul
BORDO; estesa la famiglia vince 35/36 nell'ANGOLO (dput 0,02 / dcall 0,50,
Sharpe 1,471) — e il limite di quell'angolo e' una COVERED CALL: la pendenza
porta fuori dalla domanda posta e dentro lo short-vol. E quel 1,471 e' il
prezzatore che si paga da solo: DVOL/RV-forward 1,320 a 7g (sopra nel 76,9%
dei giorni) => riprezzato alla vol vera l'angolo cade a 0,511, che e' VRP01
(0,47). Non una scoperta: VRP01 per una strada piu' lunga. §3 lo blocca.
USCITA ANTICIPATA: implementata (exit_frac) e COSTA. Cella onesta gate forte:
drift +9,48% (scadenza) -> +3,84% (50%), esito da VINCE a perde sotto 0,75.
Il meccanismo previsto c'e' (VRP residuo +3,38 -> +1,27pp) ma lo spread lo
travolge. Corregge l'applicazione di §46: "un roll anticipato non paga f"
vale per una copertura solo LONG; in un collar la gamba venduta va
RICOMPRATA, quindi si paga f sulla parte che a scadenza si regolava gratis.
L'asimmetria si INVERTE quando la struttura ha una gamba corta.
CONTROLLI DELL'APPARATO 3/3 (M15): pranzo gratis riconosciuto (maxDD
51,83%->36,76%, drift +10,04%->+35,69%), premio x10 rifiutato, zero-cost
finito. Cinque difetti miei catturati dai controlli, non a occhio: bisezione
zero-cost invertita (dava Sharpe -3,9), dcall=NaN nella cassa, C9 non
consapevole della direzione (S1>S0 non e' "vincente" per uno short), e due di
contabilita' che avrebbero ADULATO il collar (base che rollava lo spot
pagando ~3,6%/a di fee inesistenti; roll che chiudeva lo spot senza motivo).
Corregge anche un muro di §46: il tick da 5 USDC e' della famiglia USDC; la
catena che raccogliamo e' 100% inverse, quindi li' non si applica.
Regole nuove in CLAUDE.md: M29 (un edge da opzioni prezzate a modello si
riprezza alla vol REALIZZATA prima di crederci), M8 esteso (un argmax sul
BORDO e' una pendenza, non una cella), C4 esteso (il segno dell'asimmetria di
f dipende dal verso della gamba).
Libro, pesi, cron, config INVARIATI. Nessun ordine. Suite: 807 passati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
5bcf212923 |
stato trades: il "+243%" del report e' per il 96,3% un bonifico — TWR +10,80%
`trades_db.py --report` stampa `$598,06 -> $2.051,84 (+243,08%)` accanto a `netto +40,77`. La serie di 1.657 letture orarie contiene UN SOLO salto: il versamento di $1.399,39 del 25/08 11:47Z. Confermato dal classificatore ufficiale del progetto (`journal.movimenti_capitale`: certi 1399.39, ambigui 0.0, classe `movimento`). Al netto: TWR +10,80% spezzato sul versamento (+11,61% fino al 25/08, -0,73% dopo), equity +$54,39 in 69 giorni. Il giornale, che lo scorporo lo fa gia', concorda: $+62,00 al 31/08, -7,61 di marcatura fino a oggi. Il difetto non e' nuovo — e' la stessa riparazione che NON ha attraversato il confine. `journal.py:121` porta il caso d'origine nel docstring (la voce del 25/08 che dichiarava «+$1.414,57» di giornata); `trades_db.py:83` calcola `100*(e1/e0-1)` sulla serie grezza e non chiama `movimenti_capitale()`, che e' a un import di distanza. Variante di P1: non un sorvegliante che ridichiara il bersaglio, ma una riparazione che non si e' propagata al secondo lettore della stessa serie. Danno sui soldi nessuno (sola lettura); danno di citazione si', ed e' l'unico numero fuorviante che il progetto produce su richiesta di un comando pubblicato in §13. Codice NON toccato: sta su uno script che legge il libro vivo. Debito #14. Stato del libro al 01/09 16:47Z, per il resto invariato: 45 fill (ultimo 31/08 15:47), 29 round-trip (21 in utile, netto +40,77), posizioni BTC 0,0045 @ $79.208,11 e ETH 0,0872 @ $2.473,04, non realizzato -$11,72, leva lorda 0,27x. Nessun fill da 25 ore = banda morta del min_order_usd $5, non un blocco (il cron logga «gia' al target» a ogni giro). monitor_health 8/8 OK, riconcilio 44/45 con 0 prezzi divergenti (l'unica coppia scoperta e' il difetto noto dei sei giorni fra log e jsonl sullo stesso fill). - CLAUDE.md §2: riga nella tabella dei numeri da non citare - CLAUDE.md §5: debito #14 - docs/diary/2026-09-01-stato-trades.md - docs/journal/2026-08-31.md (voce del cron, non era committata) Suite: 800 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
8d391ed29a |
margini: la pagina si ricostruisce dal gateway — e l'"IM %" non e' il margine delle posizioni
L'operatore ha incollato la riga CROSS col modello ATTIVO invece che proiettato:
Available $2.010,81 · IM 2,15% · MM 0,37%. Il gateway, letto allo stesso minuto, dice
available_funds = 2010,82299383. Scarto $0,01.
(a) LO SCREENSHOT NON SERVE PIU'. La riga CROSS della pagina E' `available_funds`, che
leggiamo da soli a ogni giro. Ieri quella schermata era l'UNICA fonte per l'haircut e per il
modello attivo, e per averla e' servito un passaggio dall'operatore e da Wasabi.
r0831_margini_conto.live() la ricostruisce.
(b) TERZA CONFERMA DEL 5%, E LA PRIMA ESATTA:
1.400,71 + 0,95x654,176 + 0,20 dust - 11,553 IM = $2.010,82 contro pagina $2.010,81
Scarto $0,007. Il 10% della vecchia config non e' improbabile: invertendo la stessa riga da'
IM = -$21,16, aritmeticamente impossibile. Tre strade indipendenti, stesso numero.
(c) MIA LETTURA SBAGLIATA, CORRETTA. L'"IM %" della pagina e'
(margin_balance - available)/margin_balance, non il margine delle posizioni:
haircut USDE $32,71 = 1,592% + IM vera $11,55 = 0,562% = 2,153%
Il 74% di quella percentuale e' HAIRCUT. E' salita da 2,13% a 2,15% perche' abbiamo comprato
collaterale a rendimento — letta come rischio direbbe che ieri sera abbiamo alzato la leva
comprando USDE, l'opposto di quello che e' successo. La MM invece e' pulita ($7,60) e non puo'
contenere l'haircut, che da solo la renderebbe negativa: le due colonne hanno basi DIVERSE e la
pagina non lo dice. Regola: una percentuale letta da una schermata va INVERTITA nella sua
definizione prima di essere confrontata (P7 su superficie nuova).
(d) LA BOCCIATURA DI X:PM ESCE RAFFORZATA. La KB da' USDe al 5% sotto entrambi i modelli:
l'haircut si cancella e l'inversa da' il margine di POSIZIONE sulle stesse due posizioni,
stesso istante — X:SM $11,64 contro X:PM $88,23, 7,6x, e 9,3x la MM. Due misure pulite,
stesso verso. E la riga X:SM era una PROIEZIONE di un modello inattivo che oggi si riproduce
al centesimo: anche la riga X:PM era affidabile, quindi decidere senza provare era corretto.
Ora si sa perche', non solo che.
Suite: 800 passati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BmkQty4a99pVmvwGfxAMQ9
|
||
|
Adriano Dal Pastro
|
62025e7840 |
docs: X:SM ri-sondato e X:PM scartato — il modello di margine entra nel tetto ma non lo spiega
Le due misure di ieri sera vivevano solo in chat. Ora sono nei documenti, con i numeri e con cio' che le riapre. X:SM vs S:SM, stessa notte, stesso conto: S:SM tetto [643,18 - 644,18) equity $2.055,56 -> 31,29% - 31,34% X:SM tetto [654,18 - 655,18) equity $2.054,90 -> 31,84% - 31,88% +0,55pp = +11 USDE ~ $11. L'ipotesi "il tetto dipende dal modello di margine" e' VERA e INUTILE: per arrivare al 70% mancano ~38 punti, un fattore 2,2x. Un'ipotesi confermata al terzo decimale e falsa all'ordine di grandezza si archivia come falsa — il tetto resta misurato e non spiegato. La lezione di metodo vale piu' del risultato: il primo probe fu un BUY 20, RIFIUTATO, e da solo avrebbe chiuso la questione con "tetto invariato". Falso: il tetto si era mosso di 11, cioe' MENO della taglia del probe. Un probe unico di taglia sbagliata produce un falso negativo che si legge come risultato — la taglia si sceglie sulla risoluzione dell'effetto che si cerca (M13 in veste nuova). X:PM valutato e SCARTATO senza provarlo: la pagina margini lo dice gia'. Available Balance $1.935,14 contro $2.011,73 (-$76,59), MM 3,43% contro 0,37% (~9x). Il PM e' basato su scenari e premia il rischio che si compensa; due long direzionali nudi sono il suo caso peggiore. La MM e' la riga che decide: non morde a 0,28x ma sposta il punto di liquidazione. NON "PM e' peggio" ma "PM e' peggio PER QUESTO portafoglio" — cosa lo riapre: il deploy di VRP01 o di un altro sleeve di opzioni, che fa compensare il rischio e cambia il segno del confronto. Registrato anche il prezzo del cross, che non e' zero: sotto segregato l'USDE era ring-fenced dalle perdite del libro, sotto cross risponde l'intero conto. Non morde oggi (perdita massima plausibile ~$617, dentro il solo USDC), ma il verso e' cambiato e tornare a S:SM lo ri-recinta. Suite: 800 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BmkQty4a99pVmvwGfxAMQ9 |
||
|
Adriano Dal Pastro
|
4705d71ceb |
tetto ri-sondato sotto X:SM: il modello entra ma non spiega — +11 USDE
L'operatore e' passato a Cross: Standard Margin. Verificato dal gateway: available_funds USDC da ~$1.400 a $2.011,09 contro $2.010,90 attesi con haircut 5% (scarto $0,19) — seconda conferma indipendente del 5%, da una lettura completamente diversa dallo screenshot. RI-SONDATO il tetto a saldo neutro, stesso metodo del 31/08: SEGREGATO S:SM [643,18 - 644,18) equity $2.055,56 = 31,29-31,34% CROSS X:SM [654,18 - 655,18) equity $2.054,90 = 31,84-31,88% Il modello ENTRA nel tetto ma NON lo spiega: +0,55pp = +11 USDE (~$11), non le centinaia che servirebbero per il 70% (manca ancora un fattore ~2,2x). L'ipotesi "il tetto dipende dal modello segregato" e' quantitativamente demolita come spiegazione, pur essendo tecnicamente non nulla. Nota di metodo: il primo probe (BUY 20) era stato rifiutato e avrebbe fatto concludere "tetto invariato". Era solo troppo grosso: il test a saldo neutro con passi piccoli ha mostrato che il tetto si era mosso di 11. Un probe unico di taglia sbagliata produce un falso negativo che si legge come risultato. config: venue_cap_frac 0.312 -> 0.318 (bordo basso del bracket CROSS, che e' il modello attivo; se si torna a S:SM va rimesso a 0.312). E il costo del passaggio, che va detto: sotto SEGREGATO l'USDE era RING-FENCED dalle perdite del libro (solo il silo USDC rispondeva); sotto CROSS risponde l'intero conto. Non morde oggi (perdita massima plausibile ~$617 col disaster-SL, dentro il solo USDC) ma il rischio strutturale ha cambiato verso. Il cross ha comprato $611 di margine utilizzabile — inutile a 0,28x, serve sopra ~1,4x che non e' autorizzata — piu' $11 di capienza. Suite: 800 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
fd7595e819 |
margini: haircut 5% (la config aveva torto) — e il conto NON e' cross-collateral
Lo screenshot della pagina margini era su Wasabi (rclone remote wasabi:, bucket
adp-work, cartella _scambio), non sulla VPS: per questo il percorso non esisteva.
Riconciliazione riproducibile in scripts/research/r0831_margini_conto.py (N11).
(a) HAIRCUT = 5%. La pagina non lo espone come numero: si ricava per differenza,
perche' il CROSS conta l'USDE scontato e il SEGREGATO non lo conta affatto.
S:SM (attivo) USDC Available 1.400,86 vs equity 1.412,28 - IM 11,55 = 1.400,73
X:SM CROSS Available 2.011,73
contributo USDE al cross = $610,81 su $643,05 -> 5,0137%
5% (KB) atteso $610,89 scarto $ 0,09 TORNA
10% (nostra) atteso $578,74 scarto $32,06 NON torna
config/live.json: haircut 0.10 -> 0.05. Il 26/08 il 10% fu registrato come
"verificato sul venue" senza traccia di COME, e non lo era.
(b) 🚨 IL CONTO NON E' CROSS-COLLATERAL: modello attivo "Segregated: Standard
Margin" (S:SM). Nella tabella del modello attivo l'USDE NON COMPARE: non fa
margine per i perp USDC-settled del book, e l'haircut oggi non si applica. Il che
spiega a posteriori perche' la misura di stamattina trovava $0,0000 accantonati:
non stavo guardando nel secchio sbagliato, cercavo un parametro che sul nostro
conto non e' in vigore.
NON MORDE: al massimo lordo del libro (1,0x = ~$2.056 di nozionale) l'IM sarebbe
~$41 contro $1.400 di USDC disponibile, 34x di copertura. Nessuna decisione
operativa cambia oggi.
Ma la premessa in CLAUDE.md era falsa, e il modo in cui lo era e' istruttivo:
"l'equity del book e' il TOTALE cross-collateral" metteva due cose sotto un nome
solo. Come RICCHEZZA sommare USDC+USDE e' giusto ed era il punto della riparazione
del 26/08 (evito' il falso "USCITA DI FONDI -24%"); come CAPACITA' DI MARGINE e'
sbagliato, perche' nel modello attivo l'USDE vale zero. Finche' il margine non
morde le due coincidono nell'uso, e infatti non era mai emerso.
Corretta anche la riga di usde_watch che stampava "margine utilizzabile ~$2.013
(haircut 10%)": era falsa due volte insieme. Ora stampa il solo silo USDC e,
accanto, cosa darebbe il cross.
La quota USDE non e' "collaterale diversificato": e' cassa a rendimento FUORI dal
sistema di margine. Passare a X:SM aggiungerebbe $610,87 di margine utilizzabile
ma porta la meccanica cross (collateral fee 0,05%/giorno sul saldo negativo,
ribilanciamento automatico): decisione dell'operatore, oggi non serve.
Ipotesi nuova e non verificata: il tetto del ~31,2% potrebbe dipendere proprio dal
modello segregato. Si saprebbe passando a X:SM e ri-sondando.
Suite: 800 passati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
c8be83ef6e |
haircut: la divergenza non si chiude dal gateway — misurato perche', non supposto
Richiesta: leggere la pagina margini del conto per chiudere il 5% (KB) vs 10% (nostra config). NON E' RAGGIUNGIBILE da qui: account_summary per la valuta USD da' "Invalid currency", il parametro `extended` viene ignorato, e il gateway filtra a 8 campi senza initial_margin/maintenance_margin (debito #11). E non e' che si sia guardato nel secchio sbagliato: la contabilita' TORNA ESATTA senza alcun termine di haircut. USDC equity 1412.281074 available 1400.728093 riservato 11.5530 USDE equity 643.175691 available 643.175691 riservato 0.0000 posizioni lorde $577.65 -> IM al 2% = $11.5530 -> RESIDUO -$0.0000 Un haircut al 5% chiederebbe $32,16 accantonati, al 10% $64,32: non ci sono. => L'haircut non e' osservabile in ALCUN campo esposto. O e' applicato solo nella vista cross/USD che il gateway filtra, o non e' applicato al nostro conto: da qui le due cose non si distinguono, e non le si sceglie tirando a indovinare. La divergenza resta APERTA, ma con la ragione MISURATA invece che supposta. La chiudono 30 secondi sulla web UI o delle chiavi API Deribit (la decisione gia' dichiarata nel debito #11, non un refactor). Nel frattempo non morde nulla di osservabile: l'IM e' il 2% del nozionale e l'USDE resta interamente disponibile, quindi 5% o 10% non cambia una cifra operativa. L'operatore ha dichiarato che il conto e' STANDARD MARGIN. Aggancia due cose: - la colonna da leggere e' Haircut (X:SM), che per USDe dice 5% come la PM: ora si sa con certezza quale numero ufficiale contraddice il nostro; - spiega perche' l'IM misurata e' esattamente 1/50: il nuovo modello di margine del 05/08 si applica ai "standard margin accounts", tier 1 C1=50. Un fatto dichiarato dall'operatore e una misura fatta senza conoscerlo si confermano a vicenda — ed e' la PRIMA affermazione del venue che il conto conferma questa settimana, dopo l'APR USDC e "all users can buy BUIDL". Lo screenshot non e' arrivato: il percorso sta sul desktop dell'operatore, non sulla VPS. Suite: 800 passati. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
30286ea033 |
venue_news: sorvegliare cosa il venue ANNUNCIA — e due correzioni dalla KB
Nasce dall'annuncio sulla fine della Proof of Reserves. La notizia in se' vale
poco: si perde un segnale ad alta frequenza e DEBOLE (una PoR auto-pubblicata
prova che gli attivi esistono in un istante, non che coprano le passivita') e si
guadagna un audit annuale indipendente sotto VARA piu' il 90% degli attivi presso
Coinbase come custode. E non l'abbiamo mai sorvegliata: zero occorrenze nel
codice. Rinunciato di proposito a catturare l'ultimo dato — uno snapshot singolo
auto-riportato non regge lo standard di prova e non permetterebbe di stimare `p`.
CONSEGUENZA VERA: la decisione "100% Deribit fino a $20k" ha fra i suoi riapritori
"`p` che diventa stimabile invece che assunto". Dal 1/9 il segnale pubblico passa
da quotidiano ad ANNUALE: da una serie si stima, da un punto all'anno no. Quel
riapritore diventa praticamente irraggiungibile => la decisione e' ora gated SOLO
dal capitale.
TROVATO CERCANDO: esiste un feed RSS degli exchange-update, e conteneva quattro
annunci materiali che nessuno leggeva. Il caso che decide: le specifiche dei perp
USDC sono cambiate il 18/08, ANNUNCIATE IL 14/08. check_specs() e' nato da quella
svista e gira ogni ora, ma rileva la deriva DOPO; il feed l'avrebbe detta quattro
giorni PRIMA. La prima volta e' andata bene solo perche' i cambi erano RIDUZIONI.
Costruito scripts/live/venue_news.py (in cron_daily accanto a fee_watch):
- NON interpreta: dice "e' uscito questo, guardalo". Nessun automatismo su un
testo di marketing (P13). Classifica solo l'urgenza.
- parole-chiave DERIVATE da deribit._CONTRACT e config/live.json, non
ridichiarate (P1): chi aggiunge un asset allarga la sorveglianza da solo, ed
e' il test che lo blinda.
- primo giro semina senza allertare (P9); feed illeggibile -> exit 2, mai
silenzio implicito (P5).
Debito #8 si RESTRINGE, non si chiude: il Rulebook non ha un feed.
Confermato due volte lo zero USDC: l'espansione del 31/07 non contiene l'Italia
ne' alcun paese UE, mentre San Marino e Citta' del Vaticano SONO idonei. Non
asserisco una causa (ci sono anche Canada e Giappone).
DUE CORREZIONI dalla KB "Cross collateral specifications":
(a) Il saldo negativo costa una collateral fee dello 0,05% AL GIORNO = 18,25%/anno,
al secondo — 4,3x la resa USDE. Il 30/08 avevo scritto "lo finanzia a
interesse" SENZA il numero: giusto e vuoto. Col numero, il criterio del
cuscino di regolamento diventa aritmetica (-14 punti). E il ribilanciamento
automatico non salva: scatta a $1M assoluti o al 100% della cross equity,
irraggiungibili a $2k. Non veniamo ribilanciati: sanguiniamo la fee.
(b) L'haircut USDe ufficiale e' 5%, noi abbiamo 0.10 registrato come "verificato
sul venue" il 26/08 senza traccia di come. NON riparato (P12/M28): si tiene
0.10 perche' e' il lato conservativo, non e' sul percorso soldi e non morde
fino al 90% di quota. Divergenza dichiarata in config.
Di lato: BUIDL haircut 2% (sarebbe stato il miglior collaterale del listino, se
si potesse comprare), stETH 7,5% (terza ragione indipendente per lasciarlo stare).
Nessuna fonte documenta un tetto sulle QUANTITA': il ~31,2% resta misurato e non
spiegato — e ora si sa che non e' una svista di lettura.
Suite: 800 passati (5 nuovi su venue_news).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
41f83b5dd8 |
BUIDL-01 CHIUSO: non entrabile — e la frase pubblicata da Deribit e' falsa per noi
Esito del test pre-registrato dieci minuti prima (
|
||
|
Adriano Dal Pastro
|
7b8e35633d |
BUIDL-01: criteri pre-registrati PRIMA dell'esecuzione e dell'esito
Test di eligibilita' sul collaterale BlackRock (Treasury USA tokenizzati), taglia 500 BUIDL come il test USDE del 26/08. Nasce dalla domanda su stETH: stETH rende 2,22% (meta' dell'USDE) ed e' ETH, non un dollaro — coprirlo e' CC01, gia' parcheggiato a scala 20k+. I custodi sono istituzionali e comunque nessuna via custodiale restituisce i reward USDC (esclusione italiana per giurisdizione). BUIDL invece e' comprabile, liquido, in cross-collateral, e soprattutto e' un emittente DIVERSO: oggi il conto ha $1.412 di USDC che rendono zero e il rischio emittente concentrato al 100% su Ethena. Criteri dichiarati adesso, esito da leggere il 2026-09-04: ELIGIBILITA': >=1 reward entro le 23:00 UTC del 03/09 -> IDONEO; zero -> NON IDONEO, si riconverte e la pista si chiude. Tre finestre feriali piene. TETTO: sondato a saldo neutro, registrato col suo bracket E l'equity del momento (sull'USDE il tetto e' una frazione, non un livello). HAIRCUT: dichiarato NON misurabile a questa taglia, e non vincolante. Committato PRIMA dell'esecuzione: l'ordine dei fatti sta in git. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
f151316bdf |
usde: il tetto e' una FRAZIONE dell'equity (~31,2%), non un livello — e ora e' in config
Fonte: articolo ufficiale Deribit "Yield/reward bearing coins" (WebFetch lo prende
403, si legge dall'API Help Center in JSON). Tre correzioni alle conclusioni di
ieri.
1) L'ITALIA e' nella lista delle giurisdizioni escluse dai reward USDC. Lo zero
misurato e' confermato dalla fonte, ma la mia ipotesi MiCA era SBAGLIATA: la
lista contiene Canada e Giappone, non e' il perimetro MiCA. E' policy di
giurisdizione Deribit. M27: una fonte normativa si verifica, non si deduce.
2) La finestra di pagamento USDC e' di DUE SETTIMANE ("within the first two
weeks of the following month"), non tre giorni. Avevo verificato su 8/14 e 3/14
giorni. Rifatto sulle finestre vere: LUGLIO conclusivo (atteso $1,72 contro
un'escursione TOTALE dell'equity di $0,48 in 1-16/08, zero scalini compatibili),
GIUGNO no (il libro opera da meta' mese, rumore della taglia del segnale). La
conclusione non cambia, ma l'evidenza e' UNA finestra piu' la lista ufficiale,
non due: il "172x" del 30/08 era sovra-affermato.
3) IL TETTO NON E' UN LIVELLO, E' UNA FRAZIONE. L'articolo documenta un Cap
ETHENA che diluisce il TASSO a livello di exchange e nessun limite sulle
quantita' detenibili: il muro non aveva base documentale e andava ri-sondato.
Fatto il 31/08 (giorno UTC nuovo -> non e' un limite giornaliero): ieri si
tornava a 644,18, oggi no, con l'equity scesa di $8.
30/08 tetto [644,18 · 645,18) equity $2.063,79 = 31,21-31,26%
31/08 tetto [643,18 · 644,18) equity $2.055,56 = 31,29-31,34%
0,05pp di scarto, dentro il rumore dell'equity (+-$2-8/ora). Candidato pulito
5/16 = 31,25%, ma a questa risoluzione non si distingue da una regola sul
collaterale scontato dell'haircut (~29%): si cita la banda (M25).
=> Il tetto SCALA col conto: la quota resta ~31%, il valore in dollari cresce
col capitale, il 70% non e' raggiungibile ne' ora ne' mai. E, essendo pinnati
al tetto, il rischio emittente resta una frazione COSTANTE del conto.
Cablato (rispondeva a "dove e' scritto il valore del tetto": in tre note di
testo e in nessun posto che il codice leggesse, tanto che usde_convert --quota
0.70 dichiarava "piano valido" per un ordine che il venue rifiuta):
- config/live.json usde.venue_cap_frac 0.312 + venue_cap_misurato
- src/live/usde.py lo porta nei default (unica autorita', P1)
- usde_convert.piano() rifiuta il bersaglio sopra il tetto PRIMA di sparare
e stampa il massimo raggiungibile. Verificato su entrambi i rami.
Anche: l'USDe ha un fee Deribit del 5% mai nominato prima. Il nostro misurato
(~4,5%/anno) e' gia' netto: e' l'unico numero da citare.
Stato: USDE 643,175691 (31,29%, al tetto), USDC $1.412,40, totale $2.055,57.
Suite: 795 passati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Adriano Dal Pastro
|
c250c04371 |
usde: l'USDC NON frutta sul nostro conto — misurato, e §6 di stasera era sbagliata
Domanda dell'operatore: "verifica se l'USDC frutta davvero sul nostro conto". Sembrava dover aspettare: il gateway non espone il Transaction Log (get_transaction_log, get_settlement_history, get_deposits, get_transfers, get_interest_history: tutti 404 — debito #11) e l'unica serie storica e' trades.db.equity, oraria ma arrotondata a 2 decimali e sporcata dal P&L non realizzato (+-$2-8/ora a posizioni aperte), dove $0,13/giorno sparisce. La fonte ufficiale Deribit ha spostato il problema dal rumore al calendario: i reward USDC si pagano UNA VOLTA AL MESE ("paid out as a single monthly payment early in the following month"), accrual alle 00:00 UTC sulla minima equity — non ogni giorno come l'USDE. Ecco perche' una sorveglianza giornaliera non poteva vederli. E un accredito mensile da qualche dollaro si vede benissimo anche a 2 decimali, purche' il libro sia FLAT: allora equity == balance == USDC e ogni scalino e' un accredito. MISURA, due confini di mese entrambi a libro flat: 29/06 -> 08/07 equity 598,06 costante, 237/237 ore ferme, 0 scalini (attesi $0,45) 31/07 -> 03/08 equity 596,92 costante per 4 giorni pieni (attesi $1,72) Il secondo e' decisivo: $1,72 contro una risoluzione di $0,01, 172x. Zero MISURATO, non zero sotto soglia. => La premessa originale del gate USDE-01 e' RESTAURATA: il guadagno di tenere USDE e' il tasso pieno ~4,1%, non lo spread 0,71 punti che avevo scritto poche ore fa. Sui $644: ~$26/anno, non ~$4,6. Cosa avevo sbagliato: ho letto `apr: 3.4` in public/get_currencies e l'ho trattato come una proprieta' del NOSTRO CONTO. Era un listino del VENUE. La "conferma indiretta" che invocavo provava che il listino e' reale per l'USDE e non diceva nulla sull'idoneita' dell'USDC. Un tasso pubblicato non e' un tasso incassato: si verifica sul conto — ed e' costato una query su una serie che avevamo gia'. Esclusione plausibile ma NON verificata: MiCA (USDC e' e-money token, USDe no); Deribit dice solo "eligibility is based on their location". Il fatto misurato e' lo zero, non il suo motivo. Nuovo: scripts/live/balance_watch.py + scripts/cron_balance.sh (orario al minuto :42, libero fra :25/:35/:47, sola lettura). Registra il BALANCE a 8 decimali per valuta — la serie che mancava — col conteggio dei fill dall'ultimo campione e il nozionale lordo, cosi' una finestra sporca si riconosce invece di essere mediata dentro. Etichetta PULITA le finestre a 0 fill e libro flat, dove il delta USDC E' l'interesse, e ne stampa l'APR implicita. Suite: 795 passati. L'ERROR di teardown e' il falso positivo dichiarato dalla guardia stessa: il cron :47 ha scritto un fill reale (ETH BUY $+9, 23:47:19) mentre la suite girava. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
a45794d2cb |
usde: il venue mette un TETTO al 31,21% — e l'USDC paga gia' 3,40%
Richiesta dell'operatore: "porta in usde tutto il capitale che non viene usato". Il margine consuma $11 su $2.063 e l'USDE e' cross-collateral: preso alla lettera vale una quota ~99%, cioe' il 100% che il gate esclude. Portata all'operatore con le cifre, ha scelto 70%. Il 70% non e' un argmax (M8): e' il massimo compatibile col CUSCINO DI REGOLAMENTO, il vincolo che r0830_usde_quota non aveva guardato. P&L e funding dei perp USDC-lineari si regolano in USDC, non nel collaterale, quindi la quota non la limita l'haircut ma il saldo USDC che deve reggere il disaster-SL sulla massima esposizione: 2 x 0,5 x 0,30 = 30% dell'equity, che lascia il 70%. ESEGUITO +144 USDE (500,1757 -> 644,175691), quota 24,24% -> 31,21%, fee 0. Poi il muro. (a) TETTO DEL VENUE, misurato e non documentato da nessuna parte. Provato a saldo neutro: BUY 20 rifiutato, SELL 20 OK, BUY 20 OK, BUY 5 rifiutato, con $1.408 disponibili. E' un tetto sul LIVELLO. Il messaggio del venue (not_enough_funds_in_currency) e' fuorviante e ha fatto inseguire tre ipotesi sbagliate: taglia (falso, ma min_trade_amount=1 e' vero), rate-limit (falso), prezzo (vero in parte: il book REST pubblico e' in ritardo sul matching engine e prezzavo l'ordine sull'INDICE invece che sul BOOK — l'indice marca il collaterale, il book prezza lo scambio). La cronaca resta nel diario: chi rilegge non deve rifare il giro. (b) L'USDC PAGA 3,40%. public/get_currencies: USDE 4,1071%, USDC 3,4000%, e i nostri reward USDE misurati (~4,5%/anno) confermano che quelle APR sono reali. Il guadagno non e' il tasso, e' lo SPREAD: 0,71 punti, ~$4,6/anno sui $644 che teniamo, non i $21 che il gate implicava. Il gate ha misurato il reward dell'USDE e non ha mai chiesto cosa facesse l'USDC fermo: manca il controfattuale, M1 in un'altra veste. NON dimostrato che sia accreditato sul nostro conto — da verificare su un giorno senza trade. Nuovo attrezzo scripts/live/usde_convert.py: dry-run di default, banda prezzo, tetto hard di quota, cuscino di regolamento derivato da config. NON passa da execution.ALLOWED, che resta ai soli due perp. config: quota_target 0.70 registrato; quota_max_frac alzato a 0.85 e RIMESSO a 0.50 nella stessa sessione — la soglia larga presupponeva un 70% che non esiste, e lasciarla avrebbe disarmato la guardia per uno scenario che non si e' verificato. Suite: 795 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
3cf884fa39 |
CLAUDE.md: la riga USDE-01 cita il tasso con la sua banda — 3,26% [1,13-4,51], n=4
Citava "3,80% su UNA finestra, 1,90% su DUE": due letture di n=1 e n=2, senza banda, cioe' esattamente cio' che la §2 vieta. A quattro finestre il numero e' 3,26% annuo con banda bootstrap [1,13% - 4,51%], e la larghezza (3,4 punti su un livello di 3,2%) E' il risultato: a n=4 il tasso non e' misurato. Aggiunto il risultato che governa la decisione di domani: l'EV e' lineare in q, quindi non puo' scegliere una quota interna. E i tre numeri che la incorniciano: il margine non e' il vincolo (l'haircut non morde fino al 90% di quota, nemmeno a leva 1,50x con USDE marcato alla soglia critica 0,95 — 29x di cuscino), la resa vale $16/anno cioe' meno di un mese di versamento, e aspettare quattro settimane costa $1,33 per 8x le finestre. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E1gJmWPA4rEhmc6CQQuNZw |
||
|
Adriano Dal Pastro
|
035bd086a2 |
usde: l'EV non puo' scegliere la quota — e aspettare 4 settimane costa $1,33
La decisione di quota e' dovuta lunedi' 31/08. Il risultato strutturale, dichiarato prima di guardare i numeri: l'EV e' LINEARE in q, quindi il suo argmax e' sempre un angolo (0% o 100%) e non puo' produrre una quota interna. Ogni quota intermedia nasce da un criterio sulla CODA, che va dichiarato e non ottimizzato (M8). Lo script quindi non sceglie: mette il prezzo accanto a ogni criterio candidato. Misure: - rendimento 3,26% annuo su n=4 finestre (3 pagate), banda bootstrap 95% [1,13% - 4,51%] su 200.000 ricampionamenti. Larga 3,4 punti su un livello di 3,2%: a n=4 il tasso non e' misurato, e' abbozzato. Il punto stimato si DERIVA da usde_watch.rendimento() invece di essere ridichiarato (P1), e la divergenza fra i due denominatori (0,06 punti) e' stampata, non appianata (P12). - l'hazard annuo di pareggio E' l'APR: la quota e' EV-positiva se e solo se si crede che Ethena stia sotto il 3,3%/anno di evento catastrofico. Numero ASSUNTO, non stimato, come il p di Deribit del 26/07 — il cui framework P=1-(1-p)^20 lo script riproduce prima di usarlo (10/18/33/64% contro 10/18/34/64% registrati). - il haircut 10% NON morde a nessuna quota testata, fino al 90%: il libro gira al 2,00% di margine ($11,37 su $568,64), tre ordini di grandezza sotto il collaterale. Il vincolo non e' il margine (D5: buco quantificato e innocuo). - il churn da depeg critico vale ~$52 di nozionale a quota 50%: secondo ordine. Il numero che decide (N10 — una data si giustifica col COSTO della misura): la conversione e' fee 0 e ~3 bps di spread, quindi la decisione e' reversibile a ~6 bps. Alzare a 50% fra quattro settimane invece che domani costa $1,33 di resa non incassata e porta il campione da 4 a 32 finestre, stringendo la banda da ~3,4 punti a ~1,2. Due letture del rischio che non si annullano (M28): l'USDE fa perdere soldi solo nel mondo in cui Ethena salta E Deribit sopravvive, quindi il rischio aggiunto e' di secondo ordine — ma e' un terzo strato sullo stesso conto, e N4 dice che un rischio di venue si compra con un secondo CONTO. La prima dice che costa poco, la seconda che non e' li' che si compra sicurezza. Verdetto a runtime: risoluzione insufficiente per alzare · nessun vincolo operativo · scala (la resa di oggi vale $16/anno, meno di UN mese di versamento: la leva binding resta il bonifico) · asimmetria (gia' a 24,2% l'evento emittente vale 3,1x il maxDD dell'intero libro) · reversibile e quasi gratis da rimandare. La scelta resta dell'operatore: lo script mette i prezzi, non ne sceglie uno (N4). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E1gJmWPA4rEhmc6CQQuNZw |
||
|
Adriano Dal Pastro
|
fc24ee5f52 |
journal: voce COMPLETA del 29/08 sostituisce la parziale — 24/24 giri
Il cron notturno (00:37Z del 30/08) ha riscritto la pagina come annunciato dalla versione parziale. I numeri di GIORNO passano dalla frazione di 7 giri al giorno intero: equity $2,056.87 (era $2,051.29), P&L giorno +$4.51 (era -$1.07), trading cumulato +$59.42, DD dal picco -0.81%. Implicita ancora sotto la realizzata su entrambe le gambe (BTC 37.4 vs 44.0, ETH 51.1 vs 68.9), DVOL al 19° e 18° percentile dell'anno: VRP01 resta fermo per costruzione, IV-rank 0.07 e 0.12 sotto la soglia 0.30 del gate. Aggiunta la sezione Analisi (agente), assente nella parziale. Salute pulita: 24/24 giri di book_execute, feed SKH a 0 min. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E1gJmWPA4rEhmc6CQQuNZw |
||
|
Adriano Dal Pastro
|
bb33df472f |
journal: voce PARZIALE del 29/08 — implicita al 24° e 17° percentile, VRP01 resta fermo
Scritta a mano alle 06:49Z, quindi marcata PARZIALE: copre 7 giri su 24 e non si aggiorna da sola. Il cron la riscrive completa dopo le 00:30 di domani. Equity $2.051,29, nozionale $555, leva 0.27x. Giornata -$1,07 su 7 letture, 1 fill e 1 round-trip (+$0,02 netto). Cumulato dall'arming +$1.453,23, di cui $1.399,39 versati -> trading +$53,84. Entrambe le gambe a target, SKH01 flat su tutte e due: il rischio resta interamente TP01. Due cose che la Lettura tira fuori: - l'implicita e' crollata in un giorno — DVOL BTC dal 47° al 24° percentile di un anno, ETH dal 45° al 17° — MENTRE la realizzata 30g saliva (44,1% e 68,9%). E' lo spread in cui vivrebbe VRP01, ma il suo gate guarda l'IV-rank espandente (0,09 e 0,12 contro una soglia di 0,30) e tiene lo sleeve fermo: dice di no esattamente dove l'occhio direbbe di si', ed e' per questo che esiste. - prima comparsa della riga [drawdown]: -1,08% dal picco di $2.073,59, con la sua avvertenza attaccata (letture ORARIE, non minimo intra-giorno: e' un pavimento). Campo `nota` lasciato vuoto: e' dell'operatore. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
993d17556a |
usde: gate CHIUSO IDONEO, quota rinviata a lunedi' — l'APR si legge col suo n
Il 2026-08-28 12:35Z `usde_watch` ha rilevato il primo reward (+0.052055 USDE su 500), e la regola pre-registrata il 26/08 PRIMA dell'esito ha chiuso il gate USDE-01 su IDONEO. Si apre la decisione di QUOTA, che e' dell'operatore. DECISIONE DELL'OPERATORE (29/08): la quota si decide lunedi' 31/08, su tre-quattro finestre invece che su una. Il motivo e' un numero: sul solo pagamento il tasso implicito e' 3,80% annuo, su DUE finestre — il 27/08 aveva pagato ZERO — e' 1,90%. Fra i due c'e' tutta la decisione, e il campione e' UN pagamento. `rendimento()`: APR sulle finestre OSSERVATE, col denominatore sul TEMPO VERO e non sul numero di finestre pagate — cosi' una finestra che non paga ABBASSA la stima invece di sparire (P5: quel silenzio e' uno zero). Le letture con trade nel mezzo si escludono, non si riparano in silenzio (P12). L'APR si stampa sempre col suo `n`, e sotto 4 finestre la riga dice «un pagamento non e' un tasso». Sulle letture vere: 1,97% annuo su 1,9 giorni, 1/2 finestre pagate. `quota_da_decidere()`: vera SOLO se IDONEO E il rinvio e' scaduto. Da lunedi' il watch manda il 📌 OGNI giorno — quota attuale, tetto di allerta, APR osservato — finche' non si decide (N9: una decisione rinviata senza promemoria e' rinviata per sempre). Stesso schema della soglia $15k di GTAA01, con la data al posto del capitale. Si smette togliendo `DECISIONE_QUOTA_DAL`. 6 test nuovi, incluso il controllo positivo — «la finestra sola darebbe il doppio» — che e' esattamente la ragione per cui l'APR non si cita senza il suo n. CONFERMATO il fix IB di ieri: il giro delle 00:30 ha 0 righe `orders request timed out` (erano 2 per giro, 63 su 63) e tutti e sei gli ETF scaricati. E una conferma involontaria del debito §5.13: SPY e' passato da 1996-09-04 a 1996-09-05 — la finestra rotolante ha perso un altro giorno in una notte, come misurato. Diario: docs/diary/2026-08-29-usde-idoneo-e-ib.md Suite: 795 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
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
|
32e1649dcb |
test: la suite non parla piu' al canale di allarme vero
Difetto trovato addosso: `uv run pytest` mandava messaggi Telegram VERI sul canale dell'operatore — cinque per giro, col testo delle fixture («Analisi di ieri.», «rete KO», «Testo dell'agente.») sotto l'intestazione di una voce di giornale del 21/08. Colpevoli i cinque test di `analista.CLI.scrivi()`, che non passavano `telegram=False` e percorrevano `invia()` fino a `notifier.send()`. `_cfg()` legge il token da `.env.mainnet`/`.env`: il fatto che non fosse nell'ambiente non proteggeva niente. NON E' COSMETICO. E' P9 al contrario — allarmi finti spesi su un canale che deve restare credibile il giorno che l'allarme e' vero. Chi riceve cinque messaggi identici a ogni giro di test impara a non aprirli, ed e' l'unico canale da cui passano disaster-SL, uscita di fondi e venue giu'. RIPARAZIONE STRUTTURALE, stessa lezione del watermark (§5.12): si blocca la RETE in una fixture autouse, non si chiede a ogni autore di ricordarsi un parametro. Un test che vuole davvero esercitare `send()` continua a funzionare — patcha `urlopen` nel proprio corpo e vince su questo. In piu' una guardia di sessione: bloccare non basta, un tentativo va TROVATO e reso esplicito, o resta li' pronto a tornare vero il giorno che qualcuno cambia il boundary. Validata su controllo positivo (M15): un test che chiama `notifier.send()` fa fallire la sessione. ⚠️ E un difetto fatto e corretto nello stesso giro: la prima versione registrava l'URL, che contiene il BOT TOKEN in chiaro — e quella lista finisce nel messaggio di un assert, cioe' nell'output della suite e nei log. Ora si registra solo "telegram sendMessage": serve sapere CHE si e' tentato, non VERSO DOVE. Il token e' stato esposto una volta nell'output di quella verifica: va ruotato. Suite: 789 passati, 0 falliti. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
418f523be7 |
gtaa: la decisione tenere/bloccare va a $15k — gate (A) ritirato, soglia sorvegliata
Decisione dell'operatore: GTAA01 NON si blocca oggi, si decide quando il book arriva a $15k. Il motivo registrato non e' «non contribuisce» — la misura dice il contrario (+0,095/+0,124 di Sharpe a iso-rischio secondo la fase, positivo in tutte e cinque, hold-out +0,247, 6 anni su 8, correlazione col resto +0,087). Il motivo e' che sotto $15k di book lo sleeve NON E' ACCENDIBILE: GTAA_MIN_CAPITAL e' $3.000 allocati, che al peso 20% fa $15.000 contro i $2.068 attuali. Finora era manutenzione senza beneficio incassabile. Registrate anche le due ragioni contro il blocco, che restano valide: N7 (uno sleeve difensivo si giudica sul sinistro, e questa finestra non lo contiene) e N4 (togliendolo il portafoglio di ricerca diventa 100% cripto su un venue solo). E il costo che sarebbe andato pagato: GTAA01 e' uno dei quattro nomi di W_DEPLOY, da cui escono i $313k del muro. PERCHE' LA DECISIONE NON SI DIMENTICHI (N9). Una decisione parcheggiata su un numero che nessuno sorveglia e' parcheggiata per sempre. `journal.SOGLIE_CAPITALE` legge l'equity ogni giorno — il giornale lo fa comunque — e il giorno che supera la soglia la voce dice quale decisione si sblocca e perche'. Seconda riga: $20k, dove si riapre «100% Deribit fino a $20k». Una riga si TOGLIE quando la decisione e' presa. 5 test, incluso «equity non leggibile non e' una soglia superata» (P5). GATE (A) RITIRATO come pass/fail, congelando il MOTIVO e non l'esito — come il 07/08 col confronto fra ranghi, e per la stessa ragione: il criterio decide su un margine piu' piccolo del rumore che lo scuote. In piu' una guardia sulla CAUSA (`test_la_fase_di_ribilanciamento_e_ancora_ancorata_alla_POSIZIONE`) che si rompe il giorno che qualcuno ancorasse la fase al calendario: quel giorno il gate potrebbe tornare decidibile, ed e' un fatto da guardare, non da ignorare. Il test sul margine assoluto si e' auto-ritirato: diceva «se scendesse sotto un centesimo questo criterio smetterebbe di essere una misura», ed e' sceso a 0,0074. CLAUDE.md: §3 nuova riga · §5.2 RISOLTO (trasporto allarmi) · §5.4 riscritto (la domanda fiscale (a) ha una risposta alla fonte: derivati in c-quater al 26%, non c-sexies al 33% — Circolare AdE 30/E del 27/10/2023, citata verbatim) · §5.13 nuovo debito, la fase che ruota — quantificata e dichiarata INNOCUA oggi (D5): 0,029 di Sharpe a livello di portafoglio, dentro la banda [1,81-2,12]. Diario: docs/diary/2026-08-28-gtaa-fase-e-allarmi.md Suite: 789 passati, 0 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
|
cb40ab3e20 |
journal: recuperata l'analisi del 27/08, saltata dal guasto di autenticazione
Rigenerata con `analista.py --giorno 2026-08-27 --no-telegram`. Le sezioni misurate escono IDENTICHE (ricostruzione deterministica da trades.db e dal feed): cambiano solo l'ora di scrittura in testata e la sezione `Analisi`, che ora c'e'. Controllo sui numeri: ok. `--no-telegram` di proposito: la notifica delle 00:37:02Z era partita e diceva «analisi non disponibile (errore)». Quel record e' la prova che l'allarme del guasto e' uscito, e riscriverlo con un invio di oggi la cancellerebbe. L'analisi legge lo storico com'e' OGGI, non com'era stanotte: la testata porta l'ora vera di scrittura (08:29:00Z), quindi la pagina non si spaccia per una scritta a ridosso del giorno chiuso. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
05a698a83e |
analista: il motivo di un guasto si prende da stdout E da stderr, o si perde
Il 2026-08-28 alle 00:37:00Z la CLI `claude` e' uscita 1 scrivendo «Failed to authenticate: OAuth session expired and could not be refreshed» su STDOUT, con stderr VUOTO. `interroga()` componeva il motivo dal solo stderr, quindi nel DB e' finito `analisi_stato='errore'`, `analisi_motivi='uscita 1: '` — e su Telegram e' partito «analisi non disponibile (errore): uscita 1:». La meccanica ha retto (nessuna analisi di ieri spacciata per quella di oggi, esito registrato, notifica partita): a mancare era solo il PERCHE'. P4 — un'allerta risponde a due domande, e con la prima sola la causa si ricostruisce aprendo a mano il transcript della sessione headless. P3 — quando la diagnosi serve, il guasto e' gia' rientrato: il motivo si cattura li' o mai. - `motivo_uscita(returncode, stdout, stderr)`: unisce i due canali (stderr per primo), tronca a 300 caratteri. - Silenzio totale su entrambi i canali -> lo DICE, invece di lasciare i due punti a vuoto: «la CLI non ha detto perche'» e «il perche' l'abbiamo perso noi» sono guasti diversi e finora si scrivevano uguali. - 4 test nuovi, fra cui la regressione col messaggio testuale del 28/08. NON risolve la causa a monte: perche' quella refresh sia fallita non sta in nessun log locale. Il refresh token era valido (rinnovo automatico riuscito alle 08:03:35Z dello stesso giorno, scadenza 2026-09-25) e la stessa chiamata rifatta a mano esce 0 -> guasto transitorio, unico su 24 sessioni locali. Da qui in avanti, se ricapita, il motivo si legge dalla notifica. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Adriano Dal Pastro
|
a6b5756cc0 |
journal: voci automatiche del 26-27/08 — rischio tutto su TP01, SKH01 flat
Due voci scritte dal cron delle 00:37Z (27/08 e 28/08). Numeri come registrati, nessuna riscrittura a mano. - 26/08: equity $2.065,45, giorno $+8,86, 4 fill / 2 round-trip, 24/24 giri. L'analisi dell'agente segnala il denominatore cambiato il 25/08 (conversione USDE): stessa esposizione ($582 lordi), leva 0,28x non confrontabile coi giorni precedenti. - 27/08: equity $2.070,23, giorno $+4,78, 1 fill / 1 round-trip, 24/24 giri. Manca la sezione "Analisi (agente)" — il passo dell'analista nel cron e' a `|| true`, quindi un suo fallimento non lascia traccia nella voce. Cumulato dall'arming $+1.472,17 di equity, di cui $+1.399,39 versati: trading **$+72,78** su 65 giorni e 23 round-trip — taglia a cui il P&L non distingue l'edge dalla fortuna, e con l'82% del cumulato negli ultimi 7 giorni (la settimana in cui BTC ha fatto +9,94% e il libro era lungo su entrambe le gambe). SKH01 flat su BTC e ETH in entrambe le voci: l'esposizione e' interamente TP01. 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
|
631e854b29 |
live: l'equity del book e' il TOTALE cross-collateral — USDE valutato all'indice pubblico
Trovato eseguendo il test di eligibilita' USDE ($500 convertiti alle 13:04Z, fill 1.0003 fee 0): shadow._equity leggeva solo il conto USDC -> il giro successivo avrebbe visto -24,3%, mandato un falso "USCITA DI FONDI" e venduto ~$140 di posizioni. Riparato prima del giro delle 13:47: _collaterale_usde() valuta l'USDE all'indice pubblico usde_usdc (mediana multi-exchange, lezione Binance 10/10/2025), depeg passa nel sizing, clamp a 1.0 sopra la pari, fallback 1.0 dichiarato (mai 0: il fallback si sceglie sul danno, P5). 6 test nuovi in tests/test_shadow_usde.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
|
c4c82a8fbd |
diario: USDC rewards — verdetto: Italia esclusa per MiCA, pista chiusa + episodio scam in chat
Coinbase (chi paga i reward del programma Deribit) ha cessato i reward USDC
nell'EEA dal 2024-12-01 per il divieto MiCA di remunerare gli EMT; l'espansione
Deribit del 2026-08-01 aggiunge 80 paesi, nessuno EEA. Nessun ticket necessario.
Registrato l'episodio dei finti agenti in chat ("Yes, Italy is supported" =
falso) con la regola permanente sul canale di supporto.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1
|
||
|
Adriano Dal Pastro
|
e7a5fee2fd |
diario: USDC Rewards Deribit — prodotto verificato sul venue (apr 3.4), il conto NON li riceve
Verifica empirica sulla serie equity oraria: nelle finestre di pagamento (1-14 lug, 1-14 ago) il libro era flat e nessun accredito da ~$0,65-2,00 compare (0-1 salti >=$0,40, tutti spiegati dai fill). Resta il ticket al supporto sull'idoneita' dell'Italia. Vale ~$170/anno a $5k. 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
|
a51844875b |
journal: i versamenti non sono piu' P&L — movimenti di capitale scorporati dal trading
Il P&L di giornale era un delta di equity: la voce del 25/08 dichiarava +$1.414,57 di "giorno" quando $1.399,39 erano il deposito USDC, e il cumulato dall'arming avrebbe mentito per sempre. Nuova `movimenti_capitale()`: - soglia IMPORTATA da book.EQUITY_JUMP_ALERT, non ridichiarata (P1); - "movimento" solo se il salto supera di >2x il massimo che il mercato MISURATO (feed certificato, tetto di leva da config) poteva produrre fra le due letture; - altrimenti AMBIGUO: dichiarato con attenzione e NON scorporato (P12 -- un crash vero a tutta leva non deve diventare "prelievo"); idem a feed illeggibile (P5). Scansione dell'intera storia: 1 evento, esattamente il deposito (+209,6% contro mercato max 0,22%), zero falsi positivi. `concentrazione` ora lavora sul cumulato di TRADING; le regole sui movimenti stanno sopra l'early-return "nessun giro". Limite dichiarato (D5): un movimento sotto il 10% dell'equity resta nel P&L. 7 prove nuove (31 -> 37), incluso il controllo M15 al contrario. Voce del 25/08 rigenerata: giorno -> trading +$15,18; cumulato -> trading +$59,14. 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
|
4f91b25b72 |
journal: voce automatica completa del 25/08 (riscritta dal cron delle 00:37Z)
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
|
14e1567125 |
docs: il cap per-asset non ha tetto assoluto — CLAUDE.md dichiarava la formula del fallback
CLAUDE.md 1 descriveva il guardrail live come `min($3.000, equity_osservata x 0.5)`.
Il codice dice altro (src/live/book._cap):
if trusted: # equity reale leggibile
return float(equity) * float(frac) # <-- nessun min() con `fixed`
return min(fixed, wm * float(frac)) ... # <-- il $3.000 vive SOLO qui
Cioe' `max_notional_per_asset_usd` NON morde mai sul percorso normale: e' il tetto del
ramo di FALLBACK (equity illeggibile), e la riga lo spacciava per quello vivo. Stessa
classe del difetto 5.7 — una descrizione puntata su una configurazione diversa da quella
che gira.
Conseguenza da sapere, emersa da "cosa succede se arrivo a 3.000 USDC": nessun livello
di capitale cambia il profilo di rischio RELATIVO. Il book scala indefinitamente a leva
lorda massima 1,0x (0,40x al segnale corrente), e $3.000 non e' una soglia — il numero
compare in tre posti del progetto e nessuno scatta li':
- max_notional_per_asset_usd: cap sul nozionale, non soglia di equity, non morde;
- "la soglia $3k" di 3: decisione CHIUSA il 26/07, si riapre a $20k;
- C* ~$3.000 del monitor XSR01: difetto noto (5.3), il pavimento vero e' $15-20k.
CODICE NON TOCCATO: il comportamento e' intenzionale e documentato nel docstring di
_cap (la "frontiera" del 03/07 esiste apposta perche' un deposito non resti strozzato).
Era sbagliata la descrizione, non la scelta. Verificato anche che il tetto sul PRODOTTO
del GATE SCALA-01 (n_asset x frac x scala x disaster_sl_pct = 0,30 <= 0,50) non dipende
dall'equity, quindi regge identico a ogni capitale.
Contesto: versamento di 1.400 USDC atterrato alle 11:03:35Z, equity $667,88 -> $2.066,96.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B9UyJLHzR7EJzxR3iQ3RN1
|