PythagorasGoal/docs/diary/2026-08-07-crescita-fisco-etf-scelta.md

# 2026-08-07 — La crescita del capitale, il fisco che nessuno aveva contato, e se invece fosse un ETF

**Richieste dell'operatore, in sequenza:** *«stato progetto»* → *«riepiloga piano»* → *«grafico della
crescita per anno con versamento e con guadagno»* → *«con 800 al mese»* → *«sistema dinamico dove
imposti valore iniziale, mensile e durata, e calcola la best curva fissando il tempo»* → *«il
guadagno come viene calcolato? e se mettessi in MSCI World o ETF SP500?»* → *«quale è la miglior
strategia?»*.

**Esito: book, pesi, cron, config INVARIATI.** Nessuna decisione operativa cambia. Cambiano tre
numeri pubblicati e cade un'affermazione su GTAA01.

---

## 0. Il buco trovato per primo: quattro risultati mai registrati

Ricostruendo il piano per l'operatore ho scoperto che **quattro commit del 27/07 sera non sono né
in CLAUDE.md né in un diario**: vivono solo nei messaggi di commit e negli script
(`r0727_3k_vs_5k.py`, `r0727_orizzonte10.py`, `r0727_tasse.py`). Uno di questi cambia il numero di
testa del piano — vedi §2. È il motivo per cui questo diario esiste prima ancora del lavoro nuovo.

---

## 1. Come si calcola il «guadagno» — la domanda che andava fatta

Nessuna traiettoria del progetto ipotizza un rendimento. Il meccanismo, ora scritto:

1. si parte dai ritorni giornalieri **veri** del book live (TP01 75% + SKH01 25%), 2.692 giorni dal
   2019-03-14, già netti di commissioni;
2. si toglie la fortuna d'ancora: `r − (1−0.89)·media(r)`;
3. si **rimescolano a blocchi di 20 giorni** (block bootstrap): blocchi, non giorni singoli, per
   non distruggere il raggruppamento della volatilità;
4. si compone: `cap *= (1+r)` ogni giorno, deposito ogni 30, imposta a fine anno, su 4.000 percorsi;
5. **`guadagno = mediana(capitale) − versato`**.

Drift implicito: **17,1% annuo, vol 10,9%**. Non è un'assunzione sul rendimento — è l'assunzione
che *il futuro somigli a quei 7 anni*. Che è esattamente ciò che §3 mette alla prova.

Script: `scripts/research/r0807_growth_yearly.py` (`--lump`, `--dep`, `--anni`, `--json`).

---

## 2. ⚠️ Il fisco durante l'ACCUMULO — la voce mai contata

`TAX_RATE` compariva in **un solo punto** di tutto il progetto: la lordizzazione del bersaglio in
fase di *prelievo*. L'accumulo componeva al lordo per dieci o vent'anni. Misurato il 27/07
(`r0727_tasse.py`) e riprodotto oggi su lump €5.000 + €500/mese:

| | 5 anni | 10 anni | 15 anni |
|---|---|---|---|
| costo del fisco d'accumulo | **−15,7%** | **−29,8%** | **−42,6%** |

(27/07, lump €10k: −16,8% / −31% / −44% → replica coerente su lump diverso.)

**L'errore è composto, non una tantum.** Conseguenza da tenere presente: *tutte* le tabelle a 15-20
anni pubblicate in CLAUDE.md sono al lordo del fisco d'accumulo e vanno lette con questo sconto
sopra. Assunzioni dichiarate (33% plusvalenze, minusvalenze in carry 4 anni, 0,2% annuo sul valore),
**non un parere fiscale**.

Piano a €800/mese, 15 anni: capitale mediano **$450.107** netto contro $776.366 lordo.

📌 **Risultato contro-intuitivo:** versare di più **ritarda il sorpasso** (l'anno in cui il guadagno
cumulato supera tutto il versato): 7º anno a €500/mese, 8º a €800, perché si alza l'asticella che
il guadagno deve superare. I €300 in più non comprano il sorpasso, comprano il **traguardo**: la
mediana tocca il bersaglio al 12º anno invece che al 15º, e P(bersaglio) a 15 anni passa da 73,2% a
99,0%.

⚠️ **€800/mese non bastano per il vincolo dei 10 anni**: P(entro 10 anni) col fisco = **25,5%**.
Servono ~€880-1.050/mese (27/07), e a quel punto si versano oltre $119.000 per arrivare a $272.061.

---

## 3. E se invece fosse un ETF S&P 500 o MSCI World

Script `scripts/research/r0807_asset_compare.py`. Tre cose andavano rese comparabili:

- **la griglia** — le azioni hanno ~252 barre/anno, il book 365: portate su calendario con **0,0 a
  borsa chiusa** (convenzione GTAA01). Senza, il Sharpe esce ×1,20 (lezione 25/07);
- **il fisco** — il book realizza ogni anno al 33%; un UCITS ad accumulazione paga il 26% **alla
  vendita**. Il differimento è un vantaggio strutturale dell'ETF, ora nel modello (le curve ETF
  sono valori di *liquidazione*, già al netto dell'imposta latente);
- **il bersaglio** — $272.061 vale per la rendita perpetua *del book* e per il 33%. Ricalcolato per
  ciascuno.

| a 15 anni, €5.000 + €500/mese | book | S&P 500 | MSCI World (proxy) |
|---|---|---|---|
| rendita perpetua | 11,67% | 4,16% | 3,09% |
| capitale-rendita necessario | $254.524 | $646.172 | $869.729 |
| **lente A** — storia piena di ciascuno | $293.823 → **115%** | $204.663 → **32%** | $188.417 → 22% |
| **lente B** — stessa finestra 2019-26 | $295.540 → **118%** | $343.805 → **110%** | $296.707 → 82% |

**Il risultato che conta non è quale vince, è che le due lenti danno risposte opposte.** Sulla
storia piena il book stravince; sulla stessa finestra **l'S&P 500 accumula più del book**. Il
divario della lente A viene interamente dal fatto che i 30 anni dell'indice contengono il 2000 e il
2008, crolli che la strategia non ha mai vissuto.

📌 **E in una riga della tabella delle serie c'è il fatto più importante:** sulla stessa finestra il
rendimento è quasi identico — **17,4% contro 16,8%**. Tutta la differenza è nel rischio: vol 11,0%
contro 19,6%, maxDD 10,5% contro 33,7%. **Il book non guadagna di più, perde di meno** — che è
precisamente ciò che il progetto scrive di TP01 dal 19/06, qui misurato contro un'alternativa vera.
E la rendita perpetua vive sul drawdown: per questo il book ha bisogno di **2,5× meno capitale**.

⚠️ MSCI World è un **proxy** (70% SPY + 30% EFA): URTH/ACWI/VT non sono nell'abbonamento dati del
conto IB. Fra 50% e 80% di quota USA il drift si muove di 0,7 punti e il Sharpe di 0,05.

---

## 4. Quale strategia: book, ETF o un mix

Script `scripts/research/r0807_best_strategy.py`.

⚠️ **Difetto della prima stesura, corretto: un mix esiste solo dove esistono ENTRAMBE le serie.**
Confrontavo «storia piena» contro «stessa finestra» come due lenti, ma calcolavo i bersagli del mix
sull'intersezione in entrambe — quindi la lente «storia piena» dichiarava trent'anni e ne usava
sette (per l'ETF puro dava rendita 8,63% invece del 4,16% vero). **Il confronto fra finestre non è
disponibile per un portafoglio misto.** Rifatto su una finestra sola, con gli scenari espressi come
spostamento del **drift**, applicabile simmetricamente ai due lati.

| quota sul book | base | equity a 30 anni | book dimezzato | entrambi cauti | peggiore | **rimpianto max** |
|---|---|---|---|---|---|---|
| solo ETF | 68% | 23% | 68% | 23% | 23% | 53% |
| 25% book | 80% | 41% | 60% | 27% | 27% | 34% |
| **50% book** | **86%** | 58% | 48% | 27% | 27% | **20%** |
| 75% book | 84% | 69% | 32% | 23% | 23% | 35% |
| solo book | 75% | **75%** | 16% | 16% | 16% | 52% |

**Risposta: 50/50**, non perché vinca (vince solo nello scenario base) ma perché ha il **rimpianto
massimo più basso**. ⚠️ Il criterio del solo caso peggiore **non** distingue 25% da 50% (27,09%
contro 26,99% = pareggio dentro il rumore): a separarli è il rimpianto.

📌 **L'asimmetria fra i due stress È il risultato.** Quello sull'equity è **misurato** — trent'anni
esistono e dicono 11,3% invece di 16,5%. Quello sul book è **giudiziale** — metà del drift, scelto a
mano, perché 7,4 anni sono tutta la storia che ha e *non c'è nulla con cui stressarlo*. Si può
discutere la taglia del taglio, non lo si può togliere. La sua conseguenza è brutale: col drift
dimezzato il capitale-rendita del book puro passa da $254k a **$771.646** (rendita 11,67% → 3,85%).

**Perché il mix non è un compromesso:** correlazione book↔S&P **+0,082** nei giorni di borsa aperta,
**+0,046** nei ribassi; nel 5% di giornate peggiori dell'indice (media −2,94%) il book fa **−0,11%**.
Il capitale-rendita del 50/50 è **$235.769**, più basso sia del solo ETF ($311.567) sia del solo
book ($254.524): due motori scorrelati *abbassano l'asticella*.

⚠️ Non c'è il rischio di venue (spingerebbe ancora verso il mix), e la decisione del 26/07 tiene
tutto su Deribit fino a $20k: questa analisi è **materiale per quella soglia**, non un'indicazione
di agire adesso.

---

## 5. Il simulatore nel browser, e la sua verifica

`scripts/web/` — motore di accumulo in JavaScript (`engine.js`), serie esportata da
`export_series.py`, pagine assemblate da `build.py`.

**Il motore JS deve dare la stessa risposta del Python, e lo si prova:** `test_engine.js` confronta
mediane e probabilità su due configurazioni già calcolate, verifica che il *versato* (deterministico)
coincida al centesimo, e include un **controllo positivo** (un motore col fisco spento dev'essere
rilevato fuori tolleranza — un test che non sa fallire non è un test). Il risolutore («quanto serve
al mese per centrare il bersaglio in N anni») è validato contro `dep_necessario` di `r0727_tasse.py`:
scarti −0,4% / −0,6% / −1,1% su tre configurazioni.

Misura che ha cambiato una scelta: la banda del versamento suggerito resta **±1% da 1.200 a 3.000
percorsi** → non domina il Monte Carlo ma la granularità della bisezione (~€5). Percorsi tenuti
bassi e **incertezza dichiarata**, invece di pagare tempo per una precisione che non arriva.

---

## 6. Quattro errori miei, tutti trovati da un controllo e non a occhio

Sono la parte riutilizzabile del diario.

**(a) Dati inventati in un grafico.** Le righe degli anni 1-2 di una serie erano scritte *a memoria*
perché l'output del terminale era troncato da `tail`. Le ha trovate il confronto riga-per-riga fra
il JSON e i dati incollati nella pagina. **Regola: i dati di una pagina si INIETTANO da un file, mai
si trascrivono** — ora è `build.py` a farlo, e il passaggio manuale non esiste più.

**(b) «Distorsione sistematica» che non esisteva.** Il motore JS sembrava +0,75% sopra il Python su
8 semi, tutti positivi. Ma erano **8 estrazioni contro UN solo punto Python** (seme 807), che stava
in basso nella propria distribuzione: 8 segni concordi rispetto a un punto rumoroso non sono 8
osservazioni indipendenti. Misurato bene (8 semi per parte): **−0,01%, t = −0,04**; e i due
campionatori cadono entrambi entro 1,7 SE dall'**atteso analitico** della media di blocco.
**Regola: un confronto punto-contro-distribuzione non produce evidenza di distorsione.**

**(c) Un confronto impossibile per costruzione** — §4, il mix sull'intersezione.

**(d) Una pagina pubblicata rotta.** Python scrive le chiavi dei pesi come `"0.0"`/`"1.0"`, la pagina
le ricostruiva con `String(0)` → `"0"`: ogni lookup `undefined`, script morto alla prima riga utile.
I pesi intermedi funzionavano *per caso*. **Il controllo che usavo (`node --check`) valida solo la
SINTASSI**: ora c'è `smoke.js`, che esegue le pagine con un DOM finto e segnala sia le eccezioni sia
gli elementi riempiti con `"undefined"`. **Regola: le chiavi di un dizionario Python si LEGGONO dal
JSON, non si ricostruiscono.**

---

## 7. ⚠️ Effetto collaterale del check: un gate di GTAA01 ora FALLISCE

`tests/test_gtaa_band_gate.py::test_la_proposta_non_e_selezionata_sull_hold_out` — la proposta
(banda 25%, cadenza 5g) risulta **9ª/30 in-sample e 8ª/30 sull'hold-out**: migliora passando
all'hold-out, cioè la firma che il test intercetta. CLAUDE.md registra **4/30 e 5/30** (27/07).

Caratterizzato prima di riportarlo:

- i due ranghi sono separati da **0,00116 di Sharpe** su un'ampiezza di griglia di 0,3124 = lo
  **0,4%**: il criterio non ha mai avuto margine, era una differenza di un rango;
- il calcolo è **deterministico** (due corse, `max|diff| = 0.0`) e il codice del gate è **invariato**
  dal 27/07 (nessun commit su `r0727_gtaa_band_gate.py`, `gtaa.py`, `eqlib.py`, `eq_splits.py`);
- quindi è cambiato **il dato**: `data/raw/` è gitignored e i parquet equity vengono riscritti ogni
  giorno dal cron con `ADJUSTED_LAST` di IB, che è retroattivo.

📌 **La lezione vale più del test: un gate validato su dati sovrascritti ogni giorno non è
ri-verificabile.** Il lato cripto non ha questo problema (`rebuild_history.py` ricostruisce da una
sorgente deterministica); il lato equity sì.

**Il test NON è stato toccato** — allentare una soglia perché ha smesso di passare è ciò che questo
progetto vieta, e un `xfail` silenzierebbe esattamente il segnale. Nulla di operativo dipende da
questo (GTAA01 non è deployabile per il blocco PRIIPs e non è nel book live), ma l'affermazione
*«il rango NON migliora sull'hold-out»* oggi è falsa: **decisione dell'operatore** se correggere
l'affermazione, ripensare il gate, o congelare uno snapshot dei parquet equity per renderlo
riproducibile.

---

## Cosa NON cambia

Book, pesi, cron, `config/live.json`, i gate pre-registrati (STATARB 27/09, XSR01 23/10,
DVOLSPREAD 24/10), la decisione di venue (100% Deribit fino a $20k), il muro pubblicato di
$272.061. Gli script di questo diario non toccano la produzione.