Una desarrolladora comparte cómo construir un robot de trading para Polymarket, capturando las fluctuaciones de precios en el mercado de BTC de 15 minutos, convirtiendo $1,000 en $1,869 en unos días, con una rentabilidad de prueba del 86%. El artículo detalla la lógica de construcción del robot, el método de backtesting y sus limitaciones.
(Resumen previo: Polymarket, líder en mercados predictivos, anuncia su propia capa L2, ¿se acaba la carta de Polygon?)
(Información adicional: ¿Cómo obtener un rendimiento anual del 40% mediante arbitraje en Polymarket?)

Índice del artículo

• Lógica de construcción del robot
• Backtesting
• Limitaciones del backtesting
• Infraestructura

Hace unas semanas, decidí construir mi propio robot para Polymarket. La versión completa me llevó varias semanas.

Estoy dispuesto a dedicar este esfuerzo porque en Polymarket existen realmente vulnerabilidades de eficiencia. Aunque ya hay algunos robots aprovechando estas ineficiencias para obtener beneficios, todavía están lejos de cubrir toda la oportunidad, ya que el mercado ofrece muchas más oportunidades que la cantidad de robots existentes.

Lógica de construcción del robot

La lógica del robot se basa en una estrategia que ejecutaba manualmente en el pasado. Para mejorar la eficiencia, la automaticé. El robot opera en el mercado de «BTC 15 minutos UP/DOWN».

El robot ejecuta un programa de monitoreo en tiempo real, que puede cambiar automáticamente a la ronda actual de BTC de 15 minutos, transmitiendo los mejores precios de compra/venta (best bid/ask) mediante WebSocket, mostrando una interfaz fija en el terminal y permitiendo control total mediante comandos de texto.

En modo manual, puedes colocar órdenes directamente.

buy up / buy down : compra una cantidad específica en dólares.

buyshares up / buyshares down : compra una cantidad exacta de acciones, usando órdenes LIMIT (limitadas) + GTC (válidas hasta cancelación) con la mejor oferta de venta (best ask), ejecutándose a ese precio.

En modo automático, funciona con un ciclo repetitivo de dos etapas (two-leg).

Primero, solo observa la volatilidad en cada ventana de minutos (windowMin). Si alguna de las partes cae lo suficientemente rápido (en unos 3 segundos, con una caída de al menos movePct), se activa la «Primera etapa (Leg 1)», comprando la parte que cae bruscamente.

Tras completar Leg 1, el robot no volverá a comprar en ese mismo lado. Esperará a la «Segunda etapa (Leg 2, es decir, cobertura)», que solo se activará si se cumple la condición: leg1EntryPrice + oppositeAsk <= sumTarget.

Cuando se cumple, compra la otra parte. Tras completar Leg 2, el ciclo termina y el robot vuelve a un estado de observación, esperando la próxima señal de caída con los mismos parámetros.

Si durante el ciclo cambian las rondas, el robot abandona ese ciclo abierto y comienza uno nuevo en la siguiente ronda con la misma configuración.

Los parámetros en modo automático son: auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares: tamaño de la posición en ambas etapas.
• sum: umbral para la cobertura.
• move (movePct): umbral de caída (por ejemplo, 0.15 = 15%).
• windowMin: duración en minutos desde el inicio de cada ronda para ejecutar Leg 1.

Backtesting

La lógica del robot es sencilla: esperar una caída violenta, comprar la parte que acaba de caer, esperar a que el precio se estabilice y cubrirse comprando en la otra dirección, asegurando que: priceUP + priceDOWN < 1.

Pero esta lógica necesita ser probada. ¿Es realmente efectiva a largo plazo? Más importante aún, el robot tiene muchos parámetros (número de acciones, suma total, porcentaje de movimiento, minutos de ventana, etc.). ¿Qué conjunto de parámetros es el óptimo para maximizar beneficios?

Mi primera idea fue dejar que el robot operara en vivo durante una semana y observar los resultados. El problema es que esto lleva mucho tiempo y solo permite probar un conjunto de parámetros a la vez, mientras que necesito probar muchos.

Mi segunda idea fue usar datos históricos en línea del API CLOB de Polymarket para hacer backtesting. Pero, desafortunadamente, para el mercado de BTC de 15 minutos UP/DOWN, el endpoint de datos históricos siempre devuelve un conjunto vacío. Sin datos de precios históricos (ticks), no se puede detectar una caída de aproximadamente 3 segundos, por lo que no se puede activar Leg 1, independientemente de los parámetros, resultando en ciclos y ROI de 0%.

Tras investigar más, descubrí que otros usuarios también han tenido problemas para obtener datos históricos en ciertos mercados. Probé en otros mercados que sí devuelven datos y concluí que, en este mercado en particular, los datos históricos simplemente no se conservan.

Debido a esta limitación, la única forma confiable de backtestear esta estrategia es, durante la ejecución del robot, registrar en tiempo real los mejores precios de venta (best-ask) para crear mi propio conjunto de datos históricos.

El registrador toma instantáneas y las guarda en disco, incluyendo:

• Marca de tiempo
• Identificador de ronda (round slug)
• Segundos restantes
• ID del token UP/DOWN
• Mejor precio de venta UP/DOWN

Luego, el «backtest grabado (recorded backtest)» reproduce estas instantáneas y aplica de forma determinista la misma lógica automática. Esto garantiza que se puedan detectar caídas y condiciones de cobertura con datos de alta frecuencia.

En 4 días, recopilé 6 GB de datos. Podría haber registrado más, pero considero que esto es suficiente para probar diferentes conjuntos de parámetros.

Comencé a probar estos parámetros:

• Balance inicial: $1,000
• 20 acciones por operación
• sumTarget = 0.95
• Umbral de caída = 15%
• windowMin = 2 minutos

También apliqué una tarifa fija del 0.5% y un spread del 2% para mantener un escenario conservador.

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

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

• Balance inicial: $1,000
• 20 acciones por operación
• sumTarget = 0.6
• Umbral de caída = 1%
• windowMin = 15 minutos

Resultado: en 2 días, la rentabilidad fue -50%.

Esto demuestra claramente que la elección de parámetros es crucial. Puede hacerte ganar mucho dinero o causar pérdidas significativas.

Limitaciones del backtesting

Incluso considerando tarifas y spreads, el backtesting tiene sus limitaciones.

• Primero, usa solo unos días de datos, lo cual puede no ser suficiente para una visión completa del mercado.
• Depende de snapshots de los mejores precios de venta; en realidad, los órdenes pueden ejecutarse parcialmente o a diferentes precios. Además, no se modela la profundidad del libro ni el volumen disponible.
• No captura microfluctuaciones por debajo de un segundo (los datos se muestrean cada segundo). Aunque los timestamps son de 1 segundo, entre cada segundo pueden ocurrir muchas cosas.
• En el backtest, el deslizamiento (slippage) es constante, sin simular latencias variables (200–1500 ms) o picos de red.
• Cada operación se asume ejecutada «en tiempo real» (sin colas de órdenes, sin órdenes pendientes).
• Las tarifas se aplican uniformemente, pero en realidad pueden variar según mercado/token, creador de órdenes, nivel de tarifa, condiciones, etc.

Para ser conservador, apliqué una regla: si Leg 2 no se ejecuta antes del cierre del mercado, se considera una pérdida total (total loss).

Esto es deliberadamente conservador, pero no siempre refleja la realidad:

• A veces, Leg 1 puede cerrarse anticipadamente,
• O puede terminar en el dinero (ITM) y ganar,
• O la pérdida puede ser parcial en lugar de total.

Aunque las pérdidas pueden estar sobreestimadas, esto proporciona un escenario de «peor caso» útil.

Lo más importante es que el backtest no puede simular el impacto de tus órdenes grandes en el libro ni cómo otros traders reaccionan a tus movimientos. En realidad, tus órdenes pueden:

• Alterar el libro de órdenes,
• Atraer o repeler a otros traders,
• Causar slippage no lineal.

El backtest asume que eres un «price taker» puro, sin impacto en el mercado.

Por último, no simula limitaciones de frecuencia (rate limits), errores en la API, órdenes rechazadas, pausas, timeouts, reconexiones, o que el robot esté ocupado y pierda señales.

El backtest es muy valioso para identificar rangos de parámetros adecuados, pero no garantiza resultados del 100%, ya que algunos efectos del mundo real no se pueden modelar.

Infraestructura

Planeo ejecutar el robot en una Raspberry Pi para evitar consumir recursos de mi máquina principal y mantenerlo en funcionamiento 24/7.

Pero aún hay margen para mejoras significativas:

• Usar Rust en lugar de JavaScript ofrecerá un rendimiento y tiempos de respuesta mucho mejores.
• Ejecutar un nodo RPC dedicado de Polygon reducirá aún más la latencia.
• Desplegar en un VPS cercano a los servidores de Polymarket también disminuirá la retardo.

Seguramente hay otras optimizaciones que aún no he descubierto. Actualmente, estoy aprendiendo Rust, ya que se está convirtiendo en un lenguaje imprescindible en el desarrollo Web3.

#####