research(wave-0822): SLIP-AUDIT — nessun costo nascosto a questa taglia, ma la misura scade (22% del nastro a 600 diventa 687% a 20k)

docs/research/RESULTS-0822.md

@@ -18,6 +18,7 @@ null de-levering superato + eseguibilita' al capitale dichiarato.
 | — | **XSR-REPRO** (integrita') | 🚨 **DIFETTO DI PRODUZIONE** | il numero 1.82 e' SPIEGATO e non era sbagliato (era su una **terza** lente, e su una barra non ancora chiusa) — ma cercandone la causa e' emerso che **`paper_xsr` registra ~41 minuti di mercato al giorno**, non un giorno. Tre gate pre-registrati leggono serie costruite cosi' |
 | 5 | SKEW | **SCARTATO** (Q1, Q2) + **LEAD** (Q3, gate 2027-02-22) | il prezzo muove lo skew (t 3,1-9,4 su 8/8 test), **non il contrario** (max |t| in avanti 2,35 contro 2,08 atteso dal rumore). Ma Q3 e' grosso: **il f=0,73 di VRP01 e' per il 42% STRUTTURA A TERMINE e solo per il 25% skew** |
 | — | **HL-EXEC** (audit di fatto) | **3 falsificazioni misurate** | il pavimento vero e' **$10 (non $5)** e il taker **4,50 bps (non 5,0)** — ma il *"XS01 serve ~$20k"* e' **refutato del tutto** (nessuna soglia da min-order), il *"XSR01 ~$5.000"* e' **conservativo di 1,7x** (vero ~$3.000), e lo **slippage "rischio #1" di XSR01 e' refutato** con margine **21x** |
+| — | **SLIP-AUDIT** (audit di fatto) | **SCARTATO** = nessun costo nascosto a questa taglia | i backtest a 10 bps RT restano **conservativi di ~1,5 bps/lato**; nessuna evidenza di impatto sopravvive al null (p=0,274; estremi avversi **1/18 contro 4,7 attesi**). **Ma la misura ha una data di scadenza** |
 
 ## Note che sopravvivono ai singoli filoni
 
@@ -407,3 +408,36 @@ algebricamente** la gamba BTC (`sum(w)=0`) — che e' la ragione stessa per cui
 del singolo decimale): titolo `demean_skeptic` **1,82** · gate `basket_gate` **1,75-1,79** (fee
 raddoppiate su una gamba inesistente) · monitor `paper_xsr` **2,21**. **La lente che ha girato i
 gate e' quella PESSIMISTICA** -> il **DSR 0,983 PASS e' stato calcolato su una serie conservativa**.
+
+### SLIP-AUDIT (r0822_slip_audit.py, 18 fill reali, ~14 varianti dichiarate)
+✅ **Fee sul NASTRO: 5,00 bps/lato prima del 2026-08-01, 3,50 dopo (16/16 esatti).** Il taglio
+Deribit e' visibile nei fill reali -> conferma **indipendente** di `fee_watch` (che legge il tier
+dichiarato, non le esecuzioni) e della regola pre-registrata del 26/07 (<=5 bps -> non si tocca
+nulla). **Il listino si e' mosso nel verso buono.**
+- Slippage d'esecuzione (riferimento 5m): mediana **−4,65 bps**, IC95 [−34,6; +20,6]; statistica
+  normalizzata **+1,54 bps** [−1,30; +4,47]. Conversione con la curva pubblicata: **dSharpe −0,026 /
+  dCAGR −0,35 pp**.
+- ⚠️ **Autocorrezione della propria potenza:** il null **empirico** e' **1,43x piu' largo**
+  dell'uniforme assunto -> MDE vera **7,2 bps**, non 5,0. **Con n=18 nessuna via statistica risolve
+  1,5 bps** — dichiarato invece di spacciare l'IC per una risposta.
+📌 **Esperimento naturale, il caso peggiore del campione:** il fill del **sabato 18/07** (ETH $74) e'
+stato il **21,9% del volume della sua barra 5m**, e quella barra ha avuto un range di **1,08 bps**,
+col nostro print a meta' (q=0,48). *Un ordine che prende un quinto del nastro e lascia il prezzo
+entro 1 bps* e' la prova diretta che a questa taglia il libro **non cammina il book**.
+🚨 **La misura ha una DATA DI SCADENZA, e va scritta accanto al numero:** la partecipazione scala
+lineare -> quel 22% diventa **172% di una barra 5m a $5.000** e **687% a $20.000**. **Non si
+estrapola: va rifatta a ogni salto di taglia.** E' il muro di eseguibilita' gia' noto ma sull'asse
+dell'**attrito** invece che del min-order. ⚠️ E il caso peggiore cade di **sabato**, dove TP01 fa il
+**38%** del proprio gross.
+⚠️ **Due difetti del dato, trovati PRIMA di misurare (e ciascuno avrebbe prodotto un numero
+plausibile e falso):**
+(a) `ts_utc` in `book_executions.jsonl` **non e' l'ora del fill** ma l'etichetta dell'ultima barra
+del feed (**18/18 dicono `00:00:00`**; il fill #1 e' etichettato 08/07 ed e' stato eseguito il
+**14/07** = impronta del feed-freeze gia' noto). L'ora vera esiste **solo** in `logs/cron_book.log`:
+senza recuperarla, ogni confronto "al prezzo dell'ora del fill" misurerebbe **la mezzanotte**.
+(b) Il feed certificato e' il perpetual **INVERSE**, il libro trada il **LINEARE USDC** — **4ª
+occorrenza** dello schema `fee_watch`: misurare lo slippage sul feed certificato avrebbe misurato
+**la base**, non lo slippage (base misurata: BTC −0,03 bps, ETH −0,27).
+⚠️ Con n=18 **la media in bps e' inservibile** — un solo giorno (19/08, ETH +14% in 6h) la ribalta:
+si cita la **mediana**. E `REF-A` (−50 bps) **non e' slippage**: e' la differenza di FASE fra l'ora
+del cron e la chiusura giornaliera, gia' misurata bene il 26/07 su 24 ancore appaiate.