# 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ì.