Bots de mercados de predicción: construir una simulación

Qué hace un bot de mercados de predicción en modo simulación

Un bot de mercados de predicción es un programa que lee datos públicos de mercados (preguntas, resultados posibles, precios, liquidez) y aplica reglas para decidir qué señales merecen seguimiento. Un dry-run o simulación significa que el bot observa, registra y calcula rellenos hipotéticos, pero no envía órdenes reales ni toca claves, wallets o endpoints de trading. La separación importa: los endpoints públicos de descubrimiento y detalle son de solo lectura y no piden autenticación, mientras que la autenticación de trading es otra capa que aquí no se usa. Si quieres entender primero cómo se estructuran esos endpoints, la guía de la API de mercados de predicción cubre el mapa de lectura pública.

Antes de escribir la lógica de señales fija 3 reglas de entrada: validar que el mercado siga activo y abierto, guardar la fecha de observación de cada precio y descartar datos ausentes o viejos. Un campo vacío no es cero y un timeout de la API no es un precio de cero. Si el bot convierte ausencia en precio bajo, produce señales falsas y luego resultados simulados que no significan nada.

Leer metadatos públicos sin claves ni wallets

El descubrimiento de mercados usa eventos con parámetros como active=true y closed=false, junto con un límite y un cursor de paginación. La respuesta trae eventos más un next_cursor, así que el bot pagina hasta agotarlo. Los identificadores de tokens de resultado son distintos de los identificadores de evento o condición, por lo que cada outcome necesita su propio mapeo antes de razonar sobre precios.

El detalle de mercado incluye pregunta, outcomes, outcomePrices, clobTokenIds, actividad, cierre, aceptación de órdenes, liquidez y volumen. Algunos de esos campos llegan serializados como arrays y requieren parsing. Conserva siempre la fecha de observación: volumen y liquidez miden cosas distintas y no se sustituyen entre sí, y un valor viejo o ausente nunca se reemplaza por cero.

Cotizaciones, profundidad y slippage en la simulación

El precio que se muestra suele ser el punto medio entre el mejor bid y el mejor ask. Cuando el spread supera 0,10, se muestra el último trade. Ese punto medio no es una garantía ejecutable: las órdenes a mercado consumen varios niveles de precio y generan slippage, por lo que la profundidad del libro y la fecha de observación forman parte del dato.

Para el dry-run declara supuestos explícitos: por ejemplo, un relleno simulado al mejor ask más un coste fijo de slippage, o un límite de tamaño que no consuma más de un nivel de precio. Si no puedes estimar profundidad, marca el relleno como incierto en lugar de inventarlo. El coste de slippage no aparece en el punto medio y puede convertir una señal aparentemente rentable en una operación perdedora.

Señal hipotética y reconciliación de decisiones repetidas

Cada señal se registra con un identificador compuesto: evento, mercado y decisión. Si la misma señal aparece 2 veces, es una sola decisión, no 2 rellenos rentables. Este detalle evita inflar el rendimiento cuando el bucle de sondeo vuelve a ver el mismo mercado sin cambios. El identificador sobrevive entre ciclos mientras el evento, el mercado y la regla disparada sigan siendo los mismos.

El protocolo de parada es tan importante como la señal. El bot se detiene si faltan datos, si el precio está viejo según tu umbral declarado, si el mercado está cerrado o ya no acepta órdenes, o si el spread supera el límite que fijaste. Un relleno simulado solo cuenta como válido dentro de esas condiciones.

Ejemplo trabajado: misma señal 2 veces produce una sola decisión

Supón que el bot sondea cada minuto y encuentra el mismo mercado activo a las 10:00 y a las 10:01, con el mismo token de resultado y la misma regla disparada. Con un decision_id estable formado por evento más mercado más regla, el segundo avistamiento se descarta como duplicado. El recuento correcto es una decisión y un relleno hipotético, no 2. Si a las 10:02 la API responde con timeout, ese hueco se marca como dato ausente y no se interpreta como precio cero ni como nueva señal.

Qué no valida una simulación y cuándo conviene pasar a otra fase

Una simulación no valida latencia real, colas de ejecución, reacción de otros participantes ni tu propia capacidad de cancelar a tiempo. Tampoco convierte un punto medio en precio ejecutable: spread, profundidad y slippage pueden cambiar entre la observación y cualquier orden futura. Los ejemplos de API son instantáneas de solo lectura y no autorizan a operar.

Antes de reutilizar el bot con capital real, separa por completo la capa de lectura pública de cualquier autenticación, revisa los riesgos operativos específicos de mercados de predicción y contrasta la lógica de simulación contra datos históricos con la guía de backtest de estrategias. Si el bot ya funciona en simulación y quieres ampliar la parte de datos públicos, la guía de riesgos en mercados de predicción te ayuda a identificar los fallos que la simulación no cubre.