feat: VENUE WATCH — tripwire di fallimento exchange, cablato live

Risposta a "trova un sistema di protezione da fallimento exchange" SOTTO IL VINCOLO
della decisione appena presa (100% Deribit fino a $20k). Se non si puo' ridurre
l'ESPOSIZIONE, l'unica leva e' il TEMPO: il modello di rischio del mattino assumeva il
salto a zero istantaneo, ma i fallimenti reali non lo sono (Mt.Gox mesi, FTX ~72h, e
misurato qui: Bitfinex 2018-19 dislocato per 2.324 ore consecutive).

SEGNALE: un venue che gata i prelievi rompe l'ARBITRAGGIO -> il prezzo si stacca dal
consenso e ci resta. E' |scarto|, non il segno (Mt.Gox a premio, un venue in fuga a
sconto: stessa cosa). Consenso = venue USD indipendenti (Coinbase, Bitstamp), mai USDT.
Deribit sta a 3 bps dal consenso in mediana su 8 anni (65.043 ore BTC + 64.541 ETH).

TARATURA CONGELATA: 100 bps persistenti 4h a segno costante. Criterio DICHIARATO PRIMA,
perche' i due ovvi sbagliano in versi opposti (provati entrambi): "minimi bps" -> 25/24h
consuma 24 delle ~72h di FTX; "minime ore" -> 500/2h MANCA FTX (margine 0.6x). Regola:
zero falsi allarmi in 8 anni + margine >=3x sul caso storico piu' debole -> soglia
<=100bps -> poi minima latenza. Margine 3x FTX / 5x Quadriga / 10-20x Mt.Gox, zero falsi
allarmi con crash COVID, maggio 2021, LUNA e novembre 2022 inclusi.

CONTROLLO POSITIVO SUPERATO (un rilevatore tarato per non segnalare e' indistinguibile da
uno rotto): puntato su Bitfinex 2018-19 scatta 22 volte, episodio piu' lungo 2.324h a
+447bps. 22 dove il problema c'era, 0 su Deribit. E la durata risponde alla domanda vera:
un venue gated resta dislocato per settimane, quindi 4h di latenza sono trascurabili.

ECONOMIA: falso allarme = 0.248% atteso (flat 3g misurato sul book reale a ogni data
d'inizio); vero positivo = 100% salvato. Break-even p > (falsi/anno) x 0.00248: a 1 ogni
8 anni serve p > 0.031%. Il valore sta nella SPECIFICITA', non nella sensibilita'.

CABLATO: src/live/venue_watch.py (nucleo puro) + scripts/live/venue_watch.py, in
cron_book.sh PRIMA di book_execute (se Deribit e' in stress l'allarme deve partire anche
quando l'esecuzione fallisce per la stessa ragione). Tre stati OK/ALERT/BLIND — "non
vedo" non e' "va bene". ALLERTA, NON BLOCCA: l'azione e' prelevare (manuale; una chiave
con permesso di prelievo sarebbe essa stessa un rischio) e bloccare non protegge un saldo
che e' a rischio anche stando flat. Runbook pre-deciso nel docstring.

NON COPRE, e non e' un argomento per riaprire il 26/07: un fallimento SENZA finestra
(furto chiavi, sequestro, exit-scam) non lo prende nessun tripwire.

ERRORI CATTURATI IN SESSIONE:
- break-even calcolato sul p5 invece che sulla media (8.3x piu' severo, conclusione
  ribaltata);
- ipotesi meccanica sbagliata: credevo che i crash dislocassero a segno ALTERNATO. Falso,
  sono a segno costante anche loro (perp sotto spot per ore in cascata). A separare sono
  ampiezza e durata, non il segno;
- la prima corsa tronco' il campione da 8 anni a 29 GIORNI per un inner-join con Kraken
  (che serve solo ~700 candele) e la copertura era gia' stampata a video: una diagnostica
  stampata NON e' un controllo. Ora c'e' una guardia che ferma lo script. 2a occorrenza
  in un giorno dopo GTAA01;
- il controllo positivo era finito dentro il ramo `else` -> non girava mai, cioe'
  esattamente il difetto che doveva prevenire.

Book, pesi, config INVARIATI. 359 test verdi (+23).

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

CLAUDE.md

@@ -936,6 +936,59 @@ Prima ondata di ricerca onesta su BTC/ETH certificati (5 track, harness condivis
   presa su un asse solo va ricontrollata sugli altri prima di considerarla stabile; (d) quando una
   raccomandazione viene respinta con motivo, si registra **cosa e' stato accettato in cambio** —
   altrimenti la stessa analisi la ripropone fra tre mesi come se fosse nuova.
+- ✅ **VENUE WATCH — tripwire di fallimento exchange, CABLATO LIVE (2026-07-26).** Risposta alla
+  domanda *"trova un sistema di protezione da fallimento exchange"* **sotto il vincolo** della
+  decisione appena presa (100% Deribit fino a $20k): se non si puo' ridurre l'ESPOSIZIONE, l'unica
+  leva e' il **TEMPO**. Script `r0726_venue_tripwire.py` (segnale) + `r0726_venue_response.py`
+  (costo della risposta); produzione `src/live/venue_watch.py` + `scripts/live/venue_watch.py` in
+  `cron_book.sh`; test `tests/test_venue_watch.py` (23); diario `2026-07-26-venue-tripwire.md`.
+  **Book, pesi, config INVARIATI.**
+  (1) **Il segnale:** un venue che gata i prelievi **rompe l'arbitraggio** → il suo prezzo si stacca
+  dal consenso e ci RESTA. Il segnale e' **|scarto|, non il segno** (Mt.Gox andava a *premio*, un
+  venue in fuga a *sconto*: dicono la stessa cosa). Consenso = venue **USD indipendenti**
+  (Coinbase, Bitstamp); mai USDT (depeg 2022 → falsi allarmi giganti). Deribit sta a **3 bps** dal
+  consenso in mediana su 8 anni (65.043 ore BTC + 64.541 ETH) — fondo di rumore bassissimo, ed e'
+  cio' che rende possibile una soglia con margine.
+  (2) **Taratura CONGELATA = 100 bps persistenti 4h a segno costante.** Criterio **dichiarato
+  prima**, perche' i due ovvi sbagliano in versi opposti (provati entrambi): *minimi bps* → 25bps/24h
+  consuma 24 delle ~72h che diede FTX; *minime ore* → 500bps/2h **manca FTX** (margine 0.6x).
+  Regola adottata: (a) zero falsi allarmi su entrambi gli asset in 8 anni; (b) margine ≥3x sul caso
+  storico **piu' debole** (FTX ~300bps) → soglia ≤100bps; (c) a quei vincoli, minima latenza.
+  Margine finale **3x FTX / 5x QuadrigaCX / 10-20x Mt.Gox**, con **zero falsi allarmi** inclusi
+  crash COVID 2020-03, maggio 2021, LUNA e novembre 2022.
+  (3) ✅ **CONTROLLO POSITIVO superato** (obbligatorio: un rilevatore tarato per non segnalare e'
+  indistinguibile da uno rotto). Puntato su **Bitfinex 2018-19** (problemi bancari/Tether):
+  **22 episodi**, il piu' lungo **2.324 ore consecutive** a +447bps di picco, altri a 1.151h/+663bps
+  e 496h/+1136bps. **22 scatti dove il problema c'era, 0 su Deribit in 8 anni.** E la DURATA
+  risponde alla domanda vera: un venue gated resta dislocato per **settimane** → 4h di latenza
+  costano una frazione trascurabile del preavviso.
+  (4) **Economia della risposta:** costo ATTESO di un falso allarme (flat 3 giorni, misurato sul
+  book reale a ogni data d'inizio) = **0.248%** di equity (coda p5 −2.065%); guadagno di un vero
+  positivo = **100%**. Break-even: `p_annua > (falsi allarmi/anno) × 0.00248` → a 1 ogni 8 anni
+  serve **p > 0.031%**, a 12/anno servirebbe p > 2.97%. **Il valore sta nella SPECIFICITA', non
+  nella sensibilita'.** ⚠️ Errore mio corretto: il break-even si calcola sulla **media**, non sul
+  p5 (con la coda esce 8.3x piu' severo e la conclusione si ribalta).
+  (5) **Tre stati, e il terzo NON e' il primo:** `OK` / `ALERT` / **`BLIND`** (referenze
+  irraggiungibili o in disaccordo fra loro → dopo 12h e' un allarme suo). *"Non vedo" non e' "va
+  tutto bene"* — stessa lezione della contabilita' a 3 stati di `paper_dvolspread`. **ALLERTA, NON
+  BLOCCA:** l'azione a un vero positivo e' *prelevare* (manuale — una chiave API con permesso di
+  prelievo sarebbe essa stessa un rischio), e bloccare non protegge il saldo, che e' a rischio
+  anche stando flat. **Runbook pre-deciso** nel docstring del modulo (escludere guasto referenze →
+  `public/status` → **prelievo di prova**, unica evidenza diretta → flat + prelievo totale).
+  (6) ⚠️ **Cio' che NON copre, e non e' un argomento per riaprire il 26/07:** un fallimento **senza
+  finestra** (furto di chiavi, sequestro, exit-scam notturno) non lo prende nessun tripwire; quella
+  parte di `p` resta scoperta e la sola difesa e' lo split. E il preavviso di 200-2.300 ore viene da
+  **un** caso osservato: e' un'ancora, non una distribuzione.
+  **REGOLE:** (a) un rilevatore tarato per non segnalare va validato su un **controllo positivo**;
+  (b) una soglia si sceglie con un criterio **dichiarato prima** (i criteri ovvi sbagliano in versi
+  opposti); (c) la persistenza richiesta **e' latenza** e va confrontata con la durata del fenomeno
+  da rilevare; (d) un break-even si calcola sulla **media**, non sulla coda; (e) ⚠️ **una
+  diagnostica STAMPATA non e' un controllo** — la prima corsa tronco' il campione da 8 anni a
+  **29 giorni** per un inner-join con Kraken (che serve solo ~700 candele) e la copertura era gia'
+  a video: ora c'e' una guardia che ferma lo script (2ª occorrenza in un giorno dopo GTAA01 —
+  **l'outer-join con referenze di lunghezza diversa e' una trappola ricorrente**); (f) un controllo
+  positivo finito dentro il ramo `else` **non gira mai** (trovato in sessione: era esattamente il
+  difetto che doveva prevenire).
 - 📅 **NUOVO SCHEMA FEE DERIBIT dal 2026-08-01 — misurata la CURVA, nessuna azione oggi
   (2026-07-26).** Script `r0726_fee_sensitivity.py`, test `tests/test_fee_sensitivity.py` (6),
   diario `2026-07-26-fee-deribit.md`. **Book/pesi/cron/config INVARIATI.**