research(wave-0822): HL-EXEC refuta il muro dei 20k di XS01 e lo slippage come rischio #1 — e il 20k di venue e' un'altra cosa
This commit is contained in:
@@ -17,6 +17,7 @@ null de-levering superato + eseguibilita' al capitale dichiarato.
|
||||
| 8 | VOL-SIZE | **LEAD** (gate 2026-12-22) + 1 falsificazione | dare a SKH01 una size per-trade regge a **23/23 ancore**, 8/8 anni, null di permutazione e trasferimento su V1 — ma vale **+0,07 di Sharpe di libro, un terzo della fortuna d'ancora del libro stesso (+0,196)**. Il vol-target di **libro** e' invece falsificato: compra peso SKH gia' respinto e peggiora l'eseguibilita' |
|
||||
| — | **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** |
|
||||
|
||||
## Note che sopravvivono ai singoli filoni
|
||||
|
||||
@@ -362,3 +363,47 @@ nuovo: **va decisa PRIMA del 23/10, non quel giorno.**
|
||||
pubblicato senza quel controllo"*.
|
||||
- ✅ Smile vettorizzato (512s -> 2,0s) verificato **bit-exact** contro il ciclo lento su 21.244 celle.
|
||||
- ✅ **Convergenza indipendente** con l'agente TERM-STRUCTURE: **75 giorni utili** (l'altro trovava 74).
|
||||
|
||||
### HL-EXEC (r0822_hl_exec.py, 132 simulazioni, 0 celle di segnale = 0 selezione)
|
||||
✅ Identita' con la produzione **prima** di ogni delta: `sim_libro` == `paper_xsr._step` a
|
||||
**max|diff| 5,4e-20**; XS01 == `_xsec_returns()` a **max|diff| 0,0**.
|
||||
✅ **Verifica MAINNET** (il progetto e' nato da un feed testnet): 51/51 asset, deviazione mediana
|
||||
2,21% su feed vecchio 17h contro un movimento tipico del 2,81%; cross-check su terzo venue
|
||||
BTC Deribit $77.997 vs HL $77.339 = −0,84%.
|
||||
**Parametri assunti -> misurati:** min order **$5 -> $10** (docs + **3.827 livelli a un ordine:
|
||||
minimo $10,63, p01 $12,02, 0,0% sotto $10**); taker **5,0 -> 4,50 bps** (due fonti indipendenti
|
||||
coincidono); slippage **non modellato -> 1/2 spread 0,7 bps (19 major) / 1,0 bps (coda), max 4,5**;
|
||||
tier VIP: a $600-20k **sempre tier base**.
|
||||
📌 **XS01: la soglia dei $20k non esiste.** Origine del numero pubblicato: *"rumore di
|
||||
arrotondamento"*, stima a occhio del diario 19/06. Misurato: haircut ~0 gia' a **$200-600 allocati**;
|
||||
a $600 lo Sharpe passa **1,33 -> 1,30**. **E il meccanismo spiega perche':** gli ordini sono **due
|
||||
popolazioni** — il ribilanciamento del segnale (ogni 10g) e' il **13% degli ordini ma il 75% del
|
||||
nozionale**, ticket mediano $13,65 -> passa sempre; la deriva del vol-target giornaliera e' l'**87%
|
||||
degli ordini ma il 25% del nozionale**, ticket $0,64 -> il pavimento la taglia, **ed e' gratis**.
|
||||
*Contare gli ORDINI da' 16% e sembra un disastro; contare il NOZIONALE da' 75% e spiega perche' lo
|
||||
Sharpe non si muove.* (Convergenza indipendente con XS-LITE, che era arrivato allo stesso meccanismo
|
||||
con numeri diversi.)
|
||||
✅ **Fortuna di fase girata anche qui** (l'haircut e' un Δ): 10 fasi, mediana delle differenze
|
||||
appaiate **+0,007**, banda [−0,060, +0,061], **0/10 fasi con danno > 0,10**.
|
||||
📌 **XSR01: soglia vera ~$3.000** (non $5.000 — sbagliata nella direzione **sicura**). Banda sui
|
||||
pavimenti $8/$10/$12: ROTTO <=$1.000, INDECIDIBILE $1.500-2.000, **ok >=$3.000**.
|
||||
📌 **Slippage refutato come rischio #1** al livello di liquidita' odierno: lo Sharpe scende sotto
|
||||
1,0 a ~20 bps/gamba = **~16 bps di slippage = 21x quello misurato**. ⚠️ L'agente dichiara il limite:
|
||||
3 snapshot = **172 secondi di oggi**, una fotografia, non tre osservazioni. **E' il MARGINE (21x) che
|
||||
regge la conclusione, non il livello.**
|
||||
🚨 **Due conseguenze che l'operatore deve vedere:**
|
||||
1. **Il "$20k" di XS01 e il "$20k" della DECISIONE DI VENUE (26/07) sono due cose diverse che
|
||||
CLAUDE.md ha conflato.** Quello di XS01 **cade**; **quello di venue REGGE intatto** — e' una
|
||||
decisione dell'operatore su un altro asse (la rovina da fallimento exchange), non sull'eseguibilita'.
|
||||
XS01 resta fuori dal live **per la decisione di venue, non per taglia**.
|
||||
2. **La gamba di eseguibilita' del gate 2026-10-23 e' tarata su un vincolo che a $5.000 non morde**
|
||||
(haircut li' −7%...+2%): *una condizione pre-registrata che non puo' fallire non e' una
|
||||
condizione*. L'agente **non ha anticipato il gate**: la soglia Sharpe>=1,0 resta al 23/10.
|
||||
⚠️ **Terza spiegazione dell'1,82, complementare alle altre due:** `r0725_statarb_basket_gate`
|
||||
addebita *"2 gambe per coppia"* = 50 alt + **50 gambe BTC fantasma**, ma il demeaning **annulla
|
||||
algebricamente** la gamba BTC (`sum(w)=0`) — che e' la ragione stessa per cui XSR01 esiste.
|
||||
*L'intuizione del demeaning era stata applicata all'AMPIEZZA e non ai COSTI.*
|
||||
📌 **Quadro conciliato delle tre lenti** (i due agenti concordano sul fatto, non sull'attribuzione
|
||||
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**.
|
||||
|
||||
Reference in New Issue
Block a user