Yield Farming com 86% APY? Como usar bots para lucrar na Polymarket

Original Title: I built a Polymarket bot and tested multiple parameter setups, here are the results.

Original Author: @the_smart_ape, Crypto Researcher

Original Translation: Bitpush News

Algumas semanas atrás, decidi construir meu próprio bot para a Polymarket. A versão completa levou várias semanas para ser concluída.

Eu estava disposto a fazer esse esforço porque existe, de fato, uma lacuna de eficiência na Polymarket. Embora alguns bots no mercado já estejam aproveitando essas ineficiências, ainda não é o suficiente, e as oportunidades neste mercado são muito maiores do que o número de bots.

Lógica de construção do bot

A lógica do bot baseia-se em um conjunto de estratégias que executei manualmente no passado, as quais automatizei para melhorar a eficiência. O bot roda no mercado "BTC 15-minute UP/DOWN".

O bot executa um programa de monitoramento em tempo real que pode alternar automaticamente para o round BTC 15 minutos atual, otimizando o melhor bid/ask através de um WebSocket, exibindo uma interface de terminal fixa e permitindo controle abrangente através de comandos de texto.

No modo manual, você pode colocar ordens diretamente.

buy up <usd> / buy down <usd>: Compre um valor específico em USD.

buyshares up <shares> / buyshares down <shares>: Compre uma quantidade exata de shares, usando uma ordem LIMIT + GTC (Good 'Til Canceled) amigável, executada ao melhor preço ask atual.

O modo automático executa um loop recorrente de duas pernas.

Primeiro, ele observa apenas os movimentos de preço dentro dos minutos windowMin no início de cada round. Se qualquer lado cair rápido o suficiente (atingindo uma porcentagem de queda de pelo menos movePct em cerca de 3 segundos), ele aciona a "Perna 1", comprando o lado que sofreu o declínio acentuado.

Após completar a Perna 1, o bot nunca mais comprará o mesmo lado. Ele aguardará a "Segunda perna (Leg 2, ou seja, hedge)" e só acionará se a seguinte condição for atendida: leg1EntryPrice + oppositeAsk <= sumTarget.

Quando essa condição é atendida, ele compra o lado oposto. Após a conclusão da Perna 2, o ciclo termina, o bot retorna ao modo de observação, aguardando o próximo sinal de flash crash usando os mesmos parâmetros.

Se houver uma mudança no round durante o ciclo, o bot abandona o ciclo aberto e reinicia com as mesmas configurações no próximo round.

As configurações de parâmetros para o modo automático são as seguintes: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: Tamanho da posição para o trade de duas etapas.

· sum: Limite para hedge permitido.

· move (movePct): Limite de flash crash (ex: 0.15 = 15%).

· windowMin: Tempo desde o início de cada round para permitir a execução da Perna 1.

Backtesting

A lógica do bot é simples: espere por um flash crash violento, compre o lado que acabou de cair, depois espere o preço estabilizar e faça hedge comprando o lado oposto, garantindo que priceUP + priceDOWN < 1.

Mas essa lógica precisa ser testada. É realmente eficaz a longo prazo? Mais importante, o bot tem muitos parâmetros (shares, sum, porcentagem de movimento, minutos da janela, etc.). Qual conjunto de parâmetros é ideal e maximiza o lucro?

Meu primeiro pensamento foi ter o bot rodando ao vivo por uma semana e observar os resultados. O problema é que isso leva muito tempo e só pode testar um conjunto de parâmetros, enquanto eu preciso testar muitos.

Meu segundo pensamento foi fazer o backtest usando dados históricos online da API CLOB da Polymarket. Infelizmente, para o mercado BTC 15-minute up/down, o endpoint de dados históricos retorna consistentemente conjuntos de dados vazios. Sem ticks de preço históricos, o backtest não pode detectar um "flash crash de aproximadamente 3 segundos", não pode acionar a Perna 1 e, independentemente dos parâmetros usados, resulta em 0 ciclos e 0% de retorno sobre o investimento (ROI).

Após investigação adicional, descobri que outros usuários também encontraram o mesmo problema ao recuperar dados históricos para certos mercados. Testei outros mercados que de fato retornaram dados históricos e concluí que, para este mercado específico, os dados históricos simplesmente não foram preservados.

Devido a essa limitação, a única maneira confiável de fazer o backtest dessa estratégia é criar meu próprio conjunto de dados históricos gravando os melhores preços ask em tempo real enquanto o bot está rodando.

O gravador escreverá snapshots no disco, incluindo:

· Timestamp

· Slug do round

· Segundos restantes

· ID do token UP/DOWN

· Melhor preço ask UP/DOWN

Posteriormente, o "backtest gravado" reproduzirá esses snapshots e aplicará deterministicamente a mesma lógica automatizada. Isso garante a capacidade de obter os dados de alta frequência necessários para detectar flash crashes e condições de hedge.

Ao longo de 4 dias, coletei um total de 6 GB de dados. Eu poderia ter gravado mais, mas considerei isso suficiente para testar diferentes conjuntos de parâmetros.

Comecei a testar este conjunto de parâmetros:

· Saldo inicial: 1.000 $

· 20 shares por trade

· sumTarget = 0.95

· Limite de flash crash = 15%

· windowMin = 2 minutos

Também apliquei uma taxa constante de 0,5% e um spread de 2% para permanecer em um cenário conservador.

O backtest mostrou um ROI de 86%, transformando 1.000 $ em 1.869 $ em apenas alguns dias.

Em seguida, testei um conjunto de parâmetros mais agressivo:

· Saldo inicial: 1.000 $

· 20 shares por trade

· sumTarget = 0.6

· Limite de flash crash = 1%

· windowMin = 15 minutos

Resultado: Após 2 dias, o investimento teve uma taxa de retorno de -50%.

Isso demonstra claramente que a seleção de parâmetros é o fator mais crítico. Pode fazer você ganhar muito dinheiro ou levar a perdas significativas.

Limitações do backtesting

Mesmo com custos e spreads incluídos, o backtesting tem suas limitações.

· Primeiro, ele usa apenas alguns dias de dados, o que pode não ser suficiente para obter uma perspectiva de mercado abrangente.

· Ele depende de snapshots de preços de venda ideais gravados; na realidade, as ordens podem ser parcialmente preenchidas ou preenchidas a preços diferentes. Além disso, a profundidade do livro de ordens e o volume disponível não são modelados.

· As micro-flutuações sub-segundo não são capturadas (dados amostrados a cada segundo). Embora o backtesting tenha timestamps em nível de 1 segundo, muita coisa pode acontecer entre cada segundo.

· O slippage é constante no backtesting, sem simular atrasos variáveis (ex: 200–1500 milissegundos) ou picos de congestionamento de rede.

· Cada segmento de trade é assumido como executado "instantaneamente" (sem enfileiramento de ordens, sem ordens pendentes).

· Os custos são cobrados uniformemente, enquanto na realidade os custos podem depender de: Mercado/Token, Maker-Taker, níveis de taxas ou condições.

Para manter uma abordagem pessimista (cautelosa), apliquei uma regra: se a Perna 2 não for executada antes do fechamento do mercado, a Perna 1 é considerada uma perda total.

Embora intencionalmente conservadora, isso nem sempre se alinha com a realidade:

· Às vezes, a Perna 1 pode fechar mais cedo,

· Às vezes, acaba in-the-money (ITM) e ganha,

· Às vezes, a perda pode ser parcial em vez de total.

Embora a perda possa ser superestimada, isso fornece um cenário prático de "pior caso".

Mais importante, o backtesting não pode simular o impacto de suas grandes ordens no livro de ordens ou atrair comportamento predatório de outros traders. Na realidade, sua ordem pode:

· Perturbar o livro de ordens,

· Atrair ou repelir outros traders,

· Causar slippage não linear.

O backtesting assume que você é um puro extrator de liquidez (price taker) sem influência.

Por fim, ele não simula limites de taxa, erros de API, rejeições de ordens, paradas, timeouts, reconexões ou situações em que o bot está ocupado e perde sinais.

O backtesting é extremamente valioso para identificar uma boa faixa de parâmetros, mas não é uma garantia de 100%, pois alguns efeitos do mundo real não podem ser modelados.

Infraestrutura

Planejo rodar este bot em um Raspberry Pi para evitar consumir recursos na minha máquina principal e mantê-lo rodando 24/7.

No entanto, ainda há um espaço significativo para melhorias:

· Usar Rust em vez de JavaScript proporcionará muito melhor desempenho e tempo de processamento.

· Rodar um nó RPC Polygon dedicado reduzirá ainda mais a latência.

· Implantar em um VPS próximo ao servidor Polymarket também reduzirá significativamente a latência.

Tenho certeza de que existem outros métodos de otimização que ainda não descobri. Atualmente, estou aprendendo Rust, pois está se tornando uma linguagem essencial no desenvolvimento Web3.

Link do artigo original