Files
PythagorasGoal/docs/diary/2026-07-27-lumpsum-venue-gates.md
T
Adriano Dal Pastro fd05307c96 research(capitale): il lump-sum vale 2.45x, e la protezione dalla rovina non passa da GTAA01
Quattro filoni chiesti dall'operatore ("proposte"). Book, pesi, config: INVARIATI.

1. LUMP-SUM + VENUE (r0727_lumpsum_split.py). Tutte le traiettorie del 25-26/07 avevano
   START=600 cablato: mai misurato un versamento iniziale, mentre ~10k EUR stanno fermi
   altrove. Macchineria validata: con lump 0 riproduce IDENTICI i numeri del 26/07.
   - 10k EUR oggi e mai piu' nulla -> traguardo 17.2a, P 62%, rendita 61.58 EUR/g
   - equivalenza onesta: +154 EUR/mese per 13 anni = 24.523 EUR, cioe' 2.45x
     (la prima stesura misurava i versamenti risparmiati: numero giusto, domanda sbagliata)
   - col rischio venue: a 11.500$ lo split e' possibile (quota IB 26%, non 25%) e taglia
     P(perso tutto) da 18.4% a 3.5% a p=1%, costando 1.9-2.6pp di P(arrivare)
   - SPLIT-CASSA: seconda gamba ferma costa altri 0.6-0.8pp e protegge IDENTICO
     -> la protezione non e' bloccata dal PRIIPs: serve un CONTO, non uno sleeve

2. FEE WATCH (scripts/live/fee_watch.py). Nuovo schema Deribit dal 1 agosto senza numeri
   pubblicati -> sorvegliante invece di promemoria. Legge il tier base dall'endpoint
   pubblico (oggi taker 5.00 bps), applica la regola congelata e allerta sui cambiamenti.

3. MONITOR HEALTH (src/live/monitor_health.py). Tre gate pre-registrati si decidono su
   serie forward di cui una sola era sorvegliata. Misura coda E buchi interni: una serie
   bucata ma fresca passa qualunque guardia di freschezza.

4. BANDA GTAA01 25% VALIDATA (r0727_gtaa_band_gate.py). 30 celle, 29.9 anni, dpy=252.
   Non e' selection-on-holdout (4/30 IS, 5/30 OOS), DSR 0.999, tracking OK ma AL BORDO.
   Il modo di fallire non e' il de-levering (la vol non scende) ma la perdita di tracking.
   Impatto sul book: zero -> REBAL_BAND_USD non toccato, si applica al deploy.

Aggiunto anche il bullet edge_watch, cablato il 26/07 e mai finito in CLAUDE.md.

Test: 56 nuovi, 504/504 verdi.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-27 14:14:39 +00:00

278 lines
15 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.