usde: l'USDC NON frutta sul nostro conto — misurato, e §6 di stasera era sbagliata

Domanda dell'operatore: "verifica se l'USDC frutta davvero sul nostro conto".

Sembrava dover aspettare: il gateway non espone il Transaction Log
(get_transaction_log, get_settlement_history, get_deposits, get_transfers,
get_interest_history: tutti 404 — debito #11) e l'unica serie storica e'
trades.db.equity, oraria ma arrotondata a 2 decimali e sporcata dal P&L non
realizzato (+-$2-8/ora a posizioni aperte), dove $0,13/giorno sparisce.

La fonte ufficiale Deribit ha spostato il problema dal rumore al calendario: i
reward USDC si pagano UNA VOLTA AL MESE ("paid out as a single monthly payment
early in the following month"), accrual alle 00:00 UTC sulla minima equity —
non ogni giorno come l'USDE. Ecco perche' una sorveglianza giornaliera non
poteva vederli. E un accredito mensile da qualche dollaro si vede benissimo
anche a 2 decimali, purche' il libro sia FLAT: allora equity == balance == USDC
e ogni scalino e' un accredito.

MISURA, due confini di mese entrambi a libro flat:
  29/06 -> 08/07  equity 598,06 costante, 237/237 ore ferme, 0 scalini  (attesi $0,45)
  31/07 -> 03/08  equity 596,92 costante per 4 giorni pieni             (attesi $1,72)
Il secondo e' decisivo: $1,72 contro una risoluzione di $0,01, 172x. Zero
MISURATO, non zero sotto soglia.

=> La premessa originale del gate USDE-01 e' RESTAURATA: il guadagno di tenere
USDE e' il tasso pieno ~4,1%, non lo spread 0,71 punti che avevo scritto poche
ore fa. Sui $644: ~$26/anno, non ~$4,6.

Cosa avevo sbagliato: ho letto `apr: 3.4` in public/get_currencies e l'ho
trattato come una proprieta' del NOSTRO CONTO. Era un listino del VENUE. La
"conferma indiretta" che invocavo provava che il listino e' reale per l'USDE e
non diceva nulla sull'idoneita' dell'USDC. Un tasso pubblicato non e' un tasso
incassato: si verifica sul conto — ed e' costato una query su una serie che
avevamo gia'.

Esclusione plausibile ma NON verificata: MiCA (USDC e' e-money token, USDe no);
Deribit dice solo "eligibility is based on their location". Il fatto misurato
e' lo zero, non il suo motivo.

Nuovo: 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 — col conteggio dei fill dall'ultimo
campione e il nozionale lordo, cosi' una finestra sporca si riconosce invece di
essere mediata dentro. Etichetta PULITA le finestre a 0 fill e libro flat, dove
il delta USDC E' l'interesse, e ne stampa l'APR implicita.

Suite: 795 passati. L'ERROR di teardown e' il falso positivo dichiarato dalla
guardia stessa: il cron :47 ha scritto un fill reale (ETH BUY $+9, 23:47:19)
mentre la suite girava.

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

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

@@ -135,3 +135,79 @@ non un reward osservato.
   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.