Tutorial de Bot de Polymarket · Capítulo 15 de 32
Bots de microestructura deportiva en Polymarket: edge en vivo, mispricing impulsado por el marcador, la tag de NBA (745) y la tag de Tennis (864), fuentes de datos en tiempo real y patrones de ejecución para mercados deportivos de alta frecuencia.
Qué cubre este capítulo
Los mercados deportivos son el segmento no político más consistentemente activo en Polymarket. Los bots que funcionan se dividen en dos categorías claras: detectores de líneas pregame que operan una vez que la línea ya está establecida, y bots de microestructura in-game que reaccionan al movimiento del order book durante el partido. Este capítulo cubre ambos con los IDs de tag, fuentes de datos y presupuestos de latencia específicos que aplican a cada uno.
Los mercados deportivos son el segmento no político con más actividad en Polymarket. El patrón de ejecución que funciona combina un feed de score en vivo (ESPN, PandaScore) con señales de microestructura del order book. Este capítulo cubre qué funciona específicamente para NFL, NBA, soccer y tennis, y en qué se diferencia esports.
- Por qué los mercados deportivos son tradables
- Pregame vs in-game (bots distintos)
- IDs de tag verificados (745 NBA, 864 Tennis)
- Fuentes de datos: ESPN, APIs oficiales, pantalla
- Presupuesto de latencia para in-game
- La trampa de 0.99 / 0.01
- Código: suscribirse a un games book y reaccionar
Por qué los mercados deportivos son tradables
Los mercados deportivos cierran en plazos definidos (de horas a días), tienen datos públicos en vivo y atraen flujo continuo de órdenes durante los partidos. Las tres condiciones son necesarias para que un mercado sea tradable - los mercados políticos no tienen "plazo definido", los mercados de clima no tienen "flujo continuo" y los torneos poco conocidos no tienen "datos públicos en vivo".
La población de traders en mercados deportivos también es más diversa que en, por ejemplo, los mercados electorales. Los apostadores casuales de deportes ponen precio de forma emocional; los traders informados corrigen hacia el fair value a lo largo del partido. La diferencia entre ambos es el edge del bot.
La distribución del volumen es desigual: un domingo de NFL puede rotar cientos de millones de dólares a través de los mercados deportivos de Polymarket; un partido de la Saudi Pro League un martes por la noche quizá no llegue a $50k. Dimensiona tu estrategia según dónde esté realmente la acción.
Pregame vs in-game (bots distintos)
Dos diseños de bot fundamentalmente distintos.
Pre-game line-catcher: escanea mercados que acaban de abrir, identifica líneas mal valuadas contra tu modelo o contra la línea de una casa/venue más eficiente, y coloca una compra FOK. Mantiene la posición hasta el in-play, a veces hasta la resolución. Velocidad: minutos, no segundos. Edge: modelo + line shopping.
In-game microstructure: se suscribe al WebSocket del order book de un partido en vivo y reacciona a señales de desbalance + eventos de score en segundos. Velocidad: segundos, no minutos. Edge: latencia + lectura del order flow.
Ambos comparten casi nada de código. Tienen perfiles de riesgo distintos, fuentes de datos distintas y estrategias de salida distintas. Un bot que intenta hacer ambas cosas termina sin hacer bien ninguna; elige una.
IDs de tag verificados (745 NBA, 864 Tennis)
IDs de tag de producción verificados en mayo de 2026 para las principales categorías deportivas. Úsalos para filtrar llamadas a /events de forma eficiente.
| Deporte / Liga | Tag ID | Slug del tag | Notas |
|---|---|---|---|
| NBA | 745 | nba | mayor volumen Oct-Jun |
| NFL | 450 | nfl | pico Dom/Lun Sep-Feb |
| Tennis (all) | 864 | tennis | todo el año, por cadencia de torneos |
| Soccer (general) | 1059 | soccer | combinar con sub-tags abajo |
| EPL | 739 | epl | |
| UCL | 2186 | uefa-champions-league | |
| Esports (all) | 702 | esports | LoL+CS2+Valorant+Dota |
| MLB | 1245 | mlb | pico Apr-Oct |
| NHL | 823 | nhl | pico Oct-Jun |
Los IDs de tag son estables a lo largo de los años. Se agregan tags nuevos (Saudi Pro League, IPL), pero los antiguos no se renumeran.
Fuentes de datos: ESPN, APIs oficiales, pantalla
Para deportes tradicionales, la API gratuita de scoreboard de ESPN cubre todo lo que necesitas: scores, periodo/reloj, probabilidad de victoria y, a veces, ubicación del tiro. No requiere key; solo tiene rate limit a nivel IP. Patrón de endpoint: https://site.api.espn.com/apis/site/v2/sports/<sport>/<league>/scoreboard.
Para esports, ESPN no tiene cobertura. Opciones: PandaScore ($30-60/mes, el estándar de la industria), HLTV (solo CS2, se puede scrape a, sin API), Liquipedia (mantenido por la comunidad, scrapeable, con cadencia de actualización más lenta).
Los feeds en pantalla (pagar por un stream de TV y leer el scorebug con OCR) funcionan, pero son pesados operativamente. Se recomiendan solo si tienes una estrategia que requiere actualizaciones por debajo de 3 segundos en un deporte que ninguna API cubre en tiempo real.
Presupuesto de latencia para in-game
El presupuesto de latencia end-to-end para un bot reactivo in-game.
- Ocurre el evento de score: t=0
- El feed de origen lo refleja: t+3-15s (ESPN: ~10s; PandaScore: ~3s)
- Tu bot lee el feed: t+10-16s
- El bot decide la acción: +50ms
- La orden FOK se coloca: +200-500ms
- Se ejecuta en el CLOB: +300-1000ms (red + matching)
Total: 11-17 segundos. Las firmas profesionales más rápidas logran 3-5 segundos end-to-end con feeds premium pagos y VPS co-localizado. Los bots retail que corren en hosts estándar y con ESPN gratis quedan en el extremo más lento.
Las estrategias que necesitan menos de 5 segundos no son viables para retail. Las que sí funcionan en la ventana de 10-17 segundos son: capturar desajustes después de un score, fade de sobrerreacciones, y jugadas de certeza al final del partido.
La trampa de 0.99 / 0.01
El fallo más común de los bots deportivos in-play: comprar al favorito fuerte en 0.99 con un minuto por jugar, esperando un fácil +1¢. Hay tres razones por las que falla.
Primero, la probabilidad implícita del 1% del underdog no es cero - los regresos tardíos ocurren con frecuencia no trivial. Una victoria 99.5% segura, operada 200 veces, produce una pérdida para el tamaño de posición completo.
Segundo, el spread en 0.99/0.01 significa que pagas 99c por share, ganas 1c si sale bien y pierdes 99c en la rara reversión. La relación riesgo-recompensa es brutal.
Tercero, el bot que usa una venta GTC a 0.999 casi nunca se ejecuta - no hay compradores a ese precio. La posición se va hasta la resolución. Si gana, obtuviste 1c. Si ocurre la reversión, pierdes 99c.
La trampa es dinero real perdido por builders que no hicieron las cuentas. Mantente fuera de mercados con precio de 0.95+ salvo que tu estrategia esté diseñada específicamente para el perfil de redemption-arbitrage.
Código: suscribirse a un games book y reaccionar
Referencia: suscribirse al WebSocket de un partido específico de NBA, registrar actualizaciones del book y disparar FOK ante una señal de desbalance.
import websocket, json
THRESHOLD = 0.5 # imbalance level to trigger
def on_message(ws, message):
msg = json.loads(message)
if msg.get("event_type") != "book": return
bids = msg.get("bids", [])
asks = msg.get("asks", [])
bid_depth = sum(float(b["price"]) * float(b["size"]) for b in bids[:5])
ask_depth = sum(float(a["price"]) * float(a["size"]) for a in asks[:5])
total = bid_depth + ask_depth
if total < 100: return # too illiquid
imb = (bid_depth - ask_depth) / total
if abs(imb) > THRESHOLD:
print(f"signal imb={imb:.2f} bid={bid_depth:.0f} ask={ask_depth:.0f}")
# fire FOK here
ws = websocket.WebSocketApp(
"wss://ws-subscriptions-clob.polymarket.com/ws/market",
on_open=lambda ws: ws.send(json.dumps({"type":"Market","markets":["<CONDITION_ID>"]})),
on_message=on_message
)
ws.run_forever()Adiciones de producción: cooldown entre disparos, límite de inventario por token, matar si el book queda stale (sin mensajes en 30s).
