Dopo che la mia ricerca aveva certificato che la price action su BTC a 5 minuti non ha edge tradabile, la domanda giusta non era "quale segnale migliore posso trovare?", ma: "esiste un edge che non richieda affatto di prevedere il prezzo?".
La risposta era nella struttura del mio setup: io vedevo due prezzi dello stesso asset. Il feed dell'exchange di riferimento (Binance futures, via websocket) e la quotazione del mio broker CFD sullo stesso sottostante. Il prezzo del broker segue quello dell'exchange — deve farlo, per costruzione — ma lo segue con un ritardo e un rumore variabili. Quando il feed veloce si muove bruscamente, per una frazione di tempo il prezzo lento è "sbagliato": non una previsione — un fatto, con una scadenza.
Questo è latency arbitrage nella sua forma retail: comprare/vendere il prezzo lento nella direzione in cui quello veloce è già andato, e uscire alla convergenza. La fonte dell'edge è strutturale: paga l'attrito del meccanismo di quotazione del broker.
v4, v5: cronaca di un fallimento istruttivo
La v4 funzionava "a sensazione di log": scattava sulle divergenze, chiudeva a tempo. La v5 aggiunse take profit ambiziosi (0,55–0,85%) con orizzonte massimo di 600 secondi. Risultato: 50 trade live, mercato −8,54 $, commissioni −118,48 $, netto −127,02 $. Il 93% della perdita era costi. L'autopsia però va oltre, e ogni dettaglio è una lezione generale:
- Zero take profit colpiti su cinquanta. I TP a 0,55–0,85% erano fisicamente irraggiungibili nell'orizzonte di vita della divergenza (secondi, non minuti). Il parametro non era ottimizzato male: era concettualmente estraneo al fenomeno tradato. Se il fenomeno è una convergenza, l'uscita deve essere la convergenza — non un livello di prezzo sperato.
- Il guardian ancorato al numero sbagliato. Il limite di drawdown era calcolato su un balance letto a runtime invece che sulla baseline vera del conto prop. Il guardiano proteggeva un conto immaginario. Su un conto prop la baseline è una costante contrattuale, e va scritta come tale, non dedotta dallo stato corrente.
- Il punteggio saturato. La soglia adattiva del segnale era satura al massimo: filtrava tutto uguale, cioè non filtrava niente. Ogni soglia adattiva ha bisogno di un collaudo sui suoi estremi: un filtro saturo è un filtro morto che nessun log ordinario vi segnala.
Tre bug diversi con la stessa radice: componenti scritte prima di aver capito con precisione il fenomeno. La v6 è nata invertendo l'ordine: prima la fisica del fenomeno, poi il codice.
v6: l'architettura cost-gated
Tutto riorganizzato attorno a un principio solo — il fenomeno è una convergenza breve; ogni componente deve rispettarne la fisica:
- Cost-gate: si entra solo se la divergenza misurata supera 2× il costo totale stimato live (commissioni + spread corrente + slippage EWMA). È il filtro che manda il sistema in silenzio per ore, ed è corretto così: la selettività qui è la strategia.
- Uscita a convergenza, non a target: chiusa la forbice, chiuso il trade. Tempo massimo di permanenza 120 secondi — oltre, l'ipotesi che giustificava il trade è scaduta, e una posizione la cui ipotesi è scaduta va chiusa a prescindere dal suo P&L.
- Baseline prop esplicita, hard-coded come costante contrattuale; sizing anti-martingala ancorato al margine residuo rispetto al floor.
- Kill-switch sull'EV: il sistema tiene la contabilità della propria aspettativa realizzata su finestra mobile; se l'EV misurato diventa negativo al netto dei costi, si spegne da solo. La domanda "è rotto o è varianza?" risolta con una soglia scritta invece che con l'ansia.
- Shadow mode: il sistema fa tutto — rileva, decide, dimensiona, registra — tranne inviare gli ordini. Produce il dataset di trade virtuali con marca temporale e costi stimati, a rischio zero.
Il criterio di promozione dalla shadow mode al denaro vero è scritto nel codice, non nel mio umore: almeno 30 trade shadow con EV medio positivo. Il sistema resta lì finché il criterio non è soddisfatto. Se non lo sarà mai, la v6 morirà senza aver perso un euro — che è il secondo miglior esito possibile per un sistema, e infinitamente migliore del terzo.
Le lezioni portabili (anche se non farete mai HFT)
- L'edge migliore è quello che non prevede ma sfrutta un vincolo strutturale. Cercate asimmetrie di meccanismo — calendario, microstruttura, flussi obbligati — prima di cercare segnali.
- Ogni parametro deve appartenere alla fisica del fenomeno. Un TP di prezzo su un fenomeno di convergenza temporale è un errore di categoria, non di taratura — e nessun ottimizzatore ve lo dirà.
- Shadow mode prima dei soldi, con criterio di promozione scritto. Vale per un bot HFT come per il vostro nuovo setup discrezionale.
- Sulla latenza conta il rank, non il valore assoluto: non serve essere veloci in assoluto, serve essere più veloci degli altri che sfruttano lo stesso segnale sulla stessa venue. La domanda giusta non è "quanto è basso il mio ping?" ma "chi altro sta mungendo questa mucca, e passa davanti a me?". Quando la risposta diventa "troppi", l'edge è finito — e il kill-switch sull'EV è lì per accorgersene prima di voi.
Il feed Binance e la pipeline dati dietro questo progetto: Ricerca quantitativa con Python e API Binance. Il metodo di sviluppo con l'AI che ha scritto la v6: qui, con i prompt.