PythagorasGoal/docs/diary/2026-08-30-usde-quota-tetto-venue.md

2026-08-30 — "porta in USDE tutto il capitale che non viene usato": il venue dice 31%

Richiesta dell'operatore, verbatim: "porta in usde tutto il capitale che non viene usato". Arriva il 30/08, cioè un giorno prima della data a cui l'operatore stesso aveva rinviato la decisione di quota (gate USDE-01, rinvio al 31/08). L'anticipo è esplicito e vale come decisione.

1. "Il capitale che non viene usato" non è una quantità piccola: è quasi tutto

Stato letto dal gateway alle 19:50Z: USDC $1.563,09 (di cui $11,36 impegnati a margine), USDE 500,1757 → $500,18, totale $2.063,26, quota 24,2%. Posizioni BTC $354,72 + ETH $213,36 = $568,08 lordi (0,275x).

Il margine consuma $11 su $2.063, e l'USDE è cross-collateral: convertirlo non lo toglie dall'uso. Anche a piena esposizione del libro (lordo 1,0x) il margine sarebbe ~$41. Presa alla lettera la richiesta è una quota ~99% — il 100% che il gate esclude per nome ("mai 100%: R1 emittente non recuperabile"). Le due letture plausibili ("non a margine" e "non esposto dal libro") convergono entrambe su ~97-99%: non è un'ambiguità che si risolve scegliendo, è una che si porta all'operatore.

2. Il vincolo che r0830_usde_quota non aveva guardato: il cuscino di REGOLAMENTO

L'analisi del 30/08 aveva misurato il margine e concluso — correttamente — che l'haircut non morde a nessuna quota fino al 90%, nemmeno a leva 1,50x con USDE a 0,95. Vero, e irrilevante: il P&L e il funding dei perp USDC-lineari si regolano in USDC, non nel collaterale. Lo si vede nel conto: equity − balance = $7,24 di floating, tutto nel secchio USDC.

A quota 99% resterebbero $41 di USDC contro un libro che, col disaster-SL a −30% sulla massima esposizione, può perderne **$619**: il saldo va negativo e Deribit lo finanzia a interesse, che si mangia la resa che si stava comprando. Il vincolo non è il margine, ma non è nemmeno assente.

📌 Corretto e QUANTIFICATO il 31/08 (KB Cross collateral specifications): «a collateral fee will be charged […] default = 0.05% per day», al secondo, sulla valuta negativa — cioè 18,25%/anno, 4,3× la resa USDE che si starebbe comprando. Il ribilanciamento automatico non salva: scatta a $1M assoluti o al 100% della cross equity, soglie irraggiungibili a $2k. Qui il 30/08 avevo scritto «lo finanzia a interesse» senza il numero: il numero rende il criterio del cuscino più giustificato, non meno.

Criterio dichiarato: cuscino USDC ≥ disaster-SL sulla massima esposizione lorda del libro = n_asset × frac × disaster_sl_pct = 2 × 0,5 × 0,30 = 30% dell'equity — tutto derivato da config/live.json e src/live/book.py, mai ridichiarato (P1). Che lascia esattamente 70%. Non è un argmax (M8): la quota massima e il criterio coincidono per costruzione, e infatti il 70% cade esattamente sul limite, con zero slack.

Tabella portata all'operatore (APR allora creduta 3,26% [1,13-4,51], n=4 — vedi §5, è sbagliata):

quota	converti	USDC che resta	resa/anno	evento emittente vs maxDD libro
24,2% (allora)	—	$1.563	$16	3,1×
50%	$531	$1.032	$34	6,3×
70%	$944	$619	$47	8,8×
~99%	$1.522	$41	$66	12,3×

Scelta dell'operatore: 70%, il massimo compatibile col cuscino.

3. Esecuzione: da 500 a 644 USDE, poi il muro

Nuovo attrezzo scripts/live/usde_convert.py (dry-run di default). Non passa da DeribitTrader: execution.ALLOWED ammette solo i due perp del libro ed è il guardrail anti-fat-finger del percorso soldi — non si allarga per farci entrare uno spot che col libro non c'entra. Lo script porta le proprie guardie: banda prezzo [0,995 – 1,005], tetto HARD di quota 0,95, il cuscino di regolamento, dry-run.

Convertiti +144 USDE (500,1757 → 644,175691), quota 24,24% → 31,21%, tutti i fill a 1,0002-1,0003, fee 0. Poi ogni acquisto ha smesso di passare.

4. not_enough_funds_in_currency è un messaggio FUORVIANTE — la cronaca delle ipotesi sbagliate

Si tiene apposta, perché chi rilegge non deve rifare questo giro. Tre ipotesi, tutte plausibili, tutte sbagliate:

1. "È la taglia." 943,98 rifiutato per Invalid params → vero: min_trade_amount: 1 e contract_size: 1, il passo è intero (confermato da public/get_instrument; il gateway non espone quel tool, la risposta è arrivata dall'API pubblica). Quantizzato a intero: 933 rifiutato per fondi, con $1.541 disponibili. Falso indizio.
2. "È il rate-limit." 100 passava e 300 no; poi anche 1 rifiutato otto volte di fila. Aggiunto backoff sul tempo fino a 90s: rifiutato lo stesso. Falso.
3. "È il prezzo." Diagnosi a tre ordini da 1 USDE: SELL @1,0000 OK, BUY @1,0003 OK, BUY @1,0002 e BUY market rifiutati. Vero in parte: il book REST pubblico è in ritardo sul matching engine, e un limite a ask+1 tick a volte non incrocia davvero. Difetto mio, e istruttivo: prezzavo l'ordine sull'indice invece che sul book. Sono due prezzi con due mestieri — l'indice marca il collaterale (usde.valuta, mediana multi-exchange: la lezione Binance 10/10), il book prezza lo scambio. Corretto con 5 tick di margine e tetto duro 1,0010: il fill avviene al prezzo del libro, quindi il margine non si paga.

Ma corretto il prezzo, 200 e 800 continuavano a fallire con 4.552 di profondità all'ask.

5. 🚨 Il fatto vero: un TETTO DEL VENUE sull'USDE, a 644,175691 (31,21%)

Esperimento a saldo neutro, quattro ordini di fila (20:14Z):

BUY  20 @1.0007 -> not_enough_funds_in_currency    USDE 644.1757
SELL 20 @0.9996 -> OK                              USDE 624.1757
BUY  20 @1.0007 -> OK                              USDE 644.1757
BUY   5 @1.0007 -> not_enough_funds_in_currency    USDE 644.1757

È un tetto sul LIVELLO: non taglia, non prezzo, non liquidità, non cadenza, non fondi ($1.408 disponibili). Lo stesso ordine che viene rifiutato passa subito dopo una vendita di pari taglia. La quota del 70% non è raggiungibile, e nemmeno il 50%.

La formula del tetto non è leggibile da qui: public/get_currencies non espone un cap (in_cross_collateral_pool: true, nient'altro), e il gateway non espone né get_order_book né available_withdrawal_funds — è il debito #11, il gateway è l'unico pezzo della catena che possediamo e si ha solo quel che espone. Registrato come fatto misurato, non spiegato (D5: un buco quantificato è un risultato, uno taciuto è un debito).

6. 🚨 E la resa non è quella che credevamo: l'USDC paga 3,40%

public/get_currencies, letta oggi:

valuta	APR pubblicata
USDE	4,1071%
USDC	3,4000%

I nostri reward USDE misurati (+0,052055 · +0,061815 · +0,061821 al giorno su 500 → ~4,5%/anno) confermano che la APR pubblicata di USDE è reale. Il che rende credibile anche l'altra riga.

Se l'USDC frutta già 3,40%, il guadagno del passaggio a USDE non è il tasso: è lo spread, 0,71 punti. Sui $644 che teniamo vale ~$4,6/anno, non $21; sui $144 convertiti oggi, ~$1,0/anno. Il gate USDE-01 ha misurato con cura il reward dell'USDE e non ha mai chiesto cosa facesse l'USDC fermo: è il controfattuale mancante — M1 in un'altra veste, si giudica il marginale, non il livello. E cambia il verso della decisione: si prende un rischio emittente non recuperabile (a 31,2% vale 3,9× il maxDD dell'intero libro) per 0,71 punti.

⚠️ Quello che NON è dimostrato: che la APR USDC sia effettivamente accreditata sul nostro conto. Sull'USDE l'abbiamo vista arrivare per delta; sull'USDC il P&L di trading copre $0,13/giorno di interesse e il gateway non espone il Transaction Log. Va verificato su un giorno senza trade prima di trattarlo come misura — qui è una APR pubblicata dal venue più una conferma indiretta, non un reward osservato.

7. Cosa resta a terra

• Conto: USDC $1.419,61 · USDE 644,175691 ($644,18) · totale $2.063,79 · quota 31,21%. Nessun ordine spot appeso (restano i due tp01-disaster reduce_only). Posizioni invariate. Equity vista dal book $2.063,86 ("mainnet USDC + USDE 644 @ 1.0000"): sizing corretto, nessun falso "uscita di fondi".
• config/live.json: aggiunto quota_target: 0.70 (la decisione dell'operatore, oggi bloccata dal venue). quota_max_frac alzato a 0,85 e rimesso a 0,50 nella stessa sessione: la soglia larga presupponeva un 70% che non esiste, e lasciarla avrebbe disarmato la guardia per uno scenario che non si è verificato. Con la quota reale al 31%, il 50% morde di nuovo.
• Non fatto: portare la quota al 70%. Il venue non lo consente. Non è una rinuncia discrezionale, è un rifiuto misurato e riproducibile.

---

APPENDICE (stessa sera, 23:40-23:55Z) — l'USDC NON frutta sul nostro conto: §6 era sbagliata

Richiesta dell'operatore: "verifica se l'USDC frutta davvero sul nostro conto". Verificato. La risposta ribalta la §6 di questo stesso diario, che va letta con questa appendice accanto.

Perché la domanda sembrava dover aspettare, e invece no

Il gateway non espone il Transaction Log (provati get_transaction_log, get_settlement_history, get_deposits, get_transfers, get_interest_history: tutti 404 — debito #11). L'unica serie storica del conto è trades.db.equity: oraria ma arrotondata a 2 decimali, e contiene il P&L non realizzato, che a posizioni aperte oscilla di ±$2-8/ora. $0,13/giorno di interesse ci sparisce.

Poi la fonte ufficiale Deribit ha spostato il problema dal rumore al calendario:

«Every day at 00:00 UTC, Deribit calculates the minimum equity of USDC that a user has been holding over the previous 24 hours. […] After the month is over, the rewards from each day are summed together and paid out as a single monthly payment early in the following month.» — insights.deribit.com/education/usdc-rewards-now-paid-on-deribit/

I reward USDC si pagano UNA VOLTA AL MESE, non ogni giorno come quelli USDE. Ecco perché non li avevamo mai visti: guardavamo a cadenza giornaliera, dove l'USDE si vede e l'USDC per costruzione no. E un accredito mensile da qualche dollaro si vede benissimo anche a 2 decimali — purché il libro sia FLAT, perché allora equity == balance == USDC e ogni scalino è un accredito.

La misura: due confini di mese, entrambi a libro flat

finestra	punti orari	equity min	equity max	ore senza alcun movimento	scalini >1 cent	reward atteso se idoneo
29/06 → 08/07	238	598,06	598,06	237 / 237	0	$0,45 (8 gg dal 23/06)
31/07 → 03/08	96	596,92	596,92	tutte	0	$1,72 (luglio intero)

Il secondo è il caso decisivo: $1,72 attesi contro una risoluzione di $0,01 — 172× — e l'equity non si muove di un centesimo per quattro giorni pieni, coprendo tutta la finestra "early in the following month". Non è un'assenza sotto la soglia di rilevabilità: è uno zero misurato.

⇒ Il conto NON riceve i reward USDC. N=2 confini indipendenti, entrambi puliti per costruzione.

Perché, e perché è coerente col fatto che l'USDE invece paga

Deribit: «A user's eligibility to receive USDC is based on their location». L'ipotesi che spiega entrambe le osservazioni è MiCA: USDC è un e-money token regolamentato, e a un residente UE non se ne può corrispondere rendimento; USDe non è un EMT, e infatti i suoi reward arrivano (li abbiamo visti per delta: +0,052055 · +0,061815 · +0,061821). ⚠️ Questa è la spiegazione plausibile, non una fonte normativa verificata (P13/M27: una norma citata si verifica come un numero). Il fatto misurato è lo zero, non il suo motivo.

Cosa cambia (e cosa la §6 aveva sbagliato)

• La premessa originale del gate USDE-01 è RESTAURATA. Il guadagno di tenere USDE non è lo spread 0,71 punti: è il tasso pieno ~4,1%, perché l'alternativa sul nostro conto rende 0. Sui $644 che teniamo: ~$26/anno (e ~$29 al ritmo misurato di ~4,5%), non i ~$4,6 di §6.
• Cosa avevo sbagliato, e la lezione. Ho letto apr: 3.4 in public/get_currencies e l'ho trattato come una proprietà del nostro conto. È una proprietà del venue: un listino, non un accredito. La conferma indiretta che invocavo ("i reward USDE misurati coincidono con la loro APR pubblicata") provava che il listino è reale per l'USDE, e non diceva nulla sull'idoneità dell'USDC. 📌 Un tasso pubblicato non è un tasso incassato: si verifica sul CONTO, e la verifica costava una query sulla serie che avevamo già. È N10 in una veste nuova — la verifica a €0 va fatta prima, e si fa sul venue, non sul sito; qui perfino il venue non bastava, serviva il conto.
• Resta vero e non toccato: il tetto del venue al 31,21%, il cuscino di regolamento (30% dell'equity, che lascia il 70%), e che a 31,2% l'evento emittente vale ~3,9× il maxDD del libro. La decisione "tenere o no i $644" cambia però di segno rispetto a come l'avevo chiusa: si compra $26/anno, non $4,6.

Strumento lasciato in piedi

scripts/live/balance_watch.py + scripts/cron_balance.sh (orario al minuto :42, libero fra :25/:35/:47; sola lettura). Registra il balance a 8 decimali per valuta — la serie che mancava — con il conteggio dei fill dall'ultimo campione e il nozionale lordo, così una finestra sporca si riconosce invece di essere mediata dentro. Etichetta PULITA le finestre a 0 fill e libro flat, dove il Δ USDC è l'interesse, e ne stampa l'APR implicita accanto a quella attesa. Serve a sorvegliare che lo zero resti zero (o che cambi, se l'idoneità cambia): l'inizio di settembre è il prossimo confine di mese, ed è già strumentato.

---

APPENDICE 2 (2026-08-31) — la fonte ufficiale: due correzioni alle mie conclusioni

L'operatore ha passato l'articolo support.deribit.com/.../Yield-reward-bearing-coins. WebFetch lo prende 403 (Cloudflare); si legge dall'API Help Center in JSON: support.deribit.com/api/v2/help_center/en-us/articles/31424939199261.json → HTTP 200. Aggiornato dal venue il 2026-08-20. Contiene tre cose che il progetto non sapeva.

1. L'ITALIA è nella lista degli esclusi dai reward USDC — e non è MiCA

«The following jurisdictions are not eligible to receive USDC rewards: Austria, Belarus, Belgium, Bulgaria, Canada, […] Italy, Japan, […]»

Lo zero misurato è confermato dalla fonte. Ma l'ipotesi che avevo scritto — MiCA, USDC è un e-money token e USDe no — è sbagliata: la lista contiene Canada e Giappone, non è il perimetro MiCA. È policy di giurisdizione di Deribit. M27: una fonte normativa citata si verifica come un numero — e io l'avevo dedotta invece di leggerla.

2. La finestra di pagamento è di DUE SETTIMANE, non di tre giorni — il «172×» era sovra-affermato

«The monthly USDC rewards payment is then made within the first two weeks of the following month.»

Avevo verificato su 29/06→08/07 e 31/07→03/08: 8 giorni su 14 e 3 su 14. Rifatto sulle finestre vere:

accredito	finestra vera	letture	escursione TOTALE equity	scalini ≥70% dell'atteso	esito
giugno ($0,45)	01→16/07	374	$2,74	7	❌ NON conclusivo
luglio ($1,72)	01→16/08	382	$0,48	0	✅ conclusivo

Luglio regge da solo: il credito atteso è 3,6× l'intera escursione dell'equity su due settimane. Giugno no — il libro ha iniziato a operare a metà mese e il rumore ha la taglia del segnale. ⇒ La conclusione non cambia (una finestra conclusiva + la lista ufficiale), ma l'evidenza è una finestra, non due. Avevo citato la sotto-finestra piatta e chiamato «zero misurato» ciò che la finestra completa non copriva: scegliere la sotto-finestra che fa vedere lo zero è la stessa mossa che il progetto vieta a un backtest.

3. Il tetto NON è un livello: è una FRAZIONE dell'equity, e scala col conto

L'articolo documenta un Cap ETHENA che diluisce il tasso a livello di exchange — User APR = min(min_exchange_USDe_balance, Ethena Cap) / min_exchange_USDe_balance × Ethena APR — e nessun limite sulle quantità detenibili da un conto. Quindi il muro non aveva base documentale, e andava ri-sondato. Fatto (31/08, giorno UTC nuovo → non è un limite giornaliero):

BUY   5              -> not_enough_funds_in_currency   USDE 644.175691   (muro ancora li')
SELL 10              -> OK                             USDE 634.175691
BUY  10              -> not_enough_funds_in_currency   USDE 634.175691   <-- ieri 644,18 passava!
BUY   5              -> OK                             USDE 639.175691
BUY   3              -> OK                             USDE 642.175691
BUY   1              -> OK                             USDE 643.175691
BUY   1              -> not_enough_funds_in_currency   USDE 643.175691

Ieri si tornava a 644,18 e oggi no, con l'equity scesa di $8. Il tetto si è mosso con lei:

	tetto	equity	frazione
30/08	[644,18 · 645,18)	$2.063,79	31,21% – 31,26%
31/08	[643,18 · 644,18)	$2.055,56	31,29% – 31,34%

I bracket distano 0,05pp, dentro il rumore dell'equity (±$2-8/ora). Candidato pulito 5/16 = 31,25%, ma con questa risoluzione non si distingue da una regola sul collaterale scontato dell'haircut (~29%): non si sceglie quella che conviene, si cita la banda (M25).

⇒ Il tetto SCALA col conto. La quota resta ~31% per sempre, il valore in dollari cresce col capitale, e il 70% non è raggiungibile né ora né mai. Conseguenza che ieri non avevo visto: essendo pinnati al tetto, il rischio emittente resta una frazione COSTANTE del conto — non si diluisce crescendo, a meno di vendere apposta.

4. E l'USDe ha un fee del 5% che non avevamo mai nominato

«Deribit Fee: A percentage deducted from the reward before distribution (currently 5%)» · reward su minima equity 00:00→24:00 UTC, distribuiti ~12:00 UTC, «visible inside Transaction Log» (che il gateway non espone: da lì il metodo per delta).

Il nostro misurato (~4,5%/anno) è già netto del fee: è quello che arriva sul conto, ed è l'unico numero da citare. La apr di get_currencies (4,1071%) è un listino, non un incasso — la stessa confusione che mi era costata la §6.

5. Cablato, così il tetto smette di vivere in prosa

Alla domanda dell'operatore «dove è scritto il valore del tetto» la risposta era: in tre note di testo e in nessun posto che il codice legga, tanto che usde_convert --quota 0.70 dichiarava «piano valido» per un ordine che il venue avrebbe rifiutato. Ora:

• config/live.json → usde.venue_cap_frac 0.312 (bordo BASSO dei bracket: fa fallire il piano prima dell'ordine invece che dopo il rifiuto) + venue_cap_misurato con la data;
• src/live/usde.py lo porta nei default — unica autorità, come tutto il resto della sezione (P1);
• usde_convert.piano() rifiuta il bersaglio sopra il tetto e stampa il massimo raggiungibile. Verificato: --quota 0.70 → «TETTO DEL VENUE: bersaglio $1.438,90 sopra $641,34 (31,2% dell'equity, misurato 2026-08-31)», nessun ordine inviato.

Stato finale: USDE 643,175691 (quota 31,29%, cioè al tetto), USDC $1.412,40, totale $2.055,57.