# 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. --- ## Addendum 3 — "+184% sembra alto, da dove arriva?" Obiezione dell'operatore su un numero che avevo citato io. **Aveva ragione, e l'errore era di metodo, non di calcolo.** ### Il numero e' vero Non e' un bug. Tracciato l'anno estremo: e' composto da 18 blocchi da 20 giorni, e **nessuno di essi e' negativo in modo significativo**: ``` +20% +15% +12% +10% +8% +8% +8% +7% +6% +6% +5% +5% +2% +1% +0% -0% -0% -1% ``` La popolazione da cui pesca lo consente: blocchi 20g reali con mediana **−0.1%**, p95 **+8.5%**, max **+22.4%**, **skew +2.15** — la firma classica di un trend-follower (molte perdite piccole, poche vincite grandi). E la materia prima esiste davvero: **la miglior finestra 365g della storia reale e' +89.8%** (il 2020 fece +58% come anno di calendario). ### Ma citarlo era sbagliato ``` su 1.000 anni simulati: max +96.0% su 5.000 anni simulati: max +135.2% su 20.000 anni simulati: max +135.2% su 114.000 anni simulati: max +184.3% ``` **Il massimo di N estrazioni cresce con N: descrive la taglia della mia simulazione, non la strategia.** Con 1.000 percorsi avrei scritto "+96%" e sarebbe stata la stessa strategia. Il numero che avevo dato all'operatore parlava del mio `N_PATHS`, non del book. I numeri corretti sono i **percentili**, che non dipendono dal campione: | p0.1 | p1 | p5 | p50 | p95 | p99 | p99.9 | |---|---|---|---|---|---|---| | −17.6% | −11.9% | −5.5% | **+16.0%** | +51.2% | +71.8% | +99.9% | Vale simmetricamente per il "peggiore": il **−27.4%** che avevo citato e' anch'esso un minimo campionario (a 1.000 percorsi era −19.1%). Il numero onesto per la coda sinistra e' **p1 = −11.9%**. ### Cablato Corretto anche `r0726_decadimento.py`, che riportava "drawdown PEGGIORE 44.2%" con lo stesso difetto: ora stampa **p99 = 26.0%** e dichiara esplicitamente che il 44.2% e' un massimo campionario da non citare come "il caso peggiore". ### Regola trasferibile **Il massimo (o il minimo) di una simulazione non e' una statistica della strategia: e' una statistica del numero di simulazioni.** Si citano i percentili. E' la stessa famiglia dell'errore gia' codificato oggi ("un percentile stampato a 0 decimali mente esattamente agli estremi"): gli estremi sono il posto dove i numeri sembrano piu' informativi e lo sono meno.