Polymarket CLOB WebSocket vs archivi orari: perché la risoluzione decide il tuo backtest
La differenza tra un backtest su Polymarket su cui puoi davvero operare e uno che ti inganna non sta quasi mai nella quantità di dati che possiedi, ma nel modo in cui sono stati campionati.
La cattura event-driven registra l'order book di Polymarket a ogni variazione, direttamente dal websocket del CLOB; un archivio a intervallo fisso lo campiona a orologio (per esempio una volta all'ora) e scarta tutto ciò che accade tra un campione e l'altro. Per i mercati crypto a brevissima scadenza, che si liquidano in pochi minuti, il campionamento a intervalli cattura solo uno o due fotogrammi dell'intera vita di un mercato: ecco perché è la risoluzione, e non la dimensione del file, a determinare se un backtest è affidabile.
Cosa significa davvero "risoluzione"
La risoluzione è la frequenza con cui viene registrato lo stato del book. Esistono due approcci radicalmente diversi. Il campionamento a intervallo fisso scatta uno snapshot a orologio (ogni ora, ogni minuto, ogni poche centinaia di millisecondi) a prescindere da ciò che il mercato ha fatto. La cattura event-driven, invece, registra uno snapshot ogni volta che il book cambia davvero: un nuovo ordine, una cancellazione, un trade.
I due metodi possono produrre file di dimensioni simili e tuttavia trasportare informazioni completamente diverse. Un campione a intervalli su un mercato tranquillo spreca righe su un book immutato; un campione a intervalli su un mercato veloce manca i movimenti che contano.
Il problema dei mercati a brevissima scadenza
I mercati crypto up/down di Polymarket si liquidano in un arco da 5 a 60 minuti. Prendiamo un mercato BTC da 5 minuti. Un archivio orario potrebbe catturarlo zero o una volta: potresti non avere nemmeno un singolo book dell'intera vita del mercato. Un archivio al minuto ti dà circa cinque fotogrammi, nessuno dei quali allineato ai momenti in cui la tua strategia avrebbe effettivamente agito.
La cattura event-driven, al contrario, registra ogni re-quote e ogni trade nel momento in cui accadono, così l'intero arco del mercato (l'apertura, i movimenti man mano che lo spot oscilla, l'allargamento dello spread verso la liquidazione) è tutto lì, pronto da rieseguire.
A confronto
| Archivio orario | Campione al minuto | Event-driven (DepthFeed) | |
|---|---|---|---|
| Copertura di un mercato da 5 minuti | 0–1 fotogrammi | ~5 fotogrammi | Ogni variazione |
| Cattura l'allargamento dello spread | No | Raramente | Sì |
| Slippage misurabile | No | Approssimativo | Sì |
| Allineamento ai movimenti dello spot | No | In modo grossolano | Tick per tick |
| Consegna live | n/d | n/d | ~10 ms mediana (misurata) |
Perché quasi nessuno conserva la profondità event-driven
Registrare ogni variazione del book in tempo reale è costoso: richiede di mantenere una connessione websocket live per ogni mercato, persistere ogni fotogramma e non poter mai recuperare a posteriori ciò che non hai catturato — la storia dell'order book non può essere ricostruita dopo i fatti. È per questo che gli exchange non offrono lo storico del proprio book e la maggior parte degli archivi si ferma a un ultimo prezzo campionato. DepthFeed esiste proprio per registrare e servire quella profondità event-driven.
Key takeaways
- 01La risoluzione riguarda il metodo di campionamento, non la dimensione del file.
- 02Gli archivi a intervallo fisso mancano la vita dei mercati da 5–60 minuti.
- 03La cattura event-driven registra ogni variazione del book, così l'intero arco del mercato è rieseguibile.
- 04La storia dell'order book non può essere recuperata a posteriori: è disponibile solo se qualcuno l'ha catturata live.
La differenza tra un backtest su Polymarket su cui puoi davvero operare e uno che ti inganna non sta quasi mai nella quantità di dati che possiedi, ma nel modo in cui sono stati campionati.
Inizia gratis