Raccolta del differenziale di funding tra sedi di negoziazione — SOL delta-neutral: short sul perp con funding più alto / long sul perp con funding più basso tra BINANCE e HYPERLIQUID, incassa il funding SPREAD (non il carry direzionale), stop sul basis, mantenimento per giorni (2 componenti, market-neutral, 3 parametri)

Una strategia di valore relativo CROSS-VENUE, MARKET-NEUTRAL che incassa il FUNDING-RATE SPREAD tra i contratti perpetui dell'asset SAME su due exchange diversi — BINANCE USD-M SOLUSDT contro HYPERLIQUID SOLUSD. Entrambe le gambe sono contratti perpetui sullo stesso sottostante, quindi la posizione è delta-neutral per costruzione: NOT prendi una posizione direzionale sul prezzo e NOT stai facendo carry sul funding di una singola gamba (il meccanismo che ha generato perdite nella «Persistent-Funding Contrarian Swing» abbandonata, SOL). La fonte ONLY del PnL è il differenziale di funding: SHORT vai short sulla venue che paga il funding più positivo (lì gli short ricevono il funding) e, simultaneamente, vai long con nozionale LONG-uguale sulla venue con funding inferiore o negativo (i long ricevono il funding, o ne pagano meno). Poiché le due gambe seguono lo stesso sottostante, il PnL direzionale sul prezzo si compensa fino a circa 0; la varianza residua è soltanto il piccolo BASIS a ritorno verso la media (il divario di prezzo tra le due venue), limitato da uno stop rigido sul basis. Si tratta di arbitraggio del funding tra exchange (ibrido del Cross-Venue Pattern #3 con #2), un vantaggio strutturalmente poco esplorato e che tollera le commissioni: incassa un flusso di cassa pagato meccanicamente anziché scontrarsi con l'attrito. È stato scelto perché il portafoglio è carente di esposizione cross-venue (obiettivo 7.4% contro 15%) e long-short/market-neutral (14.2%), e perché il catalogo contiene dati di funding per BOTH Binance e Hyperliquid SOL, con una cronologia pluriennale alla risoluzione giornaliera/4h (HL giornaliera/4h non è limitata dalla disponibilità di dati storici). SOL è stato scelto per la significativa dispersione del funding tra venue (altcoin con beta più elevato), pur mantenendo una liquidità di primo livello su entrambe le venue. Solo 3 parametri liberi (soglia di spread per l'ingresso, soglia di spread per l'uscita, basis-stop) per contrastare l'overfitting, che qui è il killer #1.

L'iterazione 2 corregge QA hypothesis_mismatch (intervallo temporale): la cadenza di campionamento è ora fissata a barre 4-HOUR su componenti BOTH, in linea con la risoluzione giornaliera/4h dichiarata nell'ipotesi e con mantenimenti di più giorni, il nome stesso di questa classe e l'intervallo in cui è calibrato ogni parametro espresso in barre (spread_smooth_bars 24 x 4H = 4 giorni); anche 4H divide esattamente l'intervallo di regolamento del funding Binance di 8h, quindi nessun regolamento viene suddiviso tra barre. Nessun ricampionamento unilaterale su un'altra cadenza. Verificato che entrambe le componenti esistano nel catalogo a 4H (SOLUSDT.BINANCE-4-HOUR e SOLUSD.HYPERLIQUID-4-HOUR, cronologia HL da 2024-01), così che il controllo dei dati multi-componente non possa abbandonare l'esecuzione. La logica del segnale/ingresso/uscita, gli import e la struttura restano invariati rispetto a previous_code (i livelli precedenti sono rimasti verdi); l'unica altra modifica dichiara il limite spread_smooth_bars [6, 48] in _param_bounds, affinché l'ottimizzatore non cerchi mai valori che il codice riscrive silenziosamente. Nota a verbale: il testo del feedback QA citava un caso ETHUSDT settimanale rispetto a giornaliero che non corrisponde a questa coppia cross-venue SOL, quindi ho applicato la regola generale di allineamento dell'intervallo temporale, anziché i dettagli letterali di ETH. Il nozionale USD uguale su entrambe le componenti mantiene il delta netto a circa 0 secondo la lezione L59; la leva resta 1.0 e non viene usata nel dimensionamento.

Sandbox è essenzialmente in pareggio: total_return +0.167% su 2181 giorni, avg_trade_return_pct 0.1135% (al di sotto del floor futures 0.15%), profit_factor 1.013, win_rate 0.50 su appena 22 trade. Si tratta di uno smoke test non ottimizzato, quindi non blocca, ma due elementi che l'analista dovrebbe verificare con i numeri sull'intero storico: (1) che il backtest di NautilusTrader accrediti effettivamente i flussi di cassa perp FUNDING su entrambe le gambe — il funding è la fonte di PnL ENTIRE di questa strategia, e se il funding non viene applicato il rendimento misurato è solo rumore di basis meno le commissioni; (2) la sostenibilità di fee/carry alle soglie reali — il differenziale (~8.6% APR ≈ 0.024%/giorno) richiede ~8 giorni correttamente posizionati per coprire il round trip a due gambe da 0.19%, quindi il margine per-trade è ridotto e dipendente dalla durata di detenzione (durata media osservata ~29g). Si noti inoltre impact_cost_pct 44.9% / capacità ~$495K a per_leg_pct 0.50 (150% di esposizione lorda) — un vero tetto di capacità, sebbene una tantum sull'ingresso/uscita a basso turnover di un book di ~22 trade.

Verifica non superata (Livello 2 — scenari sintetici): Parametri utilizzati: ['per_leg_pct', 'min_notional', '_param_bounds', 'max_hold_days', 'min_hold_hours', 'exit_spread_apr', 'enter_spread_apr', 'max_basis_stop_pct', 'spread_smooth_bars'] Verifica che __init__ imposti tutti gli attributi con self.parameters.get(). - steady_uptrend: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000) - steady_downtrend: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000) - flat_ranging: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000) - volatility_spike: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000) - zero_volume: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000) - price_gap: TypeError: SolCrossVenueFundingSpreadNeutral4H._lookup() accetta 4 argomenti posizionali, ma ne sono stati forniti 5 (timestamp della barra: 1735690740000)

Verifica non riuscita (Livello 4 — revisione QA): - La redditività fee/edge fallisce in modo decisivo sul risultato del motore ACTUAL (checklist #7, L6/L26). Il sandbox è un libro in perdita: total_return -2.17%, profit_factor 0.957 (<1.0), Sharpe -0.35, aspettativa -$45/trade, e avg_trade_return_pct -0.0033% — NEGATIVE e ~45x sotto il floor dei futures 0.15%. Su un campione misurabile (82 trade, metrics_reliable: true), quindi un risultato genuino senza edge. Funding WAS accreditato (2580 eventi), quindi anche con il differenziale pagato per intero la strategia non copre il costo round-trip di ~0.19%. - L'ipotesi centrale — 'il PnL direzionale di prezzo netto è ~0; la varianza residua è solo il piccolo basis mean-reverting' — è NOT ciò che il motore ha prodotto. Il PnL per trade è dominato da enormi oscillazioni simmetriche: avg_win $2,009 ~= avg_loss $2,099, massimo ±$9,600-9,959, win_rate 0.50. Un genuino harvest funding-spread delta-neutral dovrebbe mostrare un PnL di un ordine di grandezza più piccolo e asimmetrico positivo per carry; invece il differenziale (netto -$45/trade) è annullato di ~45:1 dal rumore di basis/prezzo. Firma identica alle varianti abbandonate EthCrossVenueCashAndCarry e precedenti varianti cross-venue di funding-capture.

Verifica non riuscita (Livello 4 — revisione QA) [classe=hypothesis_mismatch]: - [edge_concern] Non il motivo del verdetto, registrato per l'analista se l'ipotesi viene riregistrata: sul clock giornaliero il sandbox è onesto e sano (metrics_reliable=TRUE, 92 trade, Sharpe 0.79 CI [0.10,1.51], avg_trade_return_pct 3.61%, PF 1.48), ma regime_performance mostra che ALL del rendimento positivo è concentrato nel terzile di volatilità 'normale' (+489%, Sharpe 2.64) con i terzili 'calmo' (-18.8%) e 'stressato' (-21.8%, 56.7% DD) entrambi negativi, e only_one_regime=true. Drawdown massimo 36% con una durata underwater di 1038 giorni. Il vantaggio è reale ma concentrato per regime e pesante in drawdown; dimensionamento/robustezza meritano scrutinio nel backtest completo. - TIMEFRAME MISMATCH rispetto all'ipotesi preregistrata. L'ipotesi di riferimento (titolo e descrizione in questo brief) specifica in modo inequivocabile e ripetuto WEEKLY barre ('su barre WEEKLY, mantenendo posizioni per settimane o mesi'), ma config.bar_type è ETHUSDT.BINANCE-1-DAY-LAST-EXTERNAL. Non si tratta di un ricampionamento cosmetico: cambia il numero di trade (28 settimanali -> 92 giornalieri), la durata media di mantenimento (10.4 settimane -> 3 settimane) e l'intero test statistico. La docstring del modulo dello sviluppatore stesso ammette che l'iterazione 3 ha effettuato questa identica commutazione giornaliera e QA 'ha avuto ragione a respingerla: era una riformulazione dell'ipotesi fatta unilateralmente nel codice'. La situazione è sostanzialmente invariata: l'ipotesi registrata dice ancora settimanale, quindi questa è di nuovo una riformulazione unilaterale del timeframe nel codice. Il Livello 1.5 valida solo strumento/venue, non il timeframe, quindi questo controllo spetta a QA, e un timeframe dichiarato nell'ipotesi che differisce da config.bar_type è una mancata corrispondenza critica. Questo è esattamente il grado di libertà del ricercatore che il sistema di preregistrazione della factory esiste per prevenire: la forma settimanale è risultata non misurabile, e l'orologio di campionamento è stato quindi cambiato per fabbricare la misurabilità.