usde: il tetto e' una FRAZIONE dell'equity (~31,2%), non un livello — e ora e' in config

Fonte: articolo ufficiale Deribit "Yield/reward bearing coins" (WebFetch lo prende
403, si legge dall'API Help Center in JSON). Tre correzioni alle conclusioni di
ieri.

1) L'ITALIA e' nella lista delle giurisdizioni escluse dai reward USDC. Lo zero
misurato e' confermato dalla fonte, ma la mia ipotesi MiCA era SBAGLIATA: la
lista contiene Canada e Giappone, non e' il perimetro MiCA. E' policy di
giurisdizione Deribit. M27: una fonte normativa si verifica, non si deduce.

2) La finestra di pagamento USDC e' di DUE SETTIMANE ("within the first two
weeks of the following month"), non tre giorni. Avevo verificato su 8/14 e 3/14
giorni. Rifatto sulle finestre vere: LUGLIO conclusivo (atteso $1,72 contro
un'escursione TOTALE dell'equity di $0,48 in 1-16/08, zero scalini compatibili),
GIUGNO no (il libro opera da meta' mese, rumore della taglia del segnale). La
conclusione non cambia, ma l'evidenza e' UNA finestra piu' la lista ufficiale,
non due: il "172x" del 30/08 era sovra-affermato.

3) IL TETTO NON E' UN LIVELLO, E' UNA FRAZIONE. L'articolo documenta un Cap
ETHENA che diluisce il TASSO a livello di exchange e nessun limite sulle
quantita' detenibili: il muro non aveva base documentale e andava ri-sondato.
Fatto il 31/08 (giorno UTC nuovo -> non e' un limite giornaliero): ieri si
tornava a 644,18, oggi no, con l'equity scesa di $8.
    30/08  tetto [644,18 · 645,18)  equity $2.063,79  = 31,21-31,26%
    31/08  tetto [643,18 · 644,18)  equity $2.055,56  = 31,29-31,34%
0,05pp di scarto, dentro il rumore dell'equity (+-$2-8/ora). Candidato pulito
5/16 = 31,25%, ma a questa risoluzione non si distingue da una regola sul
collaterale scontato dell'haircut (~29%): si cita la banda (M25).
=> Il tetto SCALA col conto: la quota resta ~31%, il valore in dollari cresce
col capitale, il 70% non e' raggiungibile ne' ora ne' mai. E, essendo pinnati
al tetto, il rischio emittente resta una frazione COSTANTE del conto.

Cablato (rispondeva a "dove e' scritto il valore del tetto": in tre note di
testo e in nessun posto che il codice leggesse, tanto che usde_convert --quota
0.70 dichiarava "piano valido" per un ordine che il venue rifiuta):
  - config/live.json usde.venue_cap_frac 0.312 + venue_cap_misurato
  - src/live/usde.py lo porta nei default (unica autorita', P1)
  - usde_convert.piano() rifiuta il bersaglio sopra il tetto PRIMA di sparare
    e stampa il massimo raggiungibile. Verificato su entrambi i rami.

Anche: l'USDe ha un fee Deribit del 5% mai nominato prima. Il nostro misurato
(~4,5%/anno) e' gia' netto: e' l'unico numero da citare.

Stato: USDE 643,175691 (31,29%, al tetto), USDC $1.412,40, totale $2.055,57.
Suite: 795 passati.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

@@ -211,3 +211,101 @@ sporca si riconosce invece di essere mediata dentro. Etichetta PULITA le finestr
 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.