PythagorasGoal/docs/diary/2026-07-26-venue-tripwire.md

2026-07-26 — Un sistema di protezione dal fallimento exchange, a capitale concentrato

Richiesta: "trova un sistema di protezione da fallimento exchange" — subito dopo la decisione di restare 100% su Deribit fino a $20k.

Il vincolo e' quello che rende il problema interessante: la riduzione dell'esposizione e' fuori discussione. Lo split di venue e' stato valutato e rifiutato con motivo (§5 del diario 2026-07-26-venue-risk.md). Quindi non si puo' ridurre quanto si perde: si puo' solo ridurre la probabilita' di essere ancora dentro quando succede.

Script: r0726_venue_tripwire.py (il segnale), r0726_venue_response.py (il costo di rispondere). Produzione: src/live/venue_watch.py + scripts/live/venue_watch.py, cablato in cron_book.sh. Test: tests/test_venue_watch.py (23). Book, pesi, config: INVARIATI.

---

0. L'idea in una riga

Il modello di rischio del mattino assumeva il salto a zero istantaneo. I fallimenti reali non lo sono: Mt.Gox gato' i prelievi per mesi, FTX ebbe ~72 ore, e — misurato qui — Bitfinex nel 2018-19 resto' dislocato dal consenso per 2.324 ore consecutive. Se dentro quella finestra il saldo esce, la perdita non e' totale. Il sistema e' quindi un rilevatore di finestra, non una riduzione di esposizione.

1. Il segnale, e perche' e' falsificabile

Quando un exchange gata i prelievi l'arbitraggio si rompe: non si puo' piu' comprare li' e vendere altrove per chiudere lo scarto, quindi il suo prezzo si stacca dal consenso e ci resta. Il segnale e' |scarto|, non il segno — su Mt.Gox il BTC andava a premio (si comprava BTC per far uscire valore), su un venue in fuga si vede lo sconto. Dicono la stessa cosa.

Misurato su 8 anni di feed certificato, consenso = mediana di venue USD indipendenti (Coinbase, Bitstamp; mai USDT — il depeg 2022 sposta BTC/USDT fino al 3% e genererebbe falsi allarmi giganti):

asset       ore   mediana      p95      p99    p99.9       max   >50bps   >100bps
BTC      65,043       3.1     11.4     18.0     34.4     712.9    0.06%    0.018%
ETH      64,541       3.3     13.3     22.2     44.3     453.1    0.07%    0.017%

Deribit sta a 3 bps dal consenso in mediana. E' un fondo di rumore bassissimo, ed e' cio' che rende possibile una soglia con margine.

2. L'ipotesi meccanica era in parte SBAGLIATA

Avevo scritto, prima di misurare, che il discriminante sarebbe stato la costanza del segno: un venue gated resta da un lato, un crash rimbalza fra i due. Falso. Gli episodi peggiori su Deribit sono tutti a segno costante anche loro:

BTC  2020-03-13 10:00   12h  picco  158 bps  segno -1      (crash COVID)
ETH  2022-09-14 20:00   10h  picco   97 bps  segno -1      (Merge)
ETH  2020-03-12 23:00    3h  picco  453 bps  segno -1
BTC  2021-07-01 13:00    2h  picco  150 bps  segno +1

In un cascata di liquidazioni il perp sta sotto lo spot per ore di fila: e' un run a segno costante come quello di un venue gated. Il segno costante resta nel rilevatore (toglie il rumore simmetrico), ma non e' lui a separare i due casi: separano ampiezza e durata. Ipotesi corretta nella conclusione, sbagliata nel meccanismo.

3. La taratura va DICHIARATA, perche' due criteri ovvi sbagliano in versi opposti

Provati entrambi in sessione:

criterio ingenuo	esito	perche' e' sbagliato
minimi bps	25 bps / 24h	consuma 24 delle ~72 ore che diede FTX
minime ore	500 bps / 2h	manca FTX (300 bps): margine 0.6x

Criterio adottato, in quest'ordine: (1) zero falsi allarmi su entrambi gli asset in 8 anni; (2) margine ≥3x sul caso storico piu' debole (FTX ~300 bps) → soglia ≤100 bps; (3) a quei vincoli, minima latenza.

   2h  ->   500 bps  (scartata: 0.6x < 3x su FTX)
   3h  ->   150 bps  (scartata: 2.0x < 3x su FTX)
   4h  ->   100 bps  <- SCELTA
   6h  ->    75 bps
  24h  ->    25 bps

→ 100 bps persistenti 4 ore a segno costante. Margine 3x su FTX, 5x su QuadrigaCX, 10-20x su Mt.Gox. Zero falsi allarmi in 8 anni, crash COVID / maggio 2021 / LUNA / novembre 2022 inclusi.

4. Il controllo positivo — senza, "non scatta mai" non e' una buona notizia

Un rilevatore tarato per non segnalare e' indistinguibile da uno rotto. Puntato su Bitfinex 2018-19 (problemi bancari/Tether, premio persistente), consenso Coinbase+Bitstamp con Bitfinex escluso dal proprio consenso:

BTC: 33.000 ore, scarto mediano 11 bps, max 1136 bps -> 22 EPISODI a 100bps/4h
    2018-12-26   2324h  picco  447 bps  segno +1
    2018-11-08   1151h  picco  663 bps  segno +1
    2018-10-10    496h  picco 1136 bps  segno +1
    2019-04-25    363h  picco  734 bps  segno +1

22 scatti su un venue realmente in stress, zero su Deribit in 8 anni. E la durata di quegli episodi risponde alla domanda che conta davvero: un venue gated resta dislocato per settimane, quindi 4 ore di latenza di rilevamento costano una frazione trascurabile del preavviso.

5. Il lato risposta: quanto costa sbagliarsi

Un allarme senza il costo della risposta non e' un sistema. Misurato sul book Deribit reale (TP01+SKH01 75/25) forzando flat una finestra a ogni data d'inizio possibile:

 giorni   costo medio   mediana   p5 (peggio)  p95 (meglio)  % dannosi
      1       -0.149%   -0.100%       -1.093%        0.590%      76.4%
      3       -0.248%   -0.100%       -2.065%        1.006%      67.9%
      7       -0.442%   -0.100%       -4.072%        1.505%      62.4%
     30       -1.537%   -0.455%       -9.236%        2.993%      57.3%

⚠️ Errore mio, corretto: avevo impostato il break-even sul p5 (la coda). Per un valore atteso ripetuto nel tempo si usa la media — con la coda il numero esce 8.3x piu' severo e la conclusione si ribalta. Il p5 serve a sapere quanto puo' bruciare una volta, non a decidere.

Il tripwire conviene se p_annua > (falsi allarmi/anno) x 0.00248:
     1 ogni 8 anni  ->  p >  0.031%     conviene per ogni p del ventaglio
            1/anno  ->  p >  0.248%     conviene per ogni p del ventaglio
            4/anno  ->  p >  0.991%     conviene da p=1%
           12/anno  ->  p >  2.974%     conviene solo a p=5%
           52/anno  ->  p > 12.889%     NON conviene mai

Il valore del sistema sta tutto nella SPECIFICITA', non nella sensibilita'. Un tripwire che strilla 12 volte l'anno sarebbe dannoso; questo, a zero falsi allarmi misurati su 8 anni, ha un break-even di p > 0.031% — un ordine di grandezza sotto l'ipotesi piu' ottimistica del venue-risk (0.5%).

6. Cosa e' stato cablato

src/live/venue_watch.py (nucleo puro, testabile) + scripts/live/venue_watch.py (runner), 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, e il terzo non e' il primo: OK (misurato, sotto soglia) / ALERT (misurato, sopra soglia e persistente → Telegram) / BLIND (non misurabile: referenze irraggiungibili o in disaccordo fra loro). "Non vedo" non e' "va tutto bene": dopo 12 ore di cecita' scatta un allarme suo. Stessa lezione della contabilita' a 3 stati di paper_dvolspread.

Allerta, non blocca. L'azione giusta a un vero positivo e' prelevare, che richiede comunque un intervento manuale — una chiave API con permesso di prelievo sarebbe essa stessa un rischio. E bloccare l'esecuzione non protegge il saldo: il saldo e' a rischio anche stando flat.

Runbook pre-deciso (nel docstring del modulo, per non doverlo decidere nel momento sbagliato):

1. escludere il guasto delle referenze (n_refs, ref_spread_bps);
2. public/status (platform_locked) e canali ufficiali;
3. prelievo di prova piccolo — l'unica evidenza DIRETTA; se non passa in tempi normali l'allarme e' vero qualunque altra spiegazione esista;
4. se non passa: flat + prelievo totale. Sbagliarsi costa 0.248%, aver ragione salva il 100%.

7. Cio' che questo sistema NON copre — e va detto

Il tripwire prezza la finestra, non la sua esistenza. Un fallimento senza finestra non lo prende nessuno: furto di chiavi, sequestro, exit-scam notturno. Quella parte di p resta scoperta, e la sola difesa e' quella che l'operatore ha rifiutato fino a $20k — lo split. Il sistema riduce il rischio di venue, non lo elimina, e non e' un argomento per cambiare la decisione del 26/07.

Secondo limite dichiarato: il preavviso storico di 200-2300 ore viene da un caso osservato (Bitfinex). E' un'ancora, non una distribuzione.

8. Regole trasferibili

1. Un rilevatore tarato per non segnalare va validato su un controllo positivo, o "non e' mai scattato" e' indistinguibile da "e' rotto". Qui: 22 scatti su Bitfinex, zero su Deribit.
2. Una soglia si sceglie con un criterio dichiarato PRIMA, perche' i criteri ovvi sbagliano in versi opposti: "minimi bps" perde preavviso, "minime ore" perde il caso da prendere.
3. La persistenza richiesta e' latenza, e la latenza va sottratta al preavviso. Va confrontata con la durata del fenomeno da rilevare, non scelta in astratto.
4. Un break-even si calcola sulla media, non sulla coda. La coda dice quanto fa male una volta; la media dice se conviene ripeterlo.
5. Un outer-join con una referenza corta e' una trappola (2ª volta oggi, dopo GTAA01): la prima corsa tronco' il campione da 8 anni a 29 giorni in silenzio, e la diagnostica di copertura era gia' stampata. Una diagnostica stampata non e' un controllo — ora c'e' una guardia che ferma lo script.
6. Un controllo positivo dentro il ramo else non gira mai. Trovato in sessione: era finito nel ramo di fallimento, cioe' esattamente il difetto che doveva prevenire.