PythagorasGoal/docs/diary/2026-07-27-lumpsum-venue-gates.md

2026-07-27 — Il capitale già fermo, due sorveglianze mancanti, e la banda GTAA validata

Richiesta dell'operatore: "proposte". Delle cinque proposte messe sul tavolo ne sono state scelte quattro; questo diario le chiude tutte. Book, pesi, cron-strategia, config: INVARIATI. Il cron guadagna due sorveglianze (non toccano l'esecuzione).

Script: r0727_lumpsum_split.py, r0727_gtaa_band_gate.py, scripts/live/fee_watch.py, scripts/live/monitor_health.py + src/live/monitor_health.py. Test: test_lumpsum_split.py (14), test_gtaa_band_gate.py (13), test_fee_watch.py (13), test_monitor_health.py (16) = 56 nuovi.

---

1. Il capitale già fermo — la leva mai misurata

Il buco

Tutte le traiettorie pubblicate il 25 e 26/07 hanno START = 600.0 cablato. Il progetto ha misurato con grande cura il calendario dei versamenti (fattore 6 fra front e back loading) e non ha mai misurato un versamento iniziale — mentre sul conto Revolut ci sono ~€10.000, di cui €6.043 in XEON che rende ~0% reale netto. Il conto che gira ne ha 600.

Validazione prima dei numeri

La macchineria è una generalizzazione di r0726_venue_risk.simulate (capitale iniziale e deposito diventano parametri, tutto il resto identico incluso l'ordine di consumo dell'RNG). Con lump=0 e €250/mese deve riprodurre esattamente i numeri del 26/07:

p=0.0%  P(arrivare) 0.9487 vs 0.9487 · P(perso tutto) 0.0000 vs 0.0000  -> IDENTICO
p=1.0%  P(arrivare) 0.8080 vs 0.8080 · P(perso tutto) 0.1842 vs 0.1842  -> IDENTICO

Cosa compra un versamento iniziale (p=0, 100% Deribit, 20 anni)

lump	dep/mese	totale versato	anni al muro	P(entro 20a)	cap. mediano	rendita a 20a
€0	€0	$600	mai	0.0%	$16.354	€3.21/g
€2.000	€0	$2.780	19.0a	2.5%	$75.773	€14.89/g
€5.000	€0	$6.050	18.5a	22.9%	$164.901	€32.39/g
€10.000	€0	$11.500	17.2a	61.7%	$313.448	€61.58/g
€0	€250	$66.818	15.7a	94.9%	$544.645	€106.99/g
€2.000	€250	$68.998	15.1a	96.8%	$605.454	€118.94/g
€5.000	€250	$72.268	14.4a	98.2%	$695.475	€136.62/g
€10.000	€250	$77.718	13.3a	99.5%	$844.022	€165.80/g

La riga che sorprende è la quarta: €10.000 fermi oggi, senza versare mai più nulla, portano al capitale-rendita in 17.2 anni mediani con P=62%. Il piano da €250/mese senza lump ci arriva in 15.7 anni con P=95%: più affidabile, ma costa $66.818 di versamenti contro $10.900 una volta sola.

L'equivalenza — e la metrica che sbagliavo

Prima stesura: "€10.000 subito risparmiano 30 mesi = €7.414 di versamenti futuri, cioè 0.7x". Numero giusto, domanda sbagliata, e la conclusione che invita è l'opposto di quella corretta: il valore di un lump-sum non è versare meno, è arrivare prima. La formulazione onesta è a quale versamento mensile permanente equivale:

lump	traguardo	equivale a versare	cioè
€2.000	15.1a (da 15.7a)	€281/mese	+€31/mese per 15 anni (€5.666)
€5.000	14.4a	€327/mese	+€77/mese per 14 anni (€13.241)
€10.000	13.3a	€404/mese	+€154/mese per 13 anni (€24.523)

€10.000 oggi valgono €24.500 di versamenti futuri: 2.45×. È lo stesso meccanismo del front-loading misurato il 26/07, portato al suo estremo.

E il rischio di venue, che è la metà scomoda della domanda

Il 26/07 aveva già osservato che il front-loading mette più capitale sull'exchange prima. Un lump-sum è il front-loading estremo, quindi va misurato col rischio dentro. A €10.000 il conto sarebbe $11.500 e lo split diventa possibile — a quota IB 26%, non il 25% preferito: sotto $3.000 sulla gamba equity non c'è uno sleeve, c'è cash su un secondo conto.

p annua	P(arrivare) CONC	SPLIT	SPLIT+costi	P(perso tutto) CONC	SPLIT
0.0%	99.5%	98.2%	98.0%	0.0%	0.0%
0.5%	93.2%	91.4%	91.2%	9.7%	0.9%
1.0%	87.1%	85.2%	85.0%	18.4%	3.5%
2.0%	76.2%	73.2%	73.1%	33.7%	11.2%
5.0%	50.5%	47.9%	47.8%	64.1%	40.7%

Lo split costa 1.9-2.6pp di P(arrivare) e taglia P(perso tutto) da 18.4% a 3.5% (a p=1%). La colonna "SPLIT+costi" applica alla gamba IB il haircut dichiarato (0.8pp/anno di costi a taglia piccola + 0.1pp di drag UCITS): cambia lo 0.1-0.2pp, cioè niente. Il costo della gamba equity non è ciò che decide.

⚠️ P(perso tutto) sotto CONC non dipende dal lump (9.7/18.4/33.7/64.1% a qualunque taglia): con un conto solo "almeno un fallimento" coincide con "perso tutto", e quella probabilità è una proprietà del tempo di esposizione. Il lump non la peggiora — moltiplica ciò che porta via.

La sezione che serviva davvero: e se la seconda gamba fosse solo liquidità?

GTAA01 oggi non è deployabile (blocco PRIIPs; la via UCITS su Degiro è verificata ma in preparazione). Quindi lo split disponibile subito è Deribit + un conto fermo.

p annua	P(arrivare) CONC	SPLIT-GTAA	SPLIT-CASSA	P(perso tutto) CONC	SPLIT
0.5%	93.2%	91.4%	90.7%	9.7%	0.9%
1.0%	87.1%	85.2%	84.5%	18.4%	3.5%
2.0%	76.2%	73.2%	72.6%	33.7%	11.2%

Tenere ferma la seconda gamba invece di investirla costa 0.6-0.8pp di P(arrivare) e non toglie NULLA alla protezione — che è identica, perché dipende da quanti conti falliscono, non da cosa ci sta sopra. La protezione dalla rovina non è bloccata dal PRIIPs, non aspetta la validazione della banda, non richiede che GTAA01 esista: richiede un secondo conto.

Soglie

• split a quota raccomandata (25%): da $12.000
• split forzando la quota fino al 35%: da $8.571
• con un lump da €10.000 il conto sarebbe $11.500 → possibile, ma a quota 26%.

La riapertura della decisione di venue è fissata a $20.000. Un lump da €10k porta il conto sotto quella soglia ma sopra la fattibilità tecnica — ed è un cambiamento del piano, il caso in cui CLAUDE.md dice esplicitamente di riaprire prima. Questa tabella è il materiale per farlo; la decisione resta dell'operatore, come il 26/07.

⚠️ Cosa questo filone NON decide: quanto dei €6.043 in XEON sia un vero fondo d'emergenza. Un fondo d'emergenza non è capitale disponibile, e la tabella qui sopra misura cosa compra ogni euro che entra, non quali euro debbano entrare.

---

2. Fee Deribit — un sorvegliante invece di un promemoria

Il nuovo schema entra in vigore il 1° agosto e l'annuncio non contiene numeri. La regola era già decisa in anticipo (≤5bps/lato → nulla; >10bps → rivedere il peso di SKH01, 4× più fee-sensibile di TP01). Mancava solo il modo di accorgersene.

public/get_instrument espone il tier base — che è quello che paga un conto da $600, dove ogni soglia VIP è fuori portata — senza chiavi:

strumento            taker     maker   liquidaz.
BTC-PERPETUAL         5.00      0.00      75.00
ETH-PERPETUAL         5.00      0.00      90.00
verdetto: [OK] taker 5.0bps <= 5: non si tocca nulla

scripts/live/fee_watch.py (in cron_daily.sh) confronta con l'ultima lettura, allerta su qualsiasi cambiamento — taker, maker e liquidation fee, che l'annuncio tocca tutti e tre — e applica la regola congelata. Cross-check best-effort sulla fee realmente pagata dai trade del conto, con {} che significa non misurata e non zero.

test_baseline_e_quella_dei_backtest lega BASELINE_TAKER_BPS al default fee_rt=0.001 di backtest_signals: se un giorno le due divergessero, il confronto smetterebbe di avere senso.

---

3. I forward-monitor non erano sorvegliati

Tre gate pre-registrati — STATARB 27/09, XSR01 23/10, DVOLSPREAD kill 24/10 — si decideranno leggendo serie forward. Di quelle serie una sola aveva una guardia d'integrità (paper_dvolspread, contabilità a 3 stati + veto sotto l'80%). Le altre nessuna: paper_xsr, paper_statarb, paper_prevday, paper_portfolio, paper_combo → 0 controlli.

Un monitor fermo produce silenzio, e il silenzio in una serie di ritorni si legge come zero, cioè come una misura. È lo stesso schema già pagato con fresh_5m (26/07) e col feed-freeze del 14/07.

src/live/monitor_health.py misura due guasti diversi, perché una sola misura non basta:

• coda — l'ultima barra è vecchia (il monitor si è fermato adesso);
• buchi interni — la serie è più corta del proprio arco temporale. Una guardia di sola freschezza lascerebbe passare un monitor che ha perso il 30% delle barre di mezzo e ha scritto stanotte — ed è esattamente il guasto che falsifica un gate senza farsi notare.

Cadenze dichiarate per monitor, perché sbagliarle significa un falso allarme a settimana: paper_prevday registra a barra oraria (864 barre in 36 giorni); paper_combo vive sul calendario di borsa (venerdì è l'ultima barra fino a lunedì). Soglia di copertura 0.80, riusata di proposito dal veto DVOLSPREAD: una soglia diversa per monitor renderebbe i gate non confrontabili.

Stati: OK / FERMO / BUCATO / ASSENTE / NUOVO — quest'ultimo per i monitor troppo giovani per un giudizio (XSR01 e DVOLSPREAD hanno 2 barre): non allerta, ma non risulta sano.

Stato al 27/07: 6/6 monitor giudicati, tutti OK; paper_combo al 96% per il 3 luglio — festività di borsa che np.busday_count non conosce. È un limite dichiarato e conservativo (segnala di più, non di meno).

I test includono i controlli positivi obbligatori (un rilevatore che non ha mai segnalato nulla è indistinguibile da uno rotto): monitor fermo → FERMO, serie bucata e fresca → BUCATO, stato assente → ASSENTE.

---

4. La banda GTAA01 al 25% — validata

La proposta del 27/07 (banda = 25% della gamba invece di $50 assoluti) era dichiarata esplicitamente non validata. Griglia 30 celle (5 cadenze × 6 bande) su 29.9 anni di path di produzione, annualizzazione √252 (una serie su giorni di borsa passata a 365 esce con lo Sharpe ×1.20: l'errore del 25/07).

(A) Selezione in-sample (cella scelta sui soli dati pre-2015, letta sul 2015+, l'hold-out equity documentato di GTAA01):

cella scelta al buio : cadenza 1, banda 25% -> IS 0.66 · OOS 0.90 · FULL 0.74
cella proposta 27/07 : cadenza 5, banda 25% -> IS 0.62 · OOS 0.86 · FULL 0.70
rango della proposta : 4/30 in-sample · 5/30 sull'hold-out

Il rango non migliora passando all'hold-out → non è selezione-sull'hold-out (la firma sarebbe il contrario). La cella scelta al buio preferisce il controllo giornaliero, che vale +0.04 di Sharpe e costa 42 ordini/anno con 250 controlli manuali: il conto d'esecuzione non ha API (misurato il 27/07), quindi non è una configurazione, è un'ipotesi. La cadenza settimanale costa −0.04 e compra l'eseguibilità a mano.

(B) Deflated Sharpe sulle 30 celle, dpy=252: 0.999 PASS (massimo atteso sotto il nullo 0.14), sia per la proposta sia per la cella scelta al buio.

(C) Null de-levering — e qui il modo di fallire non è quello atteso:

banda	corr col riferimento	vol/rif	Sh FULL
0%	0.983	1.03	0.59	OK
10%	0.980	1.02	0.64	OK
25%	0.951	0.99	0.70	OK (al bordo)
40%	0.907	1.04	0.67	fuori traccia
60%	0.859	1.10	0.59	fuori traccia

Allargando la banda la volatilità non scende: il null de-levering classico non morde. Ciò che si rompe è il tracking — lo sleeve tiene posizioni vecchie e smette di somigliare a sé stesso. E i due segnali concordano: oltre il 25% la correlazione cala e lo Sharpe smette di migliorare, quindi non esiste una zona in cui il numero premia il congelamento. ⚠️ Ma il 25% è al bordo (corr 0.951 contro una soglia di 0.95), non al centro di un plateau: va citato così.

Invarianza al capitale — la ragione per cui la proposta esiste:

capitale	banda 25%	ord/anno	Sharpe		banda $50 fissa	ord/anno	Sharpe
$3.000	$125	25	0.66		$50	65	0.52
$10.000	$417	25	0.70		$50	92	0.62
$50.000	$2.083	25	0.71		$50	134	0.66

⚠️ 25 ordini/anno, non i 21 citati il 27/07: stimatore diverso (qui il gate contato sulla griglia dei controlli, 30 anni, veicoli USA; lì i cambi di posizione sulla finestra UCITS di 3.2 anni). L'invarianza — che è la proprietà sotto esame — regge in entrambi.

Impatto sul book: Sharpe FULL 2.221 → 2.221, maxDD 6.08% → 5.94%. Zero. Il book modella GTAA01 a $10.000, dove la banda fissa già funziona: il valore della proposta è tutto al capitale piccolo (0.52 → 0.66 a $3k), cioè al deploy.

Verdetto: la proposta passa i tre gate. Produzione NON toccata: cambiare REBAL_BAND_USD non sposta un solo numero pubblicato, e lo sleeve non è deployabile prima dei $20k. Il cambio si applica al deploy, insieme alla scelta del broker, con questo diario come giustificazione.

---

5. Il debito chiuso di straforo

edge_watch.py — i criteri di kill del book live — è in cron dal 26/07 e non era in CLAUDE.md (zero occorrenze). Il criterio di morte di ciò che gira con soldi veri non stava nella memoria operativa del progetto: la sessione successiva avrebbe ragionato come se non esistesse. Aggiunto.

---

6. Regole

1. Un parametro d'esecuzione scelto guardando il risultato è selezione come ogni altra, e va passato per gli stessi gate — anche quando "è solo esecuzione" e non tocca l'allocazione.
2. Quando si misura l'effetto di un vincolo, si misura anche il vincolo del vincolo. Lo split di venue a $11.500 non è "25% su IB": è 26%, perché sotto $3.000 la gamba equity non esiste. È il capitale a scegliere la quota, non la preferenza.
3. Il valore di un versamento iniziale non si misura in versamenti risparmiati (domanda sbagliata, rapporto 0.7×) ma in versamento mensile equivalente (2.45×). La prima formulazione invita alla conclusione opposta.
4. Una guardia di freschezza non è una guardia d'integrità. Il guasto che conta — la serie bucata e fresca — passa la prima e fallisce la seconda.
5. Il verdetto pre-scritto va confrontato coi numeri prima di stamparlo. Il testo di (C) diceva "il numero migliora perché esce dal mercato": la vol misurata non scendeva, quindi era falso. Il fallimento vero era un altro (tracking), e dirlo giusto vale più che avere ragione.
6. Un rischio non-diversificabile si compra con un secondo conto, non con un secondo sleeve. La protezione dalla rovina è identica con GTAA01 o con liquidità: dipende da quanti conti falliscono, non da cosa ci sta sopra.

---

7. Addendum — "€5k messi dove" (stessa sessione)

Domanda diretta dell'operatore dopo il riassunto. Ha richiesto una misura nuova, perché €5.000 cade in una zona che la tabella §1 non copriva: a $6.050 lo split con GTAA01 è impossibile (servirebbe il 50% del conto per fare i $3.000 di gamba minima), ma lo split in liquidità non ha soglie di eseguibilità.

Due correzioni al volo prima dei numeri:

1. La configurazione vera non è quella che avevo tabulato. config/live.json è stato alzato il 26/07 "in previsione del versamento (EUR 5.000 + 500/mese → equity ~$6.050)": il piano dell'operatore è €500/mese, non i €250 di tutte le tabelle. Rimisurato su quella. Conseguenza operativa: nessuna azione di config al deposito — il cap è già min($3.000, equity_osservata × 0.5), quindi a $6.050 vale $3.000/asset = leva lorda ≤1x, ed è protetto dal watermark contro il caso "cap alto su conto piccolo".
2. Niente si sblocca a $6.050. GTAA01 richiede $3.000 sulla gamba (50% del conto) e non è comunque deployabile (PRIIPs); XS01 ~$20.000; XSR01 è sotto gate fino al 23/10. Il book resta TP01+SKH01 → l'unica domanda è quanta parte non sta sull'exchange.

Seconda gamba = liquidità ferma, due letture del suo rischio ([A] rischiosa come Deribit, conservativa; [B] conto bancario con tutela dei depositi, realistica):

fuori exchange	P(arrivare)	anni	P(perso tutto) [A]	[B]	salvato se cade
0%	89.4%	11.4a	18.4%	18.4%	$0
10%	89.0%	11.8a	3.5%	0.0%	$6.818
25%	88.5%	12.4a	3.5%	0.0%	$17.045
40%	87.8%	13.3a	3.5%	0.0%	$27.272

(p exchange = 1%; €5.000 + €500/mese, 20 anni)

⚠️ Due letture che il tavolo nasconde, e senza le quali si sceglie male.

(a) P(perso tutto) SATURA a qualunque quota > 0 (3.5% al 10, 25 e 40%): la protezione binaria si compra col semplice fatto di avere un secondo conto, non con quanto ci si mette. Ciò che distingue le quote è la colonna del salvataggio.

(b) ⚠️ Errore mio, corretto in sessione. La prima versione di quella colonna riportava il capitale a 20 anni condizionato al fallimento, e dava $77k al 10% — undici volte il valore vero. Artefatto della convenzione ereditata dal 26/07: alla morte di un venue i versamenti successivi vengono dirottati ai superstiti, e scartati se non ne resta nessuno. Quel numero attribuiva quindi allo split il valore di continuare a versare, che si ottiene comunque aprendo un altro conto dopo il guasto. La misura onesta è il salvataggio istantaneo: quanto resta nel momento in cui l'exchange cade. Congelato in test_il_salvataggio_e_istantaneo_non_a_scadenza.

Il prezzo, in chiaro: tenere fuori il 25% costa 0.9pp di probabilità di arrivare e circa un anno di ritardo mediano (11.4 → 12.4), e compra ~$17k mediani nel 18% di percorsi in cui l'exchange sparisce (a p=1%), più P(perso tutto) → 0 nella lettura realistica.

E la parte che non costa nulla: quei soldi sono già fuori dall'exchange, in XEON. Lo split non si costruisce spostando denaro su un secondo venue — si ottiene versandone di meno. Con €6.043 in XEON, deporne €5.000 lascia fuori ~16% del capitale investito: già dentro la banda 10-25%, a costo operativo zero.

REGOLA: quando una metrica binaria satura, la decisione va spostata sulla metrica continua — qui P(perso tutto) non distingue il 10% dal 40%, il salvataggio sì.