Adriano Dal Pastro
cf7de40dc0
Il cap notional per-asset non e' piu' fisso a $300: con max_notional_per_asset_frac in config diventa equity/2, cosi' cresce col capitale e un deposito futuro non resta strozzato (frontiera 2026-07-03). Guardrail: dinamico SOLO con equity reale fidata; su fallback/offline si torna al cap fisso (protezione downside quando E e' ignota). Live dry-run: cap $299 a equity $598 -> inerte oggi. Suite 172 passed (+4 test). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
48 lines
3.1 KiB
Markdown
48 lines
3.1 KiB
Markdown
# 2026-07-03 — Cap notional per-asset DINAMICO (= equity/2): operazionalizza la decisione frontier
|
||
|
||
**Contesto.** La frontiera del 2026-07-03 (`docs/diary/2026-07-03-book-frontier.md`) aveva identificato
|
||
**una sola** azione config con impatto reale: portare `max_notional_per_asset_usd` da $300 fisso a
|
||
**equity/2**, perché il cap fisso strozza il book man mano che si deposita (paradosso: più capitale =
|
||
book più freddo — a $5k il cap $300 fa girare il libro al ~49% del target). Il diario la lasciava
|
||
"da applicare AL deposito". Qui la **operazionalizzo in codice** rendendo il cap dinamico, così è
|
||
sempre corretta e non richiede un edit manuale al deposito.
|
||
|
||
## Cosa è cambiato
|
||
|
||
- **`src/live/book.py` — `_cap()`**: se in config c'è `max_notional_per_asset_frac` (opt-in), il cap
|
||
per-asset diventa **`equity × frac`** (0.5 → equity/2). Senza la chiave → comportamento vecchio
|
||
(cap fisso `max_notional_per_asset_usd`). Il call site in `book_report()` passa
|
||
`equity`, `real_equity`, `eq_fallback` a `_cap()`.
|
||
- **`config/live.json`**: aggiunto `max_notional_per_asset_frac: 0.5` (+ nota). `max_notional_per_asset_usd`
|
||
resta come **cap fisso di fallback**.
|
||
- **`tests/test_book_live.py`**: +4 test (scaling con equity fidata, fallback su eq_fallback/real=None/
|
||
equity 0, no-frac, integrazione online). Suite: **172 passed**.
|
||
|
||
## Il guardrail di sicurezza (il punto delicato)
|
||
|
||
Il cap dinamico si usa **SOLO con equity reale fidata** (letta dal conto). Se l'equity reale non è
|
||
leggibile — `eq_fallback` attivo, `real_equity=None`, offline, o equity ≤ 0 — si **torna al cap fisso
|
||
$300**. Motivo: in fallback `equity` è il paper-cap ($2000 ipotetico); calcolare `equity/2 = $1000` su
|
||
un conto di importo reale **ignoto** sizerebbe troppo. Preserva esattamente la protezione downside che
|
||
il test `test_book_execute_eq_fallback_warns_but_proceeds` verificava (l'hard-cap $/asset protegge
|
||
quando E è ignota). Regola: **equity/2 solo quando ci fidiamo di E; altrimenti $300 fisso.**
|
||
|
||
## Verifica
|
||
|
||
- **Live dry-run reale** (nessun `--execute`, nessun ordine): `cap/asset **$299**` = $598.06/2 →
|
||
**INERTE** oggi (≡ vecchio $300). Book flat, HOLD.
|
||
- Offline / `equity_override`: cap resta **$300 fisso** (nessuna equity reale da fidarsi) → il test
|
||
di parità pre-esistente regge invariato.
|
||
- A $5.000 di equity il cap diventerebbe automaticamente **$2.500** (equity/2), rimuovendo il
|
||
throttling che la frontiera aveva quantificato.
|
||
|
||
## Impatto e limiti
|
||
|
||
- **Già attivo**: il cron orario (`cron_book.sh`) esegue dal working tree → il prossimo run legge già
|
||
`frac=0.5`. Nessun deploy separato. **Inerte a $600**, si "accende" da sé quando l'equity cresce.
|
||
- **NON avvicina €50/g**: la frontiera lo aveva già detto — è una miglioria marginale (+€0.2/g @2k,
|
||
+€0.5/g @5k), il cui unico scopo è non lasciare capitale futuro strozzato. €50/g resta un problema
|
||
di **capitale + tempo** (~130k @ CAGR onesto), non di questo cap.
|
||
- Nessun cambio di **leva** (TP01 `target_vol=20%` invariato, la vol nativa ~10% emerge da sola —
|
||
coerente col verdetto frontier "gira alla vol nativa, non levare").
|