¿Yield farming con 86% APY? Cómo usar bots para ganar dinero mientras duermes en Polymarket

Título original: Construí un bot para Polymarket y probé múltiples configuraciones de parámetros, aquí están los resultados.

Autor original: @the_smart_ape, investigador de criptomonedas

Traducción original: Bitpush News

Hace unas semanas, decidí construir mi propio bot para Polymarket. La versión completa me tomó varias semanas completarla.

Estaba dispuesto a hacer este esfuerzo porque, de hecho, existe una brecha de eficiencia en Polymarket. Aunque algunos bots en el mercado ya están aprovechando estas ineficiencias, todavía no es suficiente, y las oportunidades en este mercado son mucho mayores que la cantidad de bots.

Lógica de construcción del bot

La lógica del bot se basa en un conjunto de estrategias que he ejecutado manualmente en el pasado, las cuales automaticé para mejorar la eficiencia. El bot opera en el mercado “BTC 15-minute UP/DOWN”.

El bot ejecuta un programa de monitoreo en tiempo real que puede cambiar automáticamente a la ronda actual de BTC de 15 minutos, optimizando la mejor oferta/demanda a través de un WebSocket, mostrando una interfaz de terminal fija y permitiendo un control integral mediante comandos de texto.

En modo manual, puedes colocar órdenes directamente.

buy up <usd> / buy down <usd>: Comprar una cantidad específica en USD.

buyshares up <shares> / buyshares down <shares>: Comprar una cantidad exacta de acciones, utilizando una orden LIMIT + GTC (Good 'Til Canceled) fácil de usar, ejecutada al mejor precio de venta actual.

El modo automático ejecuta un bucle recurrente de dos etapas.

Primero, solo observa los movimientos de precios dentro de los minutos windowMin al comienzo de cada ronda. Si alguno de los lados cae lo suficientemente rápido (alcanzando un porcentaje de caída de al menos movePct en unos 3 segundos), activa la “Etapa 1”, comprando el lado que experimentó la caída brusca.

Después de completar la Etapa 1, el bot nunca volverá a comprar el mismo lado. Esperará la “Segunda Etapa (Etapa 2, es decir, cobertura)” y solo se activará si se cumple la siguiente condición: leg1EntryPrice + oppositeAsk <= sumTarget.

Cuando se cumple esta condición, compra el lado opuesto. Una vez completada la Etapa 2, el ciclo termina, el bot vuelve al modo de observación, esperando la siguiente señal de caída repentina utilizando los mismos parámetros.

Si hay un cambio en la ronda durante el ciclo, el bot abandona el ciclo abierto y reinicia con la misma configuración en la siguiente ronda.

La configuración de parámetros para el modo automático es la siguiente: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: Tamaño de posición para la operación de dos etapas.

· sum: Umbral para la cobertura permitida.

· move (movePct): Umbral de caída repentina (por ejemplo, 0.15 = 15%).

· windowMin: Tiempo desde el inicio de cada ronda para permitir la ejecución de la Etapa 1.

Backtesting

La lógica del bot es simple: esperar una caída repentina violenta, comprar el lado que acaba de caer, luego esperar a que el precio se estabilice y cubrir comprando el lado opuesto, asegurando que priceUP + priceDOWN < 1.

Pero esta lógica debe probarse. ¿Es realmente efectiva a largo plazo? Más importante aún, el bot tiene muchos parámetros (shares, sum, porcentaje de movimiento, minutos de ventana, etc.). ¿Qué conjunto de parámetros es óptimo y maximiza las ganancias?

Mi primer pensamiento es hacer que el bot funcione en vivo durante una semana y observar los resultados. El problema es que esto lleva demasiado tiempo y solo puede probar un conjunto de parámetros, mientras que necesito probar muchos.

Mi segundo pensamiento es realizar un backtest utilizando datos históricos en línea de la API CLOB de Polymarket. Desafortunadamente, para el mercado de BTC de 15 minutos up/down, el endpoint de datos históricos devuelve constantemente conjuntos de datos vacíos. Sin ticks de precios históricos, el backtest no puede detectar una “caída repentina de aproximadamente 3 segundos”, no puede activar la Etapa 1 y, independientemente de los parámetros utilizados, resulta en 0 ciclos y 0% de retorno de inversión (ROI).

Tras una investigación adicional, descubrí que otros usuarios también encontraron el mismo problema al recuperar datos históricos para ciertos mercados. Probé otros mercados que sí devolvieron datos históricos y concluí que, para este mercado en particular, los datos históricos simplemente no se guardaron.

Debido a esta limitación, la única forma confiable de realizar un backtest de esta estrategia es crear mi propio conjunto de datos históricos registrando los mejores precios de venta en tiempo real mientras el bot está funcionando.

El registrador escribirá instantáneas en el disco, incluyendo lo siguiente:

· Marca de tiempo

· Round Slug

· Segundos restantes

· ID del token UP/DOWN

· Mejor precio de venta UP/DOWN

Posteriormente, el “backtest registrado” reproducirá estas instantáneas y aplicará determinísticamente la misma lógica automatizada. Esto garantiza la capacidad de obtener los datos de alta frecuencia necesarios para detectar caídas repentinas y condiciones de cobertura.

Durante 4 días, recopilé un total de 6 GB de datos. Podría haber registrado más, pero consideré que esto era suficiente para probar diferentes conjuntos de parámetros.

Comencé a probar este conjunto de parámetros:

· Saldo inicial: $1,000

· 20 acciones por operación

· sumTarget = 0.95

· Umbral de caída repentina = 15%

· windowMin = 2 minutos

También apliqué una tarifa constante del 0.5% y un spread del 2% para mantenerme en un escenario conservador.

El backtest mostró un ROI del 86%, convirtiendo $1,000 en $1,869 en solo unos días.

Luego, probé un conjunto de parámetros más agresivo:

· Saldo inicial: $1,000

· 20 acciones por operación

· sumTarget = 0.6

· Umbral de caída repentina = 1%

· windowMin = 15 minutos

Resultado: Después de 2 días, la inversión tuvo una tasa de retorno del -50%.

Esto demuestra claramente que la selección de parámetros es el factor más crítico. Puede hacerte ganar mucho dinero o llevarte a pérdidas significativas.

Limitaciones del backtesting

Incluso con costos y spreads incluidos, el backtesting tiene sus limitaciones.

· En primer lugar, solo utiliza datos de unos pocos días, lo que puede no ser suficiente para obtener una perspectiva completa del mercado.

· Se basa en instantáneas de precios de venta óptimos registrados; en realidad, las órdenes pueden llenarse parcialmente o llenarse a precios diferentes. Además, la profundidad del libro de órdenes y el volumen disponible no están modelados.

· Las micro-fluctuaciones de menos de un segundo no se capturan (datos muestreados cada segundo). Aunque el backtesting tiene marcas de tiempo a nivel de 1 segundo, pueden suceder muchas cosas entre cada segundo.

· El slippage es constante en el backtesting, sin simular retrasos variables (por ejemplo, 200–1500 milisegundos) o picos de congestión de red.

· Se asume que cada segmento de operación se ejecuta “instantáneamente” (sin colas de órdenes, sin órdenes en reposo).

· Los costos se cobran uniformemente, mientras que en realidad, los costos pueden depender de: Mercado/Token, Maker-Taker, niveles de tarifas o condiciones.

Para mantener un enfoque pesimista (cauteloso), apliqué una regla: si la Etapa 2 no se ejecuta antes del cierre del mercado, la Etapa 1 se considera una pérdida total.

Aunque es intencionalmente conservador, esto no siempre se alinea con la realidad:

· A veces, la Etapa 1 puede cerrarse antes,

· A veces termina en dinero (ITM) y gana,

· A veces la pérdida puede ser parcial en lugar de total.

Aunque la pérdida puede estar sobreestimada, esto proporciona un escenario práctico de “peor caso”.

Más importante aún, el backtesting no puede simular el impacto de tus grandes órdenes en el libro de órdenes ni atraer comportamiento depredador de otros traders. En realidad, tu orden puede:

· Interrumpir el libro de órdenes,

· Atraer o repeler a otros traders,

· Causar un slippage no lineal.

El backtesting asume que eres un extractor de liquidez puro (price taker) sin influencia.

Por último, no simula límites de tasa, errores de API, rechazos de órdenes, pausas, tiempos de espera, reconexiones o situaciones en las que el bot está ocupado y pierde señales.

El backtesting es extremadamente valioso para identificar un buen rango de parámetros, pero no es una garantía del 100% ya que algunos efectos del mundo real no se pueden modelar.

Infraestructura

Planeo ejecutar este bot en una Raspberry Pi para evitar consumir recursos en mi máquina principal y mantenerlo funcionando 24/7.

Sin embargo, todavía hay un margen significativo para mejorar:

· Usar Rust en lugar de JavaScript proporcionará un rendimiento y tiempo de procesamiento mucho mejores.

· Ejecutar un nodo RPC de Polygon dedicado node reducirá aún más la latencia.

· Desplegar en un VPS cerca del servidor de Polymarket también reducirá significativamente la latencia.

Estoy seguro de que hay otros métodos de optimización que aún no he descubierto. Actualmente, estoy aprendiendo Rust ya que se está convirtiendo en un lenguaje esencial en el desarrollo Web3.

Enlace al artículo original