research(capitale): "5k messi dove" — lo split si ottiene versando di meno
Misura nuova: a $6.050 lo split CON GTAA01 e' impossibile (servirebbe il 50% del conto per i $3.000 di gamba minima), ma quello in LIQUIDITA' non ha soglie. Due correzioni prima dei numeri: - la configurazione vera e' 5.000 + 500/mese (dal commento in config/live.json del 26/07), non i 250/mese di tutte le tabelle. Nessuna azione di config: il cap e' gia' armato e vale min($3.000, equity_osservata x 0.5) = leva lorda <=1x. - a $6.050 non si sblocca nulla (GTAA01/XS01/XSR01 tutti fuori portata o sotto gate): il book resta TP01+SKH01. Split in liquidita' (p=1%, 20a): fuori 10% -> P(perso tutto) 18.4% -> 3.5% (0.0% con cassa in banca), salvati $6.818; 25% -> salvati $17.045, al prezzo di 0.9pp di P(arrivare) e circa un anno di ritardo mediano. P(perso tutto) SATURA a qualunque quota > 0: la protezione binaria si compra col fatto di avere un secondo conto. Cio' che distingue le quote e' il salvataggio. ERRORE CORRETTO IN SESSIONE: la colonna del salvataggio riportava prima il capitale a 20 anni condizionato al fallimento ($77k al 10% = 11x il vero), gonfiato dalla convenzione ereditata dal 26/07 per cui i versamenti si dirottano ai superstiti -> attribuiva allo split il valore di continuare a versare, che si ottiene comunque aprendo un altro conto. Ora misura il salvataggio istantaneo, congelato in un test. simulate() accetta un hazard PER VENUE (una cassa in banca non fallisce come un exchange); la replica esatta dei numeri del 26/07 e' preservata e testata. Test: 4 nuovi (508 totali), tutti verdi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1373,6 +1373,27 @@ Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condivis
|
||||
= il caso in cui CLAUDE.md dice di riaprire PRIMA.** Materiale pronto; la decisione resta
|
||||
dell'operatore. ⚠️ Cosa NON decide: quanto dei €6.043 sia vero fondo d'emergenza (un fondo
|
||||
d'emergenza non e' capitale disponibile).
|
||||
✅ **ADDENDUM "€5k messi dove" (stessa sessione).** (a) ⚠️ La configurazione REALE non era quella
|
||||
tabulata: `config/live.json` fu alzato il 26/07 *"in previsione del versamento (EUR 5.000 +
|
||||
500/mese)"* → il piano e' **€500/mese**, non €250. **Nessuna azione di config al deposito**: il
|
||||
cap e' gia' `min($3.000, equity_osservata × 0.5)` = leva lorda ≤1x a $6.050, protetto dal
|
||||
watermark. (b) **A $6.050 non si sblocca NIENTE** (GTAA01 vorrebbe il 50% del conto e non e'
|
||||
deployabile; XS01 $20k; XSR01 sotto gate) → il book resta TP01+SKH01 e l'unica domanda e' quanta
|
||||
parte NON sta sull'exchange. (c) **Split in liquidita', p=1%, 20a:** fuori 0% → P(arrivare)
|
||||
89.4% / 11.4a / P(perso tutto) 18.4%; **10% → 89.0% / 11.8a / 3.5% [0.0% con cassa in banca] /
|
||||
salvati $6.818**; **25% → 88.5% / 12.4a / salvati $17.045**; 40% → 87.8% / 13.3a / $27.272.
|
||||
⚠️ **P(perso tutto) SATURA a qualunque quota > 0** (3.5% al 10, 25 e 40%): la protezione binaria
|
||||
si compra col FATTO di avere un secondo conto, non con quanto ci si mette → **quando una metrica
|
||||
binaria satura, la decisione si sposta sulla metrica continua** (qui il salvataggio).
|
||||
⚠️ **Errore mio corretto in sessione:** la colonna del salvataggio riportava prima il capitale a
|
||||
20 anni condizionato al fallimento ($77k al 10% = 11× il vero), gonfiato dalla convenzione
|
||||
ereditata dal 26/07 per cui **i versamenti si dirottano ai superstiti** (e si scartano se non ne
|
||||
resta nessuno) → attribuiva allo split il valore di *continuare a versare*, che si ottiene
|
||||
comunque aprendo un altro conto. Misura onesta = **salvataggio ISTANTANEO**, congelata in
|
||||
`test_il_salvataggio_e_istantaneo_non_a_scadenza`. (d) ✅ **Lo split non si costruisce spostando
|
||||
soldi su un secondo venue: si ottiene versandone di meno.** Con €6.043 in XEON, deporne €5.000
|
||||
lascia fuori ~16% del capitale investito = gia' dentro la banda 10-25%, **a costo operativo
|
||||
zero**. Prezzo del 25%: −0.9pp di P(arrivare) e ~1 anno di ritardo mediano.
|
||||
- ✅ **FEE WATCH + MONITOR HEALTH — due sorveglianze cablate (2026-07-27).** Nessuna tocca
|
||||
l'esecuzione; entrambe in `cron_daily.sh`. (1) **`scripts/live/fee_watch.py`** (test 13): il
|
||||
nuovo schema fee Deribit entra il **1° agosto** e l'annuncio non ha numeri → invece di un
|
||||
|
||||
Reference in New Issue
Block a user