Come Fare Backtesting di Strategie sui Prediction Market su Polymarket & Kalshi

Cosa rende i prediction market diversi per il backtesting

Un contratto su un prediction market non è un'azione né un perp. Ogni esito è quotato da 0 a 1 — la sua probabilità implicita — e alla chiusura un lato vale esattamente $1 e l'altro $0. I mercati crypto up/down si chiudono in 5-60 minuti rispetto a un prezzo di riferimento, gli spread si allargano e la profondità si assottiglia avvicinandosi alla scadenza, e l'intera vita di un mercato può essere più breve di una singola candela su un grafico normale.

Questa struttura cambia ciò che un backtest deve fare. Campionare un ultimo prezzo ogni minuto perde la maggior parte di un mercato di cinque minuti; ignorare il libro nasconde lo spread che determina il P&L su un contratto che paga al massimo un dollaro; e etichettare erroneamente il settlement trasforma i vincitori in perdenti. Il resto di questa guida riguarda il modo di fare ognuna di queste cose correttamente.

Passo 1 — Parti dal vero libro degli ordini

Un backtest può essere onesto solo quanto i suoi dati. Hai bisogno del libro degli ordini completo — ogni bid e ask in attesa con la sua size, su entrambi i lati — catturato a ogni variazione anziché su un clock fisso, perché la cattura event-driven è l'unico modo per vedere l'intero arco di un mercato a breve scadenza. Né Polymarket né Kalshi servono la propria profondità storica del libro degli ordini, quindi riprodurre il libro com'era richiede un provider che lo abbia catturato in modo continuo.

DepthFeed serve esattamente questo per entrambe le venue in un unico schema: Polymarket catturato event-driven dal websocket CLOB, Kalshi interrogato continuamente a piena profondità (fino a 100 livelli per lato), ogni snapshot con timestamp epoch-millis e un prezzo di riferimento crypto sottostante associato. Un singolo loader legge entrambe le venue.

Passo 2 — Modella i fill rispetto alla profondità, non al mid

Questo è il passo che separa un backtest su cui puoi operare da uno che mente. Un ordine a mercato percorre il libro — esegue il fill al miglior livello prima, poi al successivo, così il suo prezzo medio è peggiore del touch ogni volta che consuma più del livello in cima. Un ordine resting si unisce alla coda e viene eseguito solo se il mercato ci passa attraverso con abbastanza size dietro. Eseguire tutto al mid con zero slippage, il default della maggior parte dei backtest improvvisati, sopravvaluta sistematicamente il vantaggio.

Qualunque percorso tu scelga, insisti su un fill depth-aware. Su uno spread round-trip di quattro centesimi, su un contratto che paga al massimo un dollaro, la differenza tra un fill al mid e uno reale è enorme — e si accumula su ogni operazione.

Passo 3 — Chiudi al vero esito

Poiché il payoff è binario, il settlement non è un dettaglio di arrotondamento — è la maggior parte del P&L. I mercati Polymarket up/down risolvono rispetto a un 'prezzo da battere' fissato all'apertura versus il riferimento finale alla chiusura; i contratti Kalshi si chiudono sì/no rispetto a un prezzo di riferimento pubblicato alla scadenza. Fai il backtest rispetto alla vera risoluzione, non a un'assunzione, e controlla la distribuzione: tra i mercati crypto up/down già chiusi che abbiamo catturato, gli esiti si avvicinano a un lancio di moneta, quindi qualsiasi backtest la cui distribuzione di settlement si discosta molto da quello sta probabilmente etichettando erroneamente i vincitori.

Passo 4 — Scegli il tuo workflow: no-code o API

Ci sono due modi per eseguire tutto quanto sopra su DepthFeed. Il percorso no-code è il Backtest Lab: scegli una criptovaluta e una finestra, seleziona un preset o scrivi una breve regola, scegli un modello di fill, e riproduce i mercati già risolti e li chiude per te nel browser — fill VWAP depth-aware inclusi, nessuna pipeline da costruire.

Il percorso API è per la ricerca personalizzata su larga scala: recupera snapshot a piena profondità tramite l'API REST, ricostruisci il libro nel tuo stack e applica qualsiasi modello vuoi. Poiché l'API REST storica e il WebSocket live emettono JSON identico, il loader che scrivi per riprodurre la storia legge il feed live invariato — operi con lo stesso codice su cui hai fatto il backtest.

Passo 5 — Forward-test prima di rischiare denaro reale

Un backtest è adattato al passato, anche se leggermente, quindi l'ultimo passo è eseguire il sopravvissuto in avanti su mercati il cui esito nessuno conosce ancora. Distribuisci la regola al paper trading — o guidala dal tuo bot via webhook — e opererà sui libri live con denaro virtuale, eseguendo fill al vero bid/ask e chiudendo automaticamente alla risoluzione. La curva del capitale che costruisce è la prova forward che un backtest non può darti.

Questo completa il ciclo: dati → backtest onesto → forward test. Elimina le idee a basso costo sulla storia, promuovi quelle che sopravvivono ai libri paper live, e solo allora considera capitale reale.

Errori comuni

• Dati a ultimo prezzo o orari: nascondono lo spread e perdono la vita di un mercato da 5 a 60 minuti.
• Fill al mid: assumere zero slippage sopravvaluta il vantaggio, in modo significativo, su un contratto che paga al massimo $1.
• Settlement presunto: etichetta i vincitori dal vero prezzo di riferimento, non da un'ipotesi — è la maggior parte del P&L.
• Look-ahead bias: reagisci solo a dati con un timestamp di ricezione uguale o precedente al momento della tua decisione.
• Saltare il forward-test: un vantaggio che esiste solo sulla storia già chiusa potrebbe non sopravvivere ai mercati live.