PythagorasGoal/docs/diary/2026-07-30-vrp-profit-take.md

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.