A Polymarket tem uma testnet?

Isso surpreende quem vem de exchanges de cripto, onde uma testnet é padrão. A Binance tem uma. A Kalshi — a concorrente mais próxima da Polymarket — mantém um sandbox completo em demo-api.kalshi.com que espelha a API de produção com dinheiro fictício. A Polymarket não tem nada equivalente.

Então a pergunta prática não é onde está a testnet, e sim como reduzo o risco de uma estratégia quando o único ambiente é o de produção? Há quatro abordagens, e cada uma pega tipos diferentes de bug. A maioria das pessoas precisa de mais de uma.

Por que não existe testnet

Vale entender o motivo, porque ele explica por que é improvável que uma apareça. A Polymarket é um livro de ofertas on-chain que liquida na Polygon. Uma testnet precisaria de mais do que uma cópia da API — precisaria de uma implantação paralela dos contratos da CTF exchange, de um pUSD de testnet, de um motor de casamento de ordens e de um livro de ofertas sintético com liquidez realista dos dois lados.

Essa última parte é a difícil. Um livro de ofertas sandbox com liquidez fictícia não ensina quase nada de útil, porque o que você realmente precisa aprender é como suas ordens interagem com contrapartes reais: o que é executado, a que preço, com quanto slippage. Uma testnet dá a você uma integração funcionando e uma falsa sensação de vantagem. O que é, possivelmente, pior do que nada.

As quatro formas de testar sem testnet

1. Teste de graça tudo o que não é uma ordem

Uma parcela surpreendente dos bugs de bots não tem nada a ver com trading. Autenticação, assinatura de requisições, desvio de relógio, paginação, tratamento de decimais, lógica de reconexão, backoff de limites de requisições — tudo isso pode ser exercitado contra os endpoints de leitura de produção sem gastar nada e sem enviar uma única ordem.

Os endpoints de dados de mercado são públicos e não exigem autenticação. Aponte seu bot para eles, deixe-o rodar por um dia e você vai encontrar a maioria dos defeitos de integração antes de qualquer capital estar em risco.

# 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. Faça backtest em livros de ofertas históricos

Isto é o mais próximo de uma testnet que existe, e responde a uma pergunta que nenhuma testnet conseguiria: essa estratégia realmente dá dinheiro?

O problema é que a API da própria Polymarket não pode fornecer esses dados. Ela serve o estado atual do livro. Não existe arquivo histórico de profundidade, e depois que um mercado é resolvido o livro dele retorna 404. Você não consegue reconstruir pela API como estava o livro às 14:03:17 da última terça-feira, em nenhum nível de limite de requisições, em nenhum plano.

Por isso, o backtesting exige snapshots pontuais que alguém gravou enquanto os mercados estavam ativos. É isso que a PolyTest faz: mais de 240M de snapshots dos mercados cripto Up/Down da Polymarket, com 8 níveis de profundidade do livro de ofertas dos dois lados, timestamps abaixo de um segundo e mercados resolvidos preservados em vez de descartados.

# 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. Faça paper trading com preços ao vivo

O backtesting prova que a vantagem existiu no passado. O paper trading prova que seu bot funciona agora — que ele reconecta, lida com os 429, lê o relógio corretamente e gera sinais em tempo real, em condições reais.

Não existe endpoint da Polymarket para isso, então você o constrói: rode o loop da sua estratégia ao vivo contra os dados de mercado de produção e, em vez de chamar POST /order, grave a ordem pretendida em um log junto com o estado do livro naquele instante. Depois, compare com o que o livro fez em seguida.

// 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();

A limitação é honesta e inevitável: execuções em paper trading supõem que você conseguiu a execução. Assim você não vai aprender sobre posição na fila nem impacto no mercado. Mas vai aprender se seu bot sobrevive a uma semana no ar, o que é outra coisa, igualmente necessária.

4. Entre ao vivo com pouco

Uma hora você vai ter que enviar uma ordem real, e a forma honesta de ver isso é que esse é o teste — tudo antes dele é um ensaio. Faça isso de forma deliberada: tamanho mínimo, um único mercado, um limite rígido de posição e um botão de emergência que você realmente testou.

• Comece pelo tamanho mínimo do mercado, não pelo tamanho que você pretende usar.
• Limite a exposição total no código, não na sua cabeça.
• Teste o caminho de cancelamento antes do caminho de entrada. Não conseguir sair é pior do que não conseguir entrar.
• Trate explicitamente o modo somente cancelamento 503 — um bot que recota antes de cancelar pode entrar em loop em vez de zerar a posição.
• Registre em log todas as requisições e respostas na primeira semana. Você vai precisar delas.

E a Polymarket US?

A Polymarket US, a entidade regulamentada voltada aos Estados Unidos, é outra história. Ela já ofereceu a parceiros de integração qualificados acesso a um ambiente sandbox como parte do onboarding, após o qual são emitidas as credenciais de produção. Isso é um processo comercial de onboarding para parceiros aprovados, e não uma testnet self-service — você não consegue se cadastrar e começar a usá-la hoje à tarde, e ela não ajuda quem está construindo sobre o CLOB internacional principal.

Uma sequência de testes que funciona

1. Teste de integração somente leitura, contra os dados de mercado de produção. Prove a autenticação, o parsing e o backoff. Grátis, um dia.
2. Backtest em livros de ofertas históricos com simulação realista de execuções. Prove que a vantagem existe e sobrevive ao spread. É aqui que a maioria das estratégias morre — melhor aqui do que com dinheiro.
3. Paper trading ao vivo por pelo menos uma semana. Prove que o bot é operacionalmente sólido: disponibilidade, reconexões, limites de requisições, relógio.
4. Entre ao vivo com o tamanho mínimo, com um limite rígido de exposição e um botão de emergência testado.
5. Só aumente o tamanho depois que os números ao vivo baterem com os do paper trading. Se divergirem, seu modelo de execução estava errado — volte ao passo 2.

Os passos 1, 3 e 4 você consegue construir sozinho em poucos dias. O passo 2 é o que exige dados que você não consegue obter da Polymarket, e também é o que mais costuma poupar dinheiro. Comece um teste grátis na PolyTest — três dias são suficientes para ver se a sua ideia se sustenta.