Files

T

Adriano Dal Pastro cf7de40dc0 feat(live): cap/asset dinamico = equity/2 — operazionalizza la decisione frontier (inerte a $600)

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>

2026-07-03 09:42:13 +00:00

3.1 KiB

Raw Blame History

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").

3.1 KiB Raw Blame History Unescape Escape