PythagorasGoal/docs/diary/2026-07-26-versamenti.md

# 2026-07-26 — I versamenti: le quattro ipotesi che il piano non aveva mai fatto

**Richiesta:** *"allora concentriamoci sui versamenti"* — dopo la rivalutazione che ha misurato il
book dentro il suo plateau (ottimizzare il peso = +0.030 Sharpe, gate fallito) mentre i versamenti
valgono la differenza fra **mai** e **16 anni**.

**Script:** `r0726_deposits.py`. **Test:** `tests/test_deposits.py` (12).
**Book, pesi, cron, config: INVARIATI.** (Questo filone non tocca il codice di produzione.)

---

## 0. Cosa mancava

Tutte le traiettorie calcolate finora (25/07 e 26/07) assumono la stessa cosa: **versamento
piatto, ininterrotto, per sempre**. E' l'ipotesi meno realistica dell'intero piano. Qui si misurano
le deviazioni che succedono davvero, con la stessa macchineria (block bootstrap sui ritorni reali
del book live, fattore d'ancora ×0.89 **misurato**).

## 1. Smettere di versare — il costo non e' proporzionale ai soldi mancanti

€250/mese per K anni, poi stop, orizzonte 20 anni:

```
 versi per  totale versato   cap. mediano a 20a  P(muro entro 20a)  rendita mediana
       3a          $10,410             $202,771             32.7%       37.27 €/g
       5a          $16,950             $287,081             53.3%       52.76 €/g
      10a          $33,572             $410,220             77.9%       75.39 €/g
      20a          $66,818             $496,778             90.0%       91.30 €/g
```

**I primi 5 anni sono il 25% dei soldi e il 58% del risultato.** Chi versa 5 anni e poi smette
arriva comunque alla rendita bersaglio nel 53% dei casi; chi versa gli ultimi 10 anni (piu' soldi)
arriva nell'11% (§3). **La variabile non e' quanto versi: e' quanto presto.**

Corollario pratico: un'interruzione al 12° anno costa poco; una al 3° costa quasi tutto. Se il
piano deve rompersi, e' meglio che si rompa tardi — il che e' un argomento per **partire con un
importo sostenibile** invece che con uno ambizioso.

## 2. Un piano crescente e' peggiore di uno piatto, a pari soldi

```
piano             totale versato   cap. mediano   P(muro)   $ finale / $ versato
piatto €250              $66,818       $496,778     90.0%                  7.43x
€150 +5%/anno            $67,998       $401,889     80.8%                  5.91x
```

**Stessi soldi (€67-68k), 24% di risultato in meno.** Il piano crescente versa gli stessi euro
piu' **tardi**, e quegli euro compongono meno. L'ultima colonna e' la metrica giusta per
confrontare piani di taglia diversa: quanto capitale finale compra ogni dollaro versato — e i
piani crescenti stanno tutti a 5.1-5.9x contro 7.4x dei piatti.

E' contro-intuitivo perche' "i versamenti crescono col reddito" suona prudente. Lo e' dal punto di
vista del bilancio familiare; **non** lo e' dal punto di vista del capitale.

## 3. Stesso totale, calendario diverso — il tempo vale 2.2x

€60.000 in totale (= €250/mese per 20 anni), distribuiti diversamente:

```
calendario                   cap. mediano   P(muro)   vs piatto
piatto su 20 anni                $496,778     90.0%       1.00x
tutto nei primi 10 anni          $806,285     98.3%       1.62x
tutto nei primi 5 anni         $1,104,587     99.4%       2.22x
solo negli ultimi 10 anni        $178,494     11.0%       0.36x
```

**Gli stessi €60.000 valgono da $178k a $1.104k — un fattore 6 — a seconda di QUANDO entrano.**

⚠️ Questo **non** dice "versa tutto subito": dice quanto vale il tempo. Un piano che non si
sostiene non e' un piano, e il confronto serve a scegliere fra calendari **sostenibili**.

### E regge al rischio di venue?

Il vantaggio del front-loading e' calcolato mettendo **piu' capitale sull'exchange prima** — cioe'
proprio il rischio misurato stamattina. Andava verificato, non assunto:

```
calendario                     p=0.5%          p=2.0%          p=5.0%
piatto su 20 anni            $463,413        $359,251              $0
tutto nei primi 10 anni      $765,178        $555,904              $0
tutto nei primi 5 anni     $1,015,491        $752,367              $0
solo negli ultimi 10 anni    $172,228        $147,203              $0
```

Il vantaggio **regge** (2.22x → 2.09x a p=2%): il rischio di venue colpisce il **tempo**, non il
calendario dei versamenti. Anticipare non aumenta la probabilita' di essere colpiti, aumenta solo
quanto c'e' dentro quando succede — e nel frattempo ha composto di piu'.

⚠️ **Ma guardare la colonna p=5%: il capitale mediano e' $0 per OGNI calendario.** A quel tasso di
rischio la meta' dei percorsi finisce a zero (64% di rovina su 20 anni, come misurato stamattina) e
**come versi diventa irrilevante**. E' la formulazione piu' netta del rischio di venue trovata
finora: non erode il piano, lo **cancella**.

## 4. La domanda inversa — che rendita compra quello che posso permettermi

Rendita **netta** mediana in €/giorno:

```
  €/mese         5a        10a        15a        20a   P(€50/g a 20a)
     100      2.08€     6.54€    16.40€    38.07€            31.0%
     150      3.00€     9.55€    23.96€    55.80€            58.7%
     250      4.83€    15.53€    39.11€    91.30€            90.0%
     400      7.59€    24.52€    61.85€   144.23€            98.9%
     600     11.26€    36.52€    92.17€   215.07€           100.0%
```

E' la tabella che **riformula l'obiettivo**. €50/g e' un punto su questa griglia, non l'unico
risultato che conta: €150/mese porta a ~€24/g in 15 anni, che non e' un fallimento del piano da
€50 — e' un risultato diverso, e ora si sa quanto costa il salto.

Da notare la **non-linearita' temporale**: da 15 a 20 anni la rendita piu' che raddoppia a ogni
livello. Gli ultimi anni del piano contano piu' dei primi *in rendita*, esattamente come i primi
contano piu' degli ultimi *in versamenti*.

## 5. Ogni quanto versare — la decisione meno importante

```
 costo/tras.       mensile     bimestrale    trimestrale     semestrale
       $0.00     *$490,149       $486,725       $482,587       $473,908
       $2.00     *$486,597       $484,964       $481,446       $473,342
       $5.00      $481,270      *$482,323       $479,727       $472,495
      $25.00      $445,984       $464,692      *$468,226       $466,817
```

**Mensile fino a ~$2 di costo per trasferimento, bimestrale sopra.** Ma le differenze sono
**1-3%** del capitale finale: e' la meno importante delle cinque decisioni di questo diario, e non
merita ottimizzazione oltre la regola in una riga.

Verificato che un deposito **non resta strozzato**: col cap dinamico attivo (`_cap`), cap =
equity/2 = esattamente il nozionale massimo che il book puo' chiedere per asset.

## 6. Le cinque decisioni, in ordine di quanto pesano

| decisione | effetto misurato |
|---|---|
| **versare o no** | da **mai** a 16 anni |
| **quando** (front vs back, stesso totale) | **6x** sul capitale finale |
| **quanto presto smettere** | 5 anni = 25% dei soldi, 58% del risultato |
| piatto vs crescente | 24% a pari soldi |
| frequenza | 1-3% |

E sopra tutte, fuori scala: **a p=5% di rischio venue il risultato mediano e' zero comunque.**

## 7. Regole trasferibili

1. **Un piano di accumulo si giudica sulle sue deviazioni, non sul caso nominale.** Piatto,
   ininterrotto e per sempre e' l'unico scenario che non succede.
2. **Confrontare piani di taglia diversa richiede una metrica normalizzata** (`$ finale / $
   versato`), altrimenti "versa di piu'" vince sempre e non si impara niente.
3. **Un vantaggio calcolato ignorando un rischio noto va ri-misurato con quel rischio dentro**,
   anche quando ci si aspetta che regga — qui reggeva, ma la colonna p=5% ha prodotto il risultato
   piu' importante del filone.
4. **Quando l'obiettivo dichiarato non e' raggiungibile, la tabella utile e' quella inversa**:
   non "quando arrivo a X" ma "cosa compro con quello che ho".

---

# Addendum — il piano dichiarato: €5.000 subito + €500/mese

L'operatore ha dato i numeri veri. Cambiano la scala: €5.000 portano il conto da **$597 a $6.047
(10.1x)** e €500/mese e' il doppio del livello tabulato sopra. Ricalcolato in dedicata
(`r0726_piano_5k500.py`), non estrapolato.

## Quando

```
traguardo ($272.061):   p10 9.4a    MEDIANA 11.6a    p90 14.4a
P(entro 10a) 18%   P(entro 12a) 57%   P(entro 15a) 94%   P(entro 20a) 100%
```

```
 anno    capitale p10       MEDIANO           p90    rendita mediana
    1$        12,408$        14,057$       16,405           2.58 €/g
    3$        28,401$        34,674$       44,000           6.37 €/g
    5$        48,306$        62,952$       86,121          11.57 €/g
   10$       130,089$       191,398$      299,555          35.18 €/g
   15$       288,993$       476,825$      847,266          87.63 €/g
```

✅ **Validazione incrociata:** la variante "solo €500/mese da $600" da' **12.4 anni**, che e'
*esattamente* il numero pubblicato il 25/07 con macchineria diversa. Replica indipendente.

## Quanto vale il versamento iniziale: 0.8 anni

```
€5.000 subito (il piano)          11.6a
€5.000 spalmati sul 1° anno       11.7a
€5.000 al 5° anno                 12.1a
niente lump, solo €500/mese       12.4a
```

⚠️ **Meno di quanto suggerisse il "fattore 6" del §3**, e la ragione e' aritmetica: €5.000 sono
**~10 mesi** di versamenti a €500, quindi comprano ~10 mesi. Il fattore 6 riguardava lo spostamento
di €60.000 su vent'anni. **Anticipare vale in proporzione a quanto si anticipa** — ovvio a
posteriori, ma la mia aspettativa era piu' alta e va corretta.

## Le soglie, e la data che compare

```
$  3,000   GIA' SUPERATA il giorno 1   GTAA01 eseguibile
$  5,000   GIA' SUPERATA il giorno 1   XSR01 eseguibile (gate pre-registrato 23/10)
$ 13,000            ~0.9 anni          GTAA01 entra nel book deployable
$ 20,000            ~1.6 anni          SOGLIA DELLA DECISIONE VENUE
$117,000            ~7.6 anni          XS01 eseguibile
```

**La decisione "niente split fino a $20k" smette di essere un'ipotesi e diventa una data: ~19
mesi.** E le soglie $3k/$5k sono superate il primo giorno — il che NON autorizza ad anticipare il
gate XSR01 del 23/10 (anticiparlo e' selezione sull'hold-out), ma rende viva la sua domanda di
eseguibilita'.

## Con il rischio di venue dentro

```
 p annua   P(traguardo)   P(perso TUTTO)   cap. mediano 25a
   0.0%        100.0%            0.0%        $2,540,508
   0.5%         94.3%           11.7%        $2,304,596
   1.0%         88.0%           23.2%        $2,018,727
   2.0%         78.8%           39.6%        $1,464,013
   5.0%         55.4%           72.0%                $0
```

Il piano regge bene fino a p=2%. A p=5% il capitale mediano e' **zero**: e' la stessa conclusione
del §3, e vale a maggior ragione ora che il capitale in gioco e' 10x.

## ⚠️ AZIONE OPERATIVA PRIMA DEL VERSAMENTO — il cap fisso diventa una strozzatura

`src/live/book._cap` usa il cap **dinamico** (equity/2) solo quando l'equity reale e' leggibile;
altrimenti ripiega su `max_notional_per_asset_usd = $300`. **A $597 il fallback era INERTE**
(equity/2 = $298 ≈ $300). **Dopo il versamento l'equity/2 vale ~$3.023**, quindi un fallback
strozzerebbe il book a **~10% del target** — silenziosamente, con la sola allerta `eq_fallback`.

E' esattamente l'azione **gia' pre-registrata il 2026-07-02** (*"al deposito alzare il cap a
equity/2"*). Cablato `test_il_cap_fisso_diventa_una_strozzatura_dopo_un_deposito`: **fallisce** se
si deposita senza adeguare `max_notional_per_asset_usd`.

**Non eseguita**: e' un cambio di config su soldi veri, decisione dell'operatore.

---

## Il cap: alzato a $3.000, ma il modo conta piu' del numero

L'operatore ha autorizzato *"si alza il cap a 3000"*. Verificato prima di eseguire: **il deposito
non era ancora arrivato** (equity reale letta dal conto: $596.92). Alzare il cap in quel momento
sarebbe stato **pericoloso nel verso opposto**.

### Perche' alzarlo prima del deposito e' pericoloso

Quando l'equity reale non e' leggibile, `shadow_report` ripiega su `paper_cap` = **$2.000
nominali**, che non e' il conto vero. Il sizing diventa `0.5 × 2000 × (...)` = fino a $1.000/asset,
e **il cap fisso e' l'unica cosa che impedisce a quel nominale di diventare leva reale**:

| cap fisso | fallback su conto da $597 | leva reale |
|---|---|---|
| $300 (prima) | $300/asset = $600 lordi | **1.00x** ✅ |
| $3.000 (alzato a mano) | $1.000/asset = $2.000 lordi | **3.35x** ❌ |

Cioe' il cap sarebbe stato troppo alto **proprio nel momento in cui non si sa quanto c'e' sul
conto** — e con `disaster_sl_pct` −30% quella e' la configurazione peggiore possibile.

### La correzione: il fallback segue l'ultima equity osservata

Invece di alzare un numero da ricordare, il cap di fallback e' stato **legato al conto**:

```python
cap_fallback = min(cap_fisso_di_config, ultima_equity_reale_osservata * frac)
```

con un watermark in `data/live/equity_seen.json`, scritto da `book_report` ogni volta che l'equity
reale e' leggibile. Il cap di config torna a essere quello che dovrebbe: un **tetto dichiarato**.

Verificato sul conto vero, nei due regimi:

```
oggi, watermark $596.92     ->   $298.46/asset  = leva 1.00x
dopo il versamento, $6.047  -> $3,000.00/asset  = leva 0.99x
```

**Sicuro in entrambi gli ordini di eventi**, e senza dipendere da un'azione manuale al momento del
deposito. Senza watermark (primo avvio, file cancellato) si usa `CAP_UNKNOWN_USD` = $300: non si sa
niente del conto, si usa la taglia storicamente sicura.

Questo **chiude l'azione pre-registrata il 2026-07-02** (*"al deposito alzare il cap a equity/2"*),
rimasta ineseguita per 24 giorni — non eseguendola, ma **rendendola non necessaria**.

Guardie: `tests/test_cap_watermark.py` (11), **a due lati** — il cap non puo' ne' superare il conto
reale (leva nascosta) ne' restare sotto dopo un deposito (strozzatura).

### Regola trasferibile

**Un parametro di sicurezza che va aggiornato a mano a ogni cambio di scala e' un difetto, non una
configurazione.** Qui lo stesso numero era sbagliato in un verso prima del deposito e nell'altro
dopo: la soluzione non era scegliere il valore giusto, era **legarlo alla grandezza che lo
determina**. Il segnale che serviva questa correzione era gia' visibile: l'azione manuale era stata
pre-registrata 24 giorni prima e non era mai stata eseguita.

---

# Addendum 2 — "dai per scontato che non perdiamo mai con i trade?"

Obiezione dell'operatore. Si divide in due parti che hanno risposte **opposte**:
la prima e' infondata, la seconda coglie l'ipotesi piu' fragile di tutto il piano.
Script `r0726_decadimento.py`.

## Parte 1 — no: le perdite sono nel modello

Il block bootstrap ricampiona i ritorni **reali** del book a blocchi di 20 giorni, quindi conserva
autocorrelazione e forma dei drawdown.

```
serie reale (2.692 giorni):     in perdita 35.6% · flat 27.5% · in guadagno 36.9%
                                giorno peggiore -3.94% · peggior mese -5.76%
5.000 percorsi simulati (20a):  maxDD mediano 14.4% · p90 19.8% · PEGGIORE 44.2%
                                anni-calendario in perdita 5.8% (su 95.000 anni)
```

⚠️ **Errore mio catturato scrivendo questo**: la prima stesura riportava **63.9%** di giorni in
perdita. Artefatto: il de-luck sottrae una costante a *ogni* giorno (e' cosi' che riduce il drift
lasciando la vol invariata, come prescrive la misura d'ancora), quindi **trasforma il 27.5% di
giorni flat in piccoli negativi**. Corretto per il drift, fuorviante per la forma.
**REGOLA: una correzione uniforme sul drift e' giusta per le domande sul drift e sbagliata per le
domande sulla distribuzione** — la stessa serie dice 36% o 64% di giorni in perdita a seconda di
quale delle due si guarda, senza che sia cambiato niente.

## Parte 2 — si', ma l'assunzione e' un'altra: che l'edge continui a esistere

Il bootstrap assume che **il futuro sia il passato rimescolato**. Nessuna parte del progetto misura
il decadimento dell'alpha. Quanto costa se e' falso (piano €5.000 + €500/mese):

```
scenario                                    mediana traguardo  P(entro 20a)   cap. mediano 20a
edge intatto (cio' che ho mostrato finora)              11.6a        99.9%         $1,115,643
edge DIMEZZATO da subito                                15.8a        76.6%           $342,224
edge che decade a zero in 20 anni                       14.3a        65.5%           $269,970
edge che decade a zero in 10 anni                   oltre 20a        18.4%           $157,856
edge MORTO dall'anno 10 (rende 0)                   oltre 20a        42.0%           $259,553
edge MORTO dall'anno 5                              oltre 20a         0.0%           $163,377
```

**Il piano NON e' fragile a un dimezzamento dell'edge** (11.6 → 15.8 anni, P ancora 77%). **Lo e'
alla morte dell'edge.** E la differenza fra i due casi non e' distinguibile in anticipo — e' la
ragione per cui il progetto ha gate pre-registrati con date e soglie invece di aspettarsi che le
cose continuino a funzionare.

## Il limite strutturale del metodo

```
Peggior BIENNIO dell'intero campione: +3.0%
Se tutti i 20 anni fossero fatti cosi': P(traguardo) 2.9%, capitale mediano $149.014
                                        (a fronte di $136.847 versati)
```

**Il peggior biennio della storia del book e' POSITIVO.** Sette anni di storia crypto contengono
due mercati toro: un decennio davvero brutto **non e' mai successo**, quindi il bootstrap non lo
puo' estrarre. Non e' un parametro da alzare, e' il limite del ricampionamento: **non si puo'
simulare un regime peggiore di qualunque cosa ci sia nel campione.**

Se i prossimi 20 anni somigliassero al peggior biennio gia' visto, il capitale finirebbe **appena
sopra i soldi versati**: il piano non fallirebbe, semplicemente non renderebbe.

## Cosa se ne fa

Nessun cambio a book, pesi o piano. Cambia **cosa si sorveglia**: la domanda "l'edge c'e' ancora?"
non ha una risposta nel backtest, ce l'ha solo nel forward — che e' esattamente cio' che i monitor
paper e i gate pre-registrati esistono per misurare.