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.