Polymarket ha una testnet?

Questo sorprende chi arriva dagli exchange crypto, dove una testnet è la norma. Binance ne ha una. Kalshi, il concorrente più vicino a Polymarket, gestisce una sandbox completa su demo-api.kalshi.com che replica l’API di produzione con soldi finti. Polymarket non ha nulla di equivalente.

Quindi la domanda pratica non è dov’è la testnet, ma come riduco il rischio di una strategia quando l’unico ambiente è la produzione? Ci sono quattro approcci, e ognuno intercetta classi di bug diverse. Alla maggior parte delle persone ne serve più di uno.

Perché non esiste una testnet

Vale la pena capirne il motivo, perché spiega perché è improbabile che ne compaia una. Polymarket è un order book on-chain che regola su Polygon. Una testnet richiederebbe più di una copia dell’API: servirebbe un deployment parallelo dei contratti dell’exchange CTF, un pUSD di testnet, un motore di matching e un order book sintetico con liquidità realistica su entrambi i lati.

Quest’ultima parte è quella difficile. Un order book di sandbox con liquidità finta non ti insegna quasi nulla di utile, perché la cosa che devi davvero imparare è come i tuoi ordini interagiscono con controparti reali: cosa viene eseguito, a che prezzo, con quanto slippage. Una testnet ti dà un’integrazione funzionante e una falsa sensazione di avere un vantaggio. Il che è probabilmente peggio di niente.

I quattro modi per testare senza una testnet

1. Testa gratis tutto ciò che non è un ordine

Una quota sorprendente dei bug dei bot non ha nulla a che fare con il trading. Autenticazione, firma delle richieste, deriva dell’orologio, paginazione, gestione dei decimali, logica di riconnessione, backoff sui rate limit: tutto questo si può esercitare sugli endpoint di lettura di produzione senza spendere nulla e senza piazzare un solo ordine.

Gli endpoint dei dati di mercato sono pubblici e non richiedono autenticazione. Punta il tuo bot su di essi, fallo girare per un giorno e farai emergere la maggior parte dei difetti di integrazione prima di mettere a rischio qualsiasi capitale.

# Public, unauthenticated, safe to hammer (within rate limits).
curl -s "https://clob.polymarket.com/book?token_id=<TOKEN_ID>" | jq .

# Confirm your auth works without placing an order:
# a 200 here proves your key, secret, passphrase and clock are all correct.
curl -s "https://clob.polymarket.com/auth/api-keys" \
  -H "POLY_ADDRESS: $ADDRESS" \
  -H "POLY_SIGNATURE: $SIG" \
  -H "POLY_TIMESTAMP: $TS" \
  -H "POLY_NONCE: 0" | jq .

2. Fai backtest sugli order book storici

È la cosa più vicina a una testnet che esista, e risponde a una domanda a cui nessuna testnet potrebbe rispondere: questa strategia fa davvero soldi?

Il problema è che l’API di Polymarket non può darti questi dati. Fornisce lo stato attuale del book. Non esiste un archivio storico della profondità, e una volta che un mercato si risolve il suo book restituisce 404. Non puoi ricostruire dall’API com’era il book alle 14:03:17 di martedì scorso, con nessun livello di rate limit e con nessun piano.

Quindi il backtesting richiede snapshot point-in-time che qualcuno ha registrato mentre i mercati erano attivi. È quello che fa PolyTest: 240M+ snapshot dei mercati crypto Up/Down di Polymarket, con 8 livelli di profondità dell’order book su entrambi i lati, timestamp sotto il secondo e mercati risolti conservati invece che scartati.

# List recent BTC 5-minute Up/Down markets
curl -H "X-API-Key: $POLYTEST_KEY" \
  "https://api.polytest.io/api/v1/markets?coin=btc&market_type=5m&limit=20"

# Replay one market's book, snapshot by snapshot
curl -H "X-API-Key: $POLYTEST_KEY" \
  "https://api.polytest.io/api/v1/markets/$MARKET_ID/snapshots?include_orderbook=true"

3. Fai paper trading sui prezzi live

Il backtesting dimostra che il vantaggio esisteva in passato. Il paper trading dimostra che il tuo bot funziona adesso: che si riconnette, gestisce i 429, legge correttamente l’orologio e genera segnali in tempo reale in condizioni reali.

Non esiste un endpoint di Polymarket per questo, quindi lo costruisci tu: fai girare il ciclo della tua strategia live sui dati di mercato di produzione e, invece di chiamare POST /order, scrivi l’ordine previsto in un log insieme allo stato del book in quell’istante. Poi confrontalo con quello che ha fatto il book subito dopo.

// A paper-trading shim: identical interface, no capital at risk.
interface OrderIntent {
  tokenId: string;
  side: "BUY" | "SELL";
  price: number;
  size: number;
}

class PaperExecutor {
  readonly fills: Array<OrderIntent & { at: number; bookTop: number }> = [];

  async submit(intent: OrderIntent, book: { asks: { price: number; size: number }[] }) {
    // Record what the book actually looked like at decision time —
    // this is what lets you mark the trade honestly afterwards.
    this.fills.push({ ...intent, at: Date.now(), bookTop: book.asks[0].price });
  }
}

// Swap this for the real CLOB client only once the numbers look right.
const executor = new PaperExecutor();

Il limite è onesto e inevitabile: le esecuzioni su carta presumono che tu sia stato eseguito. In questo modo non imparerai nulla sulla posizione in coda o sull’impatto sul mercato. Ma imparerai se il tuo bot sopravvive a una settimana di uptime, che è una cosa diversa e altrettanto necessaria.

4. Vai live in piccolo

Prima o poi devi piazzare un ordine reale, e a dirla tutta il test è proprio questo: tutto ciò che viene prima è una prova generale. Fallo in modo deliberato: size minima, un solo mercato, un limite rigido alla posizione e un kill switch che hai davvero testato.

• Inizia dalla size minima del mercato, non dalla size che intendi usare.
• Limita l’esposizione totale nel codice, non nella tua testa.
• Testa il percorso di cancellazione prima di quello di ingresso. Non riuscire a uscire è peggio che non riuscire a entrare.
• Gestisci esplicitamente la modalità cancel-only 503: un bot che ri-quota prima di cancellare può finire in un loop invece di chiudere le posizioni.
• Registra ogni richiesta e risposta per la prima settimana. Ti serviranno.

E Polymarket US?

Polymarket US, l’entità regolamentata rivolta agli Stati Uniti, è un discorso a parte. Ha offerto ai partner di integrazione qualificati l’accesso a un ambiente sandbox come parte dell’onboarding, dopo il quale vengono rilasciate le credenziali di produzione. È un processo di onboarding commerciale per partner approvati, non una testnet self-service: non puoi registrarti e iniziare a usarla oggi pomeriggio, e non aiuta chi sviluppa sul CLOB internazionale principale.

Una sequenza di test che funziona

1. Test di integrazione in sola lettura, sui dati di mercato di produzione. Verifica autenticazione, parsing e backoff. Gratis, un giorno.
2. Backtest sugli order book storici con una simulazione realistica delle esecuzioni. Verifica che il vantaggio esista e sopravviva allo spread. È qui che muore la maggior parte delle strategie: meglio qui che con i soldi.
3. Paper trading live per almeno una settimana. Verifica che il bot sia solido dal punto di vista operativo: uptime, riconnessioni, rate limit, orologio.
4. Vai live con la size minima, con un limite rigido all’esposizione e un kill switch testato.
5. Aumenta le dimensioni solo quando i numeri live corrispondono a quelli su carta. Se divergono, il tuo modello di esecuzione era sbagliato: torna al passo 2.

I passi 1, 3 e 4 puoi costruirli da solo in pochi giorni. Il passo 2 è quello che richiede dati che non puoi ottenere da Polymarket, ed è anche quello che più spesso fa risparmiare soldi. Inizia una prova gratuita su PolyTest: tre giorni bastano per capire se la tua idea regge.