PythagorasGoal/docs/diary/2026-08-31b-venue-news-annunci.md

2026-08-31 — Fine della Proof of Reserves, e il guardiano che mancava

L'operatore ha passato l'annuncio Deribit to Discontinue Daily Proof of Reserves Publication. La notizia in sé vale poco per noi. Quello che è emerso cercandola vale molto di più.

1. La notizia: frequenza giù, sostanza su, per noi nulla cambia

Dal 1 settembre 2026 la pagina Proof of Reserves sparisce e gli aggiornamenti quotidiani cessano. Al loro posto, sotto il regime VARA di Dubai: audit annuale indipendente delle riserve, audit annuale del bilancio, obbligo di copertura 100% e segregazione degli attivi dei clienti. E: «approximately 90% of client assets have been migrated to Coinbase, which acts as a custodian for Deribit».

Non è un peggioramento netto, ed è importante non raccontarlo come tale. Si perde un segnale ad alta frequenza e debole (una PoR auto-pubblicata prova che gli attivi esistono in un istante, non che coprano le passività, ed è aggirabile attorno allo snapshot) e si guadagna un segnale a bassa frequenza e più forte (audit indipendente obbligatorio invece di pubblicazione volontaria), più un miglioramento sostanziale di custodia: 90% degli attivi presso un custode terzo regolato invece che nei wallet dell'exchange.

Per noi non cambia nulla di operativo, e per una ragione che va detta: la PoR non l'abbiamo mai sorvegliata. Zero occorrenze in tutto il codice. venue_probe legge se il venue risponde, non cosa dichiara. Si perde un segnale che non stavamo usando.

Ho provato a catturare l'ultimo dato prima che la pagina sparisse — è la mossa giusta per un dato non ricostruibile con una scadenza. Rinunciato di proposito: la pagina è una SPA e get_proof_of_reserves non esiste come metodo API («Method not found»), ma soprattutto uno snapshot singolo e auto-riportato non regge lo standard di prova di questo progetto e non permetterebbe comunque di stimare p. Un dato che non cambierebbe una decisione non vale il lavoro per prenderlo.

2. 📌 La conseguenza vera: il riapritore della decisione più grande si è ristretto

La decisione vincolante «100% Deribit fino a $20k» (26/07) ha come riapritori dichiarati: «$20k, o un cambio di piano, o p che diventa stimabile invece che assunto».

Dal 1 settembre il segnale pubblico di solvibilità passa da quotidiano ad annuale. Il terzo riapritore non è formalmente chiuso — un audit indipendente è semmai evidenza più forte — ma diventa praticamente irraggiungibile: da una serie giornaliera si può costruire una stima, da un punto all'anno no. ⇒ In pratica quella decisione è ora gated SOLO dal capitale: si riapre a $20k, o non si riapre. Non cambia la decisione di oggi (fu presa con p esplicitamente assunto, non osservato), ma chiude l'unica uscita non-capitale che aveva.

3. 🚨 Quello che ho trovato cercando: quattro annunci materiali che nessuno leggeva

Il debito #8 dice, testuale: «Resta scoperto il Rulebook vero e proprio: la sonda legge se il venue RISPONDE, non cosa il venue ANNUNCIA». Esiste un feed RSS pubblico (insights.deribit.com/exchange-updates/feed/) con 10 voci. Alla prima lettura:

data	annuncio	perché ci tocca
27/08	Discontinue Daily Proof of Reserves	§1 e §2 di questo diario
14/08	Contract Specifications change for Linear USDC Perpetuals	i nostri due strumenti
05/08	New SM Margin Model On Deribit	leva per taglia, tiered
31/07	USDC Rewards Available In More Countries	tocca una conclusione viva
29/06	New Fee Schedule On Deribit	fee_watch esiste per questo

Il caso che decide la questione è il 14/08. Le specifiche dei perpetual USDC sono cambiate il 18/08; l'annuncio è del 14/08. Il codice lo racconta già con onestà: la tabella «non se n'era accorta […] è andata bene per la direzione del cambiamento, non perché ce ne fossimo accorti» — i cambi erano riduzioni (tick BTC 0,5→0,1, ETH 0,05→0,01, min/step ETH 0,001→0,0001) e un valore più grosso resta conforme. check_specs() è nato da quella svista e oggi gira ogni ora. Ma rileva la deriva dopo; il feed l'avrebbe detta quattro giorni prima. Il giorno che Deribit ALZA un minimo, «dopo» significa ordini rifiutati.

Il 31/07 chiude un cerchio aperto ieri: l'espansione delle giurisdizioni idonee ai reward USDC non contiene l'Italia, né alcun paese UE — mentre San Marino e Città del Vaticano (i due microstati europei fuori dall'UE) sono idonei. La lista che avevo letto (aggiornata 20/08) è posteriore all'espansione: la conclusione dello zero USDC è confermata due volte. Il pattern UE-fuori/microstati-dentro suggerisce un driver regolatorio, ma la lista contiene anche Canada e Giappone: non asserisco una causa, il fatto è l'esclusione.

4. Costruito: venue_news.py

Sorveglianza giornaliera del feed, dentro cron_daily.sh accanto a fee_watch (suo parente stretto). Scelte che contano:

• NON interpreta. Dice «è uscito questo, guardalo». Nessun automatismo su un testo di marketing: P13 — una guardia sui NUMERI non copre il RAGIONAMENTO, e la prosa si legge come opinione di un lettore fallibile. L'unica cosa che classifica è l'urgenza.
• Le parole-chiave sono DERIVATE, non ridichiarate (P1, il difetto più ricorrente del progetto): gli strumenti vengono da deribit._CONTRACT, la valuta di collaterale da config/live.json. Chi aggiunge un asset al book allarga la sorveglianza senza toccare questo file — ed è esattamente il test che lo blinda.
• Primo giro semina senza allertare (P9: l'allarme massimo non si spende per un arretrato di 10 voci, o non verrà letto il giorno che è vero).
• Feed illeggibile → codice 2 e nessun silenzio implicito (P5: «non vedo» non è «niente di nuovo»).

5 test sulle funzioni pure. La rete no: scarica() ritorna None su qualunque errore, ed è quello il contratto.

Cosa NON copre, e va detto: il Rulebook vero e proprio (ADL, perdita socializzata, emergency powers, conti dormienti) non ha un feed. Il debito #8 si restringe, non si chiude.

---

5. La Knowledge Base risponde a due domande aperte — e corregge due cose mie

L'operatore ha passato anche yield-generating-collateral-usde-buidl-and-more, che non documenta tetti né haircut ma rimanda alla Knowledge Base. Interrogata via API Zendesk (support.deribit.com/api/v2/help_center/articles/search.json), l'articolo giusto è «Cross collateral specifications» (aggiornato 2026-02-20).

(a) 🚨 Il costo del saldo negativo: 0,05% al GIORNO

«While the equity of a currency in an account remains negative, a collateral fee will be charged to that account. This fee is charged daily in the same currency as the negative balance (default = 0.05% per day). The fee is charged based on the amount of time the negative equity is held, down to a granularity of seconds.»

18,25% annuo, cioè 4,3× la resa USDE che si starebbe comprando tenendo meno USDC. Il 30/08 avevo scritto «Deribit lo finanzia a interesse» senza il numero — l'affermazione era giusta e vuota. Con il numero il criterio del cuscino di regolamento smette di essere prudenza e diventa aritmetica: scendere sotto il cuscino per tenere più USDE è −14 punti.

E il ribilanciamento automatico non salva: scatta solo oltre $1.000.000 assoluti o il 100% della cross equity (default tabulati), soglie che a $2k non si toccano mai. Non veniamo ribilanciati: sanguiniamo la fee. La cosa che sembrava un paracadute è, alla nostra taglia, esattamente l'assenza di un paracadute.

(b) 🚨 Haircut USDe: la fonte dice 5%, noi abbiamo registrato 10%

valuta	haircut X:PM	X:SM
BTC · ETH · USDC	—	—
USDT · USYC · BUIDL	2%	2%
PAXG	2,5%	5%
USDe	5%	5%
stETH	7,5%	7,5%
SOL	—	15%

config/live.json dice haircut: 0.10, e il diario del 26/08 lo dà per «verificato sul venue» senza lasciare traccia di come. L'articolo è anteriore a quella data, quindi non si sa quale delle due sia stale.

Non l'ho riparato (P12: fra due fonti che non concordano, una riparazione silenziosa è un'invenzione; M28: la contraddizione è informazione). Si tiene 0,10 per tre ragioni dichiarate: è il lato conservativo (sottostima il margine utilizzabile), non è sul percorso soldi (non entra nel sizing — lo usa solo il report di usde_watch), ed è già misurato che non morde a nessuna quota fino al 90%. Si chiude leggendo la pagina margini del conto, che è dove Deribit stesso dice di guardare.

(c) Un dato di lato che vale per il futuro

BUIDL ha haircut 2% — sarebbe stato il miglior collaterale a rendimento del listino (contro il 5% dell'USDe), se solo lo si potesse comprare. E stETH 7,5%, il peggiore: terza ragione indipendente per lasciarlo stare, dopo il tasso dimezzato e l'esposizione ETH.

📌 Nessuna delle due fonti documenta un tetto sulle quantità detenibili. Il ~31,2% sull'USDE resta misurato e non spiegato — e ora si sa che non è una svista di lettura: non è scritto da nessuna parte.

(d) Tentata la chiusura della divergenza sull'haircut: non è raggiungibile da qui

Deribit dice: «Haircut rates can be seen on the margin page in your account». Quella pagina è web UI, e le credenziali vivono solo dentro il gateway (debito #11). Provato comunque:

• account_summary per la valuta USD (la "riga USD" che il doc menziona) → Invalid currency;
• parametro extended (che su Deribit apre i dettagli di margine) → ignorato;
• il gateway filtra a 8 campi: niente initial_margin, niente maintenance_margin.

E non è che si sia guardato nel secchio sbagliato — la contabilità torna esatta senza haircut:

USDC  equity 1412.281074  available 1400.728093   riservato  11.5530
USDE  equity  643.175691  available  643.175691   riservato   0.0000
posizioni lorde $577.65

riservato in USDC ........... $11.5530
IM di posizione al 2% ....... $11.5530
RESIDUO ..................... $-0.0000

Un haircut al 5% chiederebbe $32,16 accantonati, al 10% ne chiederebbe $64,32: non ci sono, e il secchio USDE riserva 0.000000. ⇒ L'haircut non è osservabile in alcun campo esposto. O è applicato solo nella vista cross/USD che il gateway filtra via, o non è applicato al nostro conto: da qui le due cose non si distinguono, e non le si sceglie tirando a indovinare.

La divergenza resta APERTA, ma ora con la ragione misurata invece che supposta. La chiudono due cose, entrambe dell'operatore: 30 secondi sulla pagina margini della web UI, oppure delle chiavi API Deribit — che è la decisione già dichiarata nel debito #11, non un refactor. Nel frattempo non morde nulla di osservabile: l'IM è il 2% del nozionale e il valore pieno dell'USDE resta disponibile, quindi 5% o 10% non cambia una singola cifra operativa.

📌 Sottoprodotto non cercato: $11,5530 / $577,65 = 2,0000% = esattamente 1/50. È il C1 = 50 (start leverage, tier 1) del nuovo modello di margine SM annunciato il 05/08 — quello che venue_news ha appena tirato fuori dal feed. Confermato sul nostro conto senza averlo cercato, ed è la prima volta che un annuncio del venue viene verificato contro il conto invece che creduto.

(e) L'operatore dichiara: il conto è Standard Margin — due conferme incrociate

Lo screenshot della pagina margini non è arrivato fin qui (sta sul desktop dell'operatore, non sulla VPS: il percorso non esiste su questa macchina). Ma il fatto dichiarato — «è attivo Standard margin» — aggancia due cose che erano sospese:

1. Quale colonna leggere. La tabella KB ha Haircut (X:PM) e Haircut (X:SM). Il conto è X:SM, quindi vale la seconda — che per USDe dice 5%, come la PM. La divergenza col nostro 0.10 resta quindi intatta, ma ora si sa con certezza quale numero ufficiale la contraddice, invece di doverne scegliere uno fra due colonne.
2. Perché l'IM misurata era esattamente 1/50. Il nuovo modello di margine del 05/08 si applica, testuale, ai «standard margin accounts». Il conto è standard margin, e noi abbiamo misurato IM = 2,0000% del nozionale = 1/50 = il C1 = 50 di tier 1. Le due cose si confermano a vicenda: un fatto dichiarato dall'operatore e una misura fatta sul conto senza conoscerlo.

Vale la pena notarlo perché è raro: in tutta questa settimana ogni affermazione pubblicata dal venue si è rivelata falsa per il nostro conto (APR USDC, «all users can buy BUIDL»). Questa è la prima che il conto conferma.

Cosa manca ancora, e resta l'unica cosa che chiude la divergenza: il numero di haircut per USDe mostrato sulla pagina Standard Margin del conto. Se dice 5%, la nostra config è stale e il 26/08 registrò male; se dice 10%, la KB è stale e la config ha ragione. Finché non c'è, si tiene 0.10 — lato conservativo, fuori dal percorso soldi, e senza un solo effetto operativo misurabile.

---

6. La pagina margini arriva davvero — e la seconda cosa che dice vale più della prima

Lo screenshot era su Wasabi (rclone remote wasabi:, bucket adp-work, cartella _scambio), non sulla VPS: per questo il percorso non esisteva. Scaricato e letto. Riconciliazione riproducibile in scripts/research/r0831_margini_conto.py (N11).

(a) ✅ Haircut = 5%. La nostra config aveva torto.

La pagina non espone l'haircut come numero: si ricava per differenza, perché il modello CROSS conta l'USDE scontato e il SEGREGATO non lo conta affatto.

S:SM (attivo)   USDC Available 1,400.86   ·  USDC equity 1,412.28 − IM 11.55 = 1,400.73  (scarto $0.13)
X:SM            CROSS Available 2,011.73
contributo USDE al cross = 2,011.73 − (1,412.28 + 0.20 − 11.55) = $610.81  su $643.05 di valore
  → haircut implicito 5,0137%
     ipotesi  5% (KB)     → atteso $610.89   scarto $ 0.09   ✅
     ipotesi 10% (nostra) → atteso $578.74   scarto $32.06   ❌

config/live.json passa da 0.10 a 0.05. Il 26/08 il 10% fu registrato come «verificato sul venue» senza lasciare traccia di come, e non lo era. Una nota di provenienza che dice «verificato» senza dire con quale lettura non è provenienza: è la stessa parola usata come garanzia.

(b) 🚨 Il conto non è cross-collateral. È Segregated: Standard Margin.

Lo dice la schermata in cima — Current status: Segregated: Standard Margin — e la tabella del modello attivo elenca BTC, ETH, USDC. L'USDE non c'è.

⇒ L'USDE non fa margine per i perp USDC-settled del book, e l'haircut oggi non si applica affatto. Il che spiega, a posteriori e in modo pulito, perché la misura di stamattina trovava $0,0000 accantonati: non stavo guardando nel secchio sbagliato, stavo cercando un parametro che sul nostro conto non è in vigore.

NON MORDE, e va detto subito per non allarmare: al massimo lordo del libro (1,0x ≈ $2.056 di nozionale) l'IM sarebbe ~$41 contro $1.400 di USDC disponibile — 34× di copertura. Nessuna decisione operativa cambia oggi.

Ma la premessa scritta in CLAUDE.md era falsa, e il modo in cui era falsa è istruttivo. Diceva: «l'equity del book è il TOTALE cross-collateral». Sono due cose diverse messe sotto un nome solo:

• come ricchezza, sommare USDC+USDE è giusto — ed era il punto della riparazione del 26/08, che evitò il falso «USCITA DI FONDI −24%» e una vendita indesiderata;
• come capacità di margine, è sbagliato: nel modello attivo l'USDE vale zero.

Finché il margine non morde le due coincidono nell'uso, e infatti non è mai emerso. Un errore che non ha conseguenze finché una terza cosa resta vera è un debito, non un'assoluzione. Corretto in CLAUDE.md, e corretta anche la riga di usde_watch che stampava «margine utilizzabile ~$2.013 (haircut 10%)»: era falsa due volte insieme.

(c) Come cambia il modo di pensare alla quota USDE

Non è «collaterale diversificato»: è cassa messa da parte a rendimento, fuori dal sistema di margine. Il che rende il tetto del venue al ~31,2% meno una limitazione e più un caso fortunato — tiene automaticamente dentro al 31% la parte di conto che non lavora come margine.

E apre una decisione dell'operatore, non mia: passare a X:SM aggiungerebbe $610,87 di margine utilizzabile, ma porta con sé la meccanica cross — collateral fee 0,05%/giorno sul saldo negativo e ribilanciamento automatico. Oggi non serve (34× di copertura); servirebbe solo a leve che non sono autorizzate.

📌 Ipotesi nuova sul tetto del ~31,2%, non verificata: potrebbe dipendere proprio dal modello segregato. Si saprebbe passando a X:SM e ri-sondando — un esperimento che ora ha un senso, dove prima non si sapeva nemmeno cosa variare.

---

7. Passaggio a X:SM e ri-sondaggio del tetto — l'ipotesi regge tecnicamente e cade in pratica

L'operatore è passato a Cross: Standard Margin e ha chiesto di ri-sondare, per verificare l'ipotesi lasciata aperta in §6(c): il tetto del ~31,2% dipende dal modello segregato?

Il passaggio è verificabile dal gateway, senza fidarsi di una dichiarazione

available_funds USDC è passato da ~$1.400 a $2.011,09, contro $2.010,90 attesi sommando l'USDE scontato al 5% — scarto $0,19. È anche la seconda conferma indipendente dell'haircut al 5%, da una lettura completamente diversa dallo screenshot: due strade, stesso numero.

Il risultato

modello	tetto misurato	equity	frazione
Segregato S:SM (31/08)	[643,18 – 644,18)	$2.055,56	31,29% – 31,34%
Cross X:SM (31/08, dopo)	[654,18 – 655,18)	$2.054,90	31,84% – 31,88%

+0,55pp = +11 USDE ≈ $11. ⇒ L'ipotesi è vera e inutile: il modello di margine entra nel tetto, ma non lo spiega. Per arrivare al 70% mancano ancora ~38 punti, un fattore 2,2×. Un'ipotesi confermata al terzo decimale e falsa all'ordine di grandezza va archiviata come falsa: il tetto resta misurato e non spiegato.

🚨 La lezione di metodo, che vale più del risultato

Il primo probe fu un BUY 20, rifiutato. Da solo avrebbe chiuso la questione con "tetto invariato, l'ipotesi è refutata" — e sarebbe stato falso. Il tetto si era mosso di 11, cioè meno della taglia del probe. È stato il test a saldo neutro con passi piccoli (BUY 1 → SELL 10 → BUY 10 → BUY 1, tutti accettati) a rivelarlo.

📌 Un probe unico di taglia sbagliata produce un falso negativo che si legge come risultato. La taglia del sondaggio va scelta sulla risoluzione dell'effetto che si cerca, non su ciò che è comodo — ed è M13 in una veste nuova: un criterio si misura sulla sua risoluzione prima che sul suo esito.

Cosa ha comprato il passaggio, e cosa è costato

• Comprato: $611 di margine utilizzabile — inutile a 0,28x di leva, serve solo sopra ~1,4x che non è autorizzata — più $11 di capienza sul tetto.
• Costato: sotto segregato l'USDE era ring-fenced dalle perdite del libro (solo il silo USDC rispondeva delle posizioni); sotto cross risponde l'intero conto. Non morde oggi (perdita massima plausibile ~$617 col disaster-SL, dentro il solo USDC), ma il rischio strutturale ha cambiato verso. Se un giorno il cross non servisse più, tornare a S:SM ri-recinta l'USDE.

config: venue_cap_frac 0.312 → 0.318 (bordo basso del bracket CROSS, che è il modello attivo). Se si torna a S:SM va rimesso a 0.312.

8. X:PM valutato e SCARTATO — la risposta era già nello screenshot

L'operatore ha chiesto di provare Cross: Portfolio Margin. Non serve provarlo: il confronto è nella schermata di §6.

modello	Available Balance	IM	MM
X:SM (attivo)	$2.011,73	2,13%	0,37%
X:PM	$1.935,14	5,85%	3,43%

Sulla colonna il cui significato è inequivocabile — stessa riga, stesse unità — X:PM dà $76,59 di collaterale utilizzabile in MENO, e chiede più margine. ⚠️ La frase «su entrambe le misure» è stata corretta in §9: l'«IM %» stampata dalla pagina non è il margine delle posizioni. La conclusione non cambia — migliora.

Perché, ed è strutturale e non contingente: il Portfolio Margin è basato su scenari di rischio e premia i portafogli in cui il rischio si compensa, tipicamente i book di opzioni. Il nostro è due long direzionali nudi senza nulla che compensi — il caso peggiore per PM, che addebita lo scenario di stress invece di un'aliquota piatta.

La riga che decide è la MM: 3,43% contro 0,37%, ~9×. Il maintenance margin è ciò che innesca la liquidazione: non morde a 0,28x, ma sposta il punto di liquidazione molto più vicino su un libro con soldi veri. E il beneficio atteso sul tetto è noto per analogia: il salto S:SM→X:SM ne ha comprato $11.

⇒ SCARTATO. ⚠️ Non "PM è peggio", ma "PM è peggio PER QUESTO portafoglio": cosa lo riapre — il giorno che VRP01 o un altro sleeve di opzioni entra in deploy, il rischio inizia a compensarsi e quel confronto cambia di segno. Va rifatto allora, non prima.

---

9. X:SM attivo: la pagina si ricostruisce dal gateway — e una mia lettura era sbagliata

L'operatore ha incollato la riga CROSS col modello attivo invece che proiettato: Available $2.010,81 · IM 2,15% · MM 0,37%. Il gateway, letto allo stesso minuto (08:34Z), dice available_funds = 2010,82299383. Scarto $0,01.

(a) Lo screenshot non serve più

⇒ La riga CROSS della pagina È available_funds, che leggiamo da soli a ogni giro. Ieri quella schermata era l'unica fonte per l'haircut e per il modello attivo, e per averla è servito un passaggio dall'operatore e da Wasabi. Oggi non serve a niente: r0831_margini_conto.live() la ricostruisce.

(b) Terza conferma del 5%, e la prima ESATTA

1.400,71 + 0,95 × 654,176 + 0,20 dust − 11,553 IM = $2.010,82     pagina $2.010,81

Scarto $0,007. E il 10% della vecchia config non è improbabile: invertendo la stessa riga dà IM = −$21,16, cioè aritmeticamente impossibile. Le tre strade — differenza fra le righe della pagina (31/08 07:50), salto di available_funds al passaggio S:SM→X:SM ($0,19), e ora questa ricostruzione al centesimo — sono indipendenti e danno lo stesso numero.

(c) 🚨 L'«IM %» della pagina NON è il margine delle posizioni — mia lettura sbagliata

(margin_balance − available)/margin_balance = 2,1532%, ed è esattamente ciò che la pagina stampa come «IM 2,15%». Ma si scompone così:

voce	USD	% di margin_balance
haircut sull'USDE (5% × 654,18)	$32,71	1,592%
IM vera delle due posizioni	$11,55	0,562%
totale riservato	$44,26	2,153%

⇒ il 74% di quella percentuale è haircut, non rischio. È salita da 2,13% a 2,15% perché abbiamo comprato collaterale a rendimento — cioè per un motivo che con l'esposizione del libro non c'entra nulla. Letta come misura di rischio direbbe che ieri sera abbiamo alzato la leva comprando USDE: l'opposto di quello che è successo.

La MM invece è pulita: 0,37% = $7,60, e non può contenere l'haircut ($32,71 da solo la renderebbe negativa). Le due colonne hanno basi diverse, e la pagina non lo dice.

📌 Regola: una percentuale letta da una schermata va invertita nella sua definizione prima di essere confrontata. Due colonne affiancate, con la stessa unità e lo stesso aspetto, possono avere denominatori — e qui numeratori — diversi. È P7 su una superficie nuova: un numero si etichetta con la sua configurazione, e una pagina del venue non è obbligata a farlo per noi.

(d) La decisione su X:PM esce RAFFORZATA

La KB dà USDe al 5% sotto entrambi i modelli (§6b): nel confronto l'haircut si cancella, e l'inversa restituisce il margine di posizione puro sulle stesse due posizioni, stesso istante:

modello	available	IM di posizione
X:SM	$2.011,73	$11,64
X:PM	$1.935,14	$88,23

PM chiede 7,6× il margine iniziale e 9,3× la MM. Due misure ora pulite, stesso verso: la bocciatura di §8 regge, meglio fondata di quando l'ho scritta.

E c'è una conferma che ieri mancava: la riga X:SM era una proiezione di un modello inattivo, e oggi che è attivo la stessa aritmetica la riproduce al centesimo. ⇒ anche la riga X:PM, che resta una proiezione, è affidabile: la decisione presa senza provare il modello era presa su un numero buono. Non provare X:PM è stato corretto, e ora si sa perché e non solo che.