Files

T

Adriano Dal Pastro 9f55652d99 usde al 68,7%: il tetto del venue del 30-31/08 non c'era piu'; il versamento di prova del 25/08 dichiarato, TWR +7,83%

Su autorizzazione dell'operatore («usa piu' USDE», «cerca % massima raggiungibile»):
- usde_convert al 31,8% (774 USDE), poi sonda a saldo crescente r0906_usde_tetto_sonda.py
  (passi 100->20->4->1, doppio rifiuto prima di scendere, conferma a saldo neutro): da 31,8%
  a 68,7% in 39 ordini @ 1,0005, ZERO rifiuti. Fermata dal cuscino di regolamento (70%,
  derivato da config), non dal venue. «Il 70% non e' raggiungibile ne' ora ne' mai» (31/08)
  e' falsificato: il tetto e' sparito, non scalato. Non spiegato, puo' tornare.
- config: venue_cap_frac -> null (misura in venue_cap_misurato), quota_max_frac 0,50 -> 0,85
  (il valore scelto dall'operatore il 30/08 per questo scenario).
- debito §5.17: nessuno sorveglia il cuscino USDC (slack $58; una perdita del libro lo consuma
  da sola).

Versamento di prova di EUR 25 il 25/08 08:00Z (dichiarato dall'operatore): +3,3% su $647, sotto
la soglia del 10% del rilevatore, contato per 12 giorni come trading.
- data/live/movimenti_dichiarati.jsonl (append-only, nel backup) letto da
  journal.movimenti_dichiarati; movimenti_capitale lo fonde coi rilevati (fonte dichiarato,
  importo dell'operatore, dopo = prima + importo; dichiarato+rilevato se coincide; fuori
  letture o riga rotta -> avvisi). Report e nota di giornale lo dicono.
- trading da arming +87,35 -> +62,45; TWR +11,98% -> +7,83%. CLAUDE.md §2 aggiornato.
- tests: +6 in test_journal (conftest isola il file). Suite 916 verdi.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KSnordG9FT4q8M4MVm85GQ

2026-09-07 05:49:15 +00:00

6.5 KiB

Raw Blame History

2026-09-06 — USDE: dal 14,6% al 68,7%. Il tetto del venue del 30-31/08 non c'era piu'; il versamento di prova del 25/08 dichiarato

Ore: 20:56-21:16Z. Autorizzazioni dell'operatore, in sessione: «usa piu' USDE se ne hai bisogno», poi «cerca % massima raggiungibile in USDE», sulla decisione gia' presa il 30/08 (quota bersaglio 70%, usde.quota_target). E, a meta' sessione: «i 25 euro erano un versamento di prova».

1. Il versamento del 04/09 aveva dimezzato la quota

Il versamento di $2.410,14 del 04/09 14:47Z (riconosciuto dal classificatore: mercato max 0,56% a leva piena contro un salto del +116,8%) ha portato l'equity a ~$4.495 e la quota USDE da 31,3% a 14,6%. Nessun automatismo la riportava su.

2. Primo passo: al tetto di config (31,8%) — e la lettura SBAGLIATA che ne ho dato

usde_convert.py --quota 0.318 --esegui: 774 USDE in 8 ordini @ 1,0005 medio, zero rifiuti, quota 31,79%. Ho scritto in CLAUDE.md «il tetto ha tenuto la stessa frazione a equity 2,2× maggiore: terza conferma». Falso: nessun rifiuto fino al 31,8% dimostra che il tetto e' ≥ 31,8%, non che e' = 31,8%. Il dato non conteneva la conferma; l'ho letta perche' me l'aspettavo. Corretto venti minuti dopo, quando l'operatore ha chiesto la % massima e la sonda ha mostrato che la conferma non c'era.

3. La sonda: nessun tetto fino al 68,7%

scripts/research/r0906_usde_tetto_sonda.py — a saldo crescente, passi piccoli, stesso metodo dei diari 30-31/08 (un probe unico di taglia sbagliata produce un falso negativo): sale finche' il venue non rifiuta, ripete il rifiuto dopo aver riletto il book (il messaggio not_enough_funds_in_currency e' lo stesso di un limite che non incrocia), scende di passo a ogni doppio rifiuto, e conferma il muro a saldo neutro (SELL 1 → BUY 1 ok → BUY 1 rifiutato). Guardie: prezzo dal book (ask+5 tick, tetto 1,0010), quota mai oltre il 70% e USDC mai sotto il cuscino di regolamento derivato da config (usde_convert.cuscino_richiesto_usd).

corsa	passi	da → a (USDE)	quota	rifiuti
21:02-21:09	30 × 2	1.428,7 → 1.488,7	31,8% → 33,1%	0 (fermata dal mio limite +60)
21:11-21:15	16 × 100	1.488,7 → 3.088,7	33,1% → 68,7%	0 (fermata dal cuscino: +100 avrebbe superato il 70%)

Totale del giorno: 2.434 USDE in 39 ordini @ 1,0005, ~$1,2 di spread. Conto finale: USDC $1.407,40 + USDE 3.088,72 = $4.496; cuscino richiesto $1.349 → slack +$58. Registro: data/live/usde_convert.jsonl (due record sonda_tetto, con ogni ordine).

4. Cosa dice il risultato — e cosa non dice

Il tetto del 30-31/08 era vero allora ed e' sparito ora. Tre bracket riproducibili a 1 USDE (31,21-31,26% · 31,29-31,34% · 31,84-31,88%) contro 2.434 USDE accettati oggi senza un rifiuto. Non e' scalato, e' sparito: la frase del 31/08 «il 70% non e' raggiungibile ne' ora ne' mai» e' falsificata.
Non spiegato (D5). Ipotesi non verificabili da qui (il gateway non espone il transaction log ne' i parametri del cap): un'allocazione per-conto del Cap ETHENA che varia col saldo aggregato dell'exchange; un vincolo sui fondi depositati di recente (ma l'USDC del 04/09 e' stato convertibile a 2 giorni); un cambio di policy. Il tetto puo' tornare: quando tornera', bloccherebbe gli ACQUISTI, mai le vendite (tutte le SELL sono sempre passate). venue_cap_frac → null con la misura in venue_cap_misurato; usde_convert si affida al chunk+backoff sui rifiuti, che e' cio' che ha sempre fatto.
Il limite che morde e' NOSTRO: il cuscino di regolamento. P&L e funding dei perp si regolano in USDC; a 68,7% restano $58 sopra il cuscino. ⚠️ Nessuno sorveglia il cuscino: usde_watch allerta sulla quota (quota_max_frac, riportata a 0,85, il valore che l'operatore aveva scelto il 30/08 «in previsione della quota al 70%»), non sull'USDC. Una perdita del libro fa salire la quota da sola: a −$58 il cuscino e' scoperto, e Deribit finanzia un saldo USDC negativo allo 0,05%/giorno (18%/anno). Debito nuovo, §5.17.
Rischio emittente: a 24,2% l'evento Ethena valeva 3,1× il maxDD del libro (30/08); a 68,7% vale ~8,8×. E' la decisione del 30/08 presa con l'informazione completa (r0830_usde_quota), oggi eseguita. Resa attesa ~4,1% × $3.089 ≈ $127/anno (era $26): ancora meno di un mese di versamento.

5. Il versamento di prova del 25/08: dichiarato, scorporato, e il TWR scende di 4 punti

Trovato stamattina per differenza (equity 07:07→08:07 +$21,11 con le posizioni a −$3,3/−4,3) e confermato dall'operatore: €25 di prova prima del bonifico da $1.399,39 delle 11:47. Il rilevatore non poteva vederlo (+3,3% contro soglia 10%) e abbassare la soglia farebbe di ogni ora di mercato un candidato: l'unica fonte che sa l'importo e' l'operatore. Costruito il canale:

data/live/movimenti_dichiarati.jsonl (append-only, nel perimetro di backup — P11), letto da journal.movimenti_dichiarati(); movimenti_capitale lo fonde coi rilevati: fonte dichiarato, importo dell'operatore (non il salto), dopo = prima + importo cosi' il mercato dell'ora resta nel rendimento; se coincide con un salto rilevato l'importo dichiarato vince (dichiarato+rilevato); fuori dalle letture → avvisi, non applicato; riga rotta → avvisi, le altre restano (P3).
Importo registrato $24,90 ± 0,50: stimato per differenza (salto +21,11, mercato −3,3/−4,3 dal log del book, fee 0,03) — il gateway non espone get_deposits, quindi il numero USDC esatto non e' leggibile; la banda sta nel record e nel report (P12).
tests/test_journal.py: +6 (scorporo sotto soglia · dichiarato+rilevato · fuori letture · riga rotta · senza file niente cambia · la nota di giornale lo dice); conftest isola il file nei test.

	prima (20:47Z)	dopo (21:14Z)
movimenti certi	$3.809,53	$3.834,43
trading da arming	+$87,35	+$62,45
TWR	+11,98%	+7,83% = +8,14% × −0,62% × −0,12% × +0,46%

Un terzo del «trading» era un bonifico da 25 euro. Regola nuova (CLAUDE.md §2): ogni versamento, anche di prova, si dichiara nel file il giorno stesso.

6. File toccati

config/live.json (usde: venue_cap_frac null, quota_max_frac 0.85, nota) · src/live/journal.py · scripts/live/trades_db.py · tests/conftest.py · tests/test_journal.py (+6) · scripts/research/r0906_usde_tetto_sonda.py (nuovo) · data/live/movimenti_dichiarati.jsonl (nuovo) · CLAUDE.md §1 §2 §4 §5.

6.5 KiB Raw Blame History Unescape Escape