Adriano Dal Pastro
04cb572535
Book, pesi, cron, config INVARIATI. VRP01 tiene fino a scadenza (S1 = px[i+tn], nessuna gestione infra-settimana) e il profit-take era l'unico grado di liberta' non misurato: i 4 overlay del 03/07 erano tutti sul lato del RISCHIO, questo e' sul lato del PROFITTO. Replica del sleeve bit-exact (max|diff| = 0.0) prima di ogni delta. VERDETTO con fee reali per gamba: canonico ShFULL 1.32 -> PT25 0.22 / PT50 -0.18 / PT75 -0.45. Null del de-levering REFUTED 6/6: a PT25 basta k=0.818 per lo stesso DD con Sharpe 1.32 invece di 0.22. MECCANISMO (confronto appaiato per ingresso): scatta sull'86-91% dei VINCENTI e sul 19-25% dei perdenti -> tronca i vincenti del 27% e salva un perdente su cinque. La peggior settimana e' IDENTICA (-7.27%) in ogni variante: nelle settimane brutte lo spread non tocca mai +50%, quindi e' pura troncatura dell'upside. IPOTESI MIA REFUTATA IN SESSIONE: 'su 7g chi tocca +50% e' chi sarebbe scaduto senza valore, quindi a scadenze lunghe paga'. Testata su 7/10/14/18/21/28g: delta Sharpe negativo a tutti e sei. A 18g (il tenore di cerbero-bite) il DD migliora 7.1->3.8% ma lo Sharpe crolla = firma del de-levering. CORREZIONE a un numero pubblicato oggi: il sleeve modella le fee come 12.5% del credito netto, il listino vero e' 0.03% del sottostante per gamba (cap 12.5% del premio della singola opzione, che quasi mai morde) -> sovrastima di ~2x. Il numero onesto di VRP01 con f=0.73 e' ShFULL 0.47, non 0.31. fee_frac NON cambiato: il forfait e' conservativo e i numeri di ammissione di questo progetto si tengono conservativi. A $3.000 la domanda non e' il rendimento: BTC min 0.1 = $6.210 di collaterale per lotto -> FUORI; ETH min 1 contratto = $1.832 -> 1 lotto. Il sleeve 50/50 diventa ETH-only e al peso di book (12% = $360) sono 0 lotti. REGOLE: (a) un'uscita si giudica appaiata per INGRESSO, mai allineando le serie sulla data di USCITA — e' quella che la variante cambia, e l'inner-join tiene solo i casi in cui non e' successo niente (errore commesso e corretto in sessione, congelato in un test); (b) una regola d'uscita che scatta piu' spesso sui vincenti che sui perdenti non e' protezione, e' troncatura; (c) prima del rendimento a un capitale dato, misurare il lotto minimo del venue. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
158 lines
8.8 KiB
Markdown
158 lines
8.8 KiB
Markdown
# 2026-07-30 (3º filone) — profit-take al 50% su VRP01: REFUTED, e una correzione a un numero di stamattina
|
||
|
||
**Domanda dell'operatore:** *«fai la misura del profit-take al 50%, simula con 3K».*
|
||
**Esito: book, pesi, cron, config INVARIATI.** Il profit-take **non entra**. Ma il filone ha
|
||
prodotto una correzione favorevole a un numero pubblicato **oggi stesso**, e una mia ipotesi
|
||
refutata nella stessa sessione.
|
||
|
||
Script `scripts/research/r0730_vrp_profit_take.py`, test `tests/test_vrp_profit_take.py` (16 casi).
|
||
|
||
## Perché questa misura e non un'altra
|
||
|
||
VRP01 come codificato **tiene fino a scadenza**: in `_vrp_weekly_asset` il payoff è su
|
||
`S1 = px[i + tn]`, non esiste gestione infra-settimana. L'onda 03/07 aveva testato 4 overlay di
|
||
protezione DD (exit-spike, **stop-loss MTM 1.5/2/3×**, ala di coda, cooldown) e li aveva refutati
|
||
4/4 col null del de-levering — ma il profit-take **non era fra quelli**: è un'uscita sul lato del
|
||
*profitto*, non del rischio. Era l'ultimo grado di libertà non misurato su questo sleeve, e la
|
||
misura del 30/07 sulle quote reali diceva che sarebbe scattato in **13 settimane su 15**.
|
||
|
||
L'idea è la regola 1 del motore di cerbero-bite (`debit <= 50% del credito`), progetto dismesso lo
|
||
stesso giorno. **Non se ne eredita il giudizio: bite non ne ha uno** (59 decisioni, tutte
|
||
`no_entry`, 0 posizioni, in testnet). Si misura.
|
||
|
||
## Fondazione: replica bit-exact
|
||
|
||
Prima di ogni delta, la re-implementazione riproduce `_vrp_weekly_asset` a **max|diff| = 0.00e+00
|
||
su entrambi gli asset, zero date non condivise**. Senza questa, ogni numero sotto sarebbe rumore di
|
||
implementazione. Congelata in un test: se qualcuno tocca il sleeve, si rompe.
|
||
|
||
## Il verdetto
|
||
|
||
Fee **reali per gamba** (`min(0.03% del sottostante, 12.5% del premio)` = listino Deribit letto da
|
||
`public/get_instruments`), identiche a canonico e variante.
|
||
|
||
| variante | ShFULL | ShHOLD | maxDD | CAGR | peggior sett. | usciti prima | giorni |
|
||
|---|---|---|---|---|---|---|---|
|
||
| **canonico (a scadenza)** | **1.32** | **0.82** | 10.5% | 10.5% | −7.27% | — | 7.0 |
|
||
| PT 25% | 0.22 | −0.44 | 8.6% | 0.9% | −7.27% | 87% | 2.7 |
|
||
| **PT 50%** | **−0.18** | **−0.65** | 17.3% | −1.3% | −7.27% | 79% | 3.6 |
|
||
| PT 75% | −0.45 | −1.24 | 19.5% | −3.0% | −7.27% | 71% | 4.6 |
|
||
|
||
**Null del de-levering: REFUTED 6/6** (3 livelli × vol-matched e DD-matched). ⚠️ Nota onesta: sotto
|
||
scalatura moltiplicativa lo Sharpe è **invariante**, quindi il null si riduce a «la variante ha
|
||
Sharpe più alto?». Il `k` dice solo *quanto* de-levering ottiene lo stesso DD: per PT25 basta
|
||
**k=0.818** per avere lo stesso 8.6% di DD **con Sharpe 1.32 invece di 0.22**.
|
||
|
||
## Il meccanismo — e perché serviva il confronto appaiato
|
||
|
||
⚠️ **Errore di metodo commesso e corretto in sessione.** Le due varianti sono indicizzate sulla
|
||
**data di uscita**, che il profit-take cambia: un `join="inner"` fra le serie tiene solo le
|
||
settimane *senza* uscita anticipata, dove i valori coincidono per costruzione. La prima
|
||
diagnostica stampava «troncamento 0%, variazione +0%» su tutto — potenza zero, e una conclusione
|
||
esattamente opposta al vero. È la trappola dell'inner-join già codificata due volte nel progetto
|
||
(venue watch, GTAA), qui in veste nuova. Congelata in `test_confrontare_per_data_di_uscita_da_una_risposta_falsa`.
|
||
|
||
Rifatto **appaiato per ingresso** (stesso trade, due esiti):
|
||
|
||
| | BTC (71 trade) | ETH (92 trade) |
|
||
|---|---|---|
|
||
| scatta sui **vincenti** | **86%** | **91%** |
|
||
| scatta sui **perdenti** | 25% | 19% |
|
||
| vincenti | +1.419% → +1.023% (**−28%**) | +1.638% → +1.218% (**−26%**) |
|
||
| perdenti | −3.649% → −2.941% (−19%) | −4.248% → −3.505% (−17%) |
|
||
| somma PnL | +60.2% → **+40.9%** | +56.6% → **+36.5%** |
|
||
|
||
**Il profit-take tronca del 27% i trade che avrebbero vinto comunque e salva un perdente su
|
||
cinque.** La peggior settimana è **identica** (−7.27%) in tutte le varianti: nelle settimane brutte
|
||
lo spread non raggiunge mai +50%, quindi si arriva a scadenza e si prende la perdita piena. È pura
|
||
troncatura dell'upside.
|
||
|
||
## ❌ Ipotesi mia, nata e refutata nella stessa sessione
|
||
|
||
Il meccanismo suggeriva una spiegazione: *su 7 giorni chi tocca +50% è proprio chi sarebbe scaduto
|
||
senza valore; a scadenze lunghe — 18g, quella di bite, e i 30-45 DTE dello standard di mestiere —
|
||
la regola dovrebbe pagare.* Testata su 6 tenori:
|
||
|
||
| tenore | Sh hold | Sh PT50 | ΔSh |
|
||
|---|---|---|---|
|
||
| 7g | 1.32 | −0.18 | −1.50 |
|
||
| 10g | 1.51 | 0.12 | −1.40 |
|
||
| 14g | 1.14 | −0.56 | −1.71 |
|
||
| **18g** (bite) | **1.51** | **0.37** | **−1.14** |
|
||
| 21g | 1.09 | −0.27 | −1.36 |
|
||
| 28g | 1.31 | 0.06 | −1.25 |
|
||
|
||
**Negativo a tutti e sei.** A 18g è il meno peggio e il DD migliora davvero (7.1% → 3.8%), ma lo
|
||
Sharpe crolla: **firma del de-levering**, non di una protezione. Ipotesi refutata.
|
||
|
||
⚠️ **La colonna `Sh hold` NON è un risultato.** Sei celle scelte sul campione pieno: il tenore 18
|
||
sembra migliore del 7 (1.51 vs 1.32) ma è esattamente la selezione che `study_family_honest` +
|
||
deflated-Sharpe esistono per uccidere. La griglia 03/07 si fermava a 10 giorni, quindi il buco è
|
||
reale — ma va chiuso con lo strumento giusto, non con questo sweep.
|
||
|
||
## ✅ Correzione a un numero pubblicato stamattina
|
||
|
||
Il sleeve modella le fee come **12.5% del credito netto** round-trip. Il listino vero è **0.03% del
|
||
sottostante per gamba** (cap 12.5% *del premio della singola opzione*, che quasi mai morde): su ETH
|
||
sono $1.14 d'ingresso contro i $2.26 del forfait, cioè il modello **sovrastima le fee di ~2×**.
|
||
|
||
| lente | ShFULL | ShHOLD | maxDD | CAGR |
|
||
|---|---|---|---|---|
|
||
| sleeve ufficiale (forfait) | 1.08 | 0.58 | 11.8% | 8.2% |
|
||
| **fee reali per gamba** | **1.32** | **0.82** | 10.5% | 10.5% |
|
||
|
||
Combinato col **f = 0.73** misurato stamattina sulle quote reali, il numero onesto di VRP01 è
|
||
**ShFULL 0.47 / DD 14.5%**, non lo **0.31** che ho scritto oggi in CLAUDE.md — che era calcolato
|
||
con le fee forfettarie. Il f resta il difetto dominante; la fee lo attenua di ~+0.16.
|
||
|
||
**Nessuna azione:** `fee_frac` **non è stato cambiato**. Il forfait è conservativo, e questo
|
||
progetto preferisce i numeri di ammissione conservativi (stessa logica per cui l'audit d'ancora
|
||
del 03/07 su VRP01 è stato accolto come «numeri conservativi, non gonfiati»). Cambiarlo alzerebbe
|
||
i numeri di uno sleeve senza aggiungere edge.
|
||
|
||
## Rientro immediato dopo l'uscita
|
||
|
||
Testato come strategia a sé (non è un overlay: cambia la cadenza). PT50 + rientro fa **Sh 1.19**
|
||
contro 1.32 del canonico, CAGR 4.9% contro 10.5%, 200 trade contro 163. Il suo **ShHOLD 2.42** è
|
||
vistoso — ed è precisamente la firma che questo progetto ha imparato a non credere: non è
|
||
selezionabile in-sample (Sharpe FULL più basso), quindi crederci sarebbe selezione sull'hold-out.
|
||
**Non è un lead.**
|
||
|
||
## $3.000 — la domanda che viene prima
|
||
|
||
Parametri veri da `public/get_instruments` (30/07): **ETH `min_trade_amount` = 1 contratto = 1 ETH;
|
||
BTC = 0.1 BTC**. Collaterale = strike corto (convenzione cash-secured del sleeve).
|
||
|
||
| | spot | lotto min | collaterale/lotto | a $3.000 | fee round-trip |
|
||
|---|---|---|---|---|---|
|
||
| BTC | $63.917 | 0.1 | **$6.210** | **0 lotti — FUORI** | $7.67 = 17.8% del credito |
|
||
| ETH | $1.906 | 1.0 | $1.832 | 1 lotto | $2.29 = 12.6% del credito |
|
||
|
||
Tre conseguenze:
|
||
1. **A $3.000 il sleeve 50/50 diventa ETH-only** — cioè non è più il sleeve misurato.
|
||
2. **Al peso di book (12%) l'allocazione è $360 = 0 lotti.** Per un solo lotto ETH servirebbe il
|
||
**61% del conto** su un singolo sleeve.
|
||
3. Quindi a $3.000 la domanda «il profit-take migliora VRP01?» **non è la domanda che decide**:
|
||
VRP01 non è collocabile a quel capitale in nessuna forma sensata.
|
||
|
||
## Cosa resta
|
||
|
||
- **Profit-take: REFUTED**, a ogni livello, a ogni f, a ogni tenore, contro il null del de-levering.
|
||
Con questo il conto degli overlay refutati su VRP01 sale a **5 su 5**, e il filone «gestire VRP01
|
||
dentro il modello» è chiuso su tutti i lati misurabili.
|
||
- **Buco reale rimasto:** il tenore oltre i 10 giorni non è mai passato per `study_family_honest`.
|
||
Non è urgente (le opzioni non sono eseguibili prima di ~$2.6k, e a $3k solo ETH e a peso assurdo).
|
||
- **Il vincolo binding non è la ricerca.** Vale la nota del 26/07: qui si è misurato un ΔSharpe che
|
||
non cambia niente, mentre le leve che decidono restano il capitale che entra e il conto che non
|
||
sparisce.
|
||
|
||
## Regole
|
||
|
||
- **Un'uscita si giudica su un confronto APPAIATO PER INGRESSO**, mai allineando due serie sulla
|
||
data di uscita: la variante che stai testando è esattamente quella che cambia quella data, e il
|
||
join tiene solo i casi in cui non è successo niente.
|
||
- **Una regola d'uscita che scatta più spesso sui vincenti che sui perdenti non è protezione, è
|
||
troncatura** — e si vede in una riga: la peggior settimana non cambia.
|
||
- **Prima di misurare il rendimento a un capitale dato, misurare il lotto minimo del venue.** Qui
|
||
la risposta operativa («non è collocabile») non dipendeva da nessuno Sharpe.
|