Bot de contratos de eventos: de los datos a la conciliación

Un bot de contratos de eventos necesita un registro de contratos

Empieza con un registro explícito de los contratos que el bot puede considerar. Guarda el contexto de la plataforma, el identificador de mercado, los identificadores de resultados, la unidad de liquidación y la referencia de las reglas. Añade el momento del evento, el cierre de negociación y la fuente indicada en el contrato. El registro debe distinguir una publicación inicial de un valor revisado y conservar la versión de la correspondencia utilizada en cada decisión.

Este registro es más preciso que un resultado de búsqueda que contiene un título de mercado. Una búsqueda automatizada puede descubrir un contrato candidato, pero el descubrimiento no debe autorizar silenciosamente el trading. Dos mercados pueden compartir un titular y utilizar umbrales o ventanas de observación diferentes. Una correspondencia revisada por una persona o un proceso probado de comparación de reglas debe establecer que los datos que recibe el bot responden a la pregunta que liquida el contrato.

Trata un cambio en la correspondencia como un evento significativo del sistema. Si un campo previamente reconocido deja de estar disponible, el bot no debe elegir un campo de nombre similar simplemente porque mantiene el flujo en funcionamiento. Si aparece una aclaración del contrato, conserva la interpretación antigua y registra la revisión de la información nueva. Ese historial es necesario para entender por qué se abrió una posición anterior bajo supuestos que pueden cambiar después.

La guía anterior sobre la API de bots de mercados de predicción ayuda a identificar la conexión entre identificadores de contratos y acciones de cuenta. Un registro no es solo una comodidad para programar. Es el límite que impide que una señal de un evento se dirija a una posición superficialmente similar pero económicamente distinta.

Mantén la observación separada de la interpretación

La capa de observación registra qué informó una fuente y cuándo lo recibió el sistema. No debe convertir inmediatamente cada actualización en una señal de trading. Conserva la marca temporal de la fuente, la de recepción, el identificador y el valor pertinente exacto. Si un mensaje se repite, márcalo como la misma observación en lugar de una segunda confirmación independiente. Si los mensajes llegan desordenados, conserva esa información de orden en vez de sobrescribir una observación más reciente con una más antigua.

La capa de interpretación decide qué significa la observación para el contrato. Un informe de que un índice es igual a 100.3 puede respaldar Yes para un umbral por encima de 100.2, pero solo si se refiere a la publicación, el campo y el tratamiento de redondeo correctos. Un titular que dice que el índice superó las expectativas es insuficiente cuando el contrato pregunta por un valor absoluto. Un analizador debe extraer el hecho pertinente para el contrato en lugar de un sentimiento general positivo o negativo.

Algunos datos respaldan una estimación de probabilidad en lugar de una determinación factual directa. El programa debe etiquetar ese resultado como pronóstico y conservar su incertidumbre. Un valor de confianza devuelto por un modelo de lenguaje o un clasificador no es automáticamente una probabilidad calibrada de que el contrato pague. Si la interpretación requiere un juicio jurídico o factual novedoso, el sistema puede remitirla a revisión sin conceder al modelo autoridad para crear exposición.

Una vista de diagnóstico útil muestra la observación original junto a la afirmación derivada. Cuando un operador cuestiona una decisión, debe poder inspeccionar esa conexión sin reconstruirla a partir de un gráfico de precios. Esto también facilita aislar fallos de las fuentes: una observación desactualizada, una extracción incorrecta y un pronóstico razonable pero fallido son problemas diferentes que requieren soluciones diferentes.

Define la autoridad de decisión del bot de contratos de eventos

La fase de recomendación propone una acción con un contrato, lado, cantidad, límite de precio y motivo. La fase de autorización decide si esa propuesta encaja con las restricciones actuales de la cuenta. Estas fases deben estar separadas incluso en un programa pequeño. Una estrategia puede recomendar comprar cuando la cuenta ya está en su límite de eventos, mientras otra orden sigue sin resolverse o mientras la fuente de mercado se ha vuelto demasiado antigua para respaldar el precio propuesto.

Un registro de autorización debe indicar los límites que comprobó. Pueden incluir coste máximo de adquisición, exposición máxima al evento, número máximo de órdenes abiertas y un requisito de que la correspondencia del contrato siga vigente. El resultado es un permiso acotado con caducidad, no una instrucción indefinida para seguir intentando hasta obtener la cantidad deseada. Si cambian las condiciones antes del envío, el ejecutor debe solicitar una decisión nueva o rechazar la acción.

Por ejemplo, una estrategia ficticia recomienda 100 unidades Yes con un límite de compra de $0.56 y una reserva adicional de $2 para cargos. El control de riesgo de la cuenta permite como máximo $60 de compromiso para este evento. El compromiso máximo propuesto es $58, por lo que encaja en esa restricción particular. Aun así puede incumplir otra restricción, como una orden sin resolver en el mismo mercado o la falta de una marca temporal de la fuente oficial.

La distinción se vuelve especialmente importante cuando un bot realiza varias tareas. Un módulo de investigación puede añadir contratos a una lista de seguimiento, pero no debe obtener permiso de trading simplemente porque comparte proceso con el ejecutor. Un módulo de notificaciones puede alertar a una persona de un diferencial inusual, pero esa alerta no autoriza una estrategia nueva. Los permisos explícitos impiden que observaciones útiles se conviertan en instrucciones accidentales de cuenta.

Reserva exposición antes de enviar nada

La reserva de exposición de un bot de contratos de eventos impide que varias decisiones simultáneas gasten la misma capacidad. Cuando se autorice una instrucción, reserva su coste máximo permitido y la exposición pertinente al evento antes de enviarla. Mantén la reserva mientras la orden esté abierta o su resultado sea incierto. Libera solo la parte que los registros autorizados establezcan que ya no puede ejecutarse.

Supón que la orden ficticia de 100 unidades empieza a ejecutarse. Cuarenta unidades se ejecutan a $0.54 y cuestan $21.60 antes de cargos. Sesenta unidades siguen abiertas con un límite de $0.56, lo que representa hasta $33.60 de coste adicional de compra. Manteniendo la reserva de comisiones de $2, el compromiso combinado es $57.20. El precio inferior de la parte ejecutada reduce el compromiso desde los $58 originales, pero la parte no ejecutada sigue siendo una posible posición futura.

Si el presupuesto de efectivo pertinente de la cuenta es $100, esta reserva simplificada deja $42.80 sin comprometer. No deja $78.40 simplemente porque hasta ahora solo se hayan gastado $21.60. Esa cifra mayor ignoraría la orden abierta y podría permitir que otra estrategia consuma dinero ya necesario para una posible ejecución. Las implementaciones reales también deben conciliar las comisiones reales y cualquier comportamiento de reservas específico de la plataforma.

Utiliza una visión compartida de la exposición entre las estrategias que operan la misma cuenta. Programas separados con contadores independientes pueden creer cada uno que la cuenta tiene capacidad abundante. El análisis anterior sobre automatización del trading en mercados de predicción ofrece contexto para coordinar estas responsabilidades. El sistema de reservas debe fallar de manera conservadora cuando no pueda determinar si otra instrucción sigue siendo capaz de ejecutarse.

Modela las órdenes como estados, no como mensajes de éxito

Una solicitud de orden puede estar preparada, enviada, reconocida, en espera, parcialmente ejecutada, completada, rechazada, cancelada o incierta. Son estados conceptuales, no una afirmación de que todas las API utilizan exactamente esos nombres. Vincula las respuestas reales de la plataforma con un modelo local documentado. Conserva la respuesta original junto a la interpretación para poder investigar después un error del adaptador.

Una respuesta satisfactoria de red puede establecer que se aceptó una solicitud sin establecer que se ejecutó la cantidad prevista. A la inversa, un tiempo de espera de red puede agotarse después de que la plataforma haya aceptado una orden. El bot debe evitar tratar cada éxito como una posición completada y cada tiempo de espera agotado como un rechazo. Los identificadores de órdenes, registros de ejecuciones e instantáneas de cuenta aportan pruebas distintas sobre lo que ocurrió realmente.

La documentación actual del ciclo de vida de órdenes de Polymarket distingue estados de órdenes y de operaciones. Esa distinción ilustra por qué un único booleano local llamado completed es insuficiente. Una implementación debe seguir los estados de su plataforma y producto específicos, incluidos los estados intermedios de ejecución o liquidación que sigan sin resolverse después de informar una casación.

El ejecutor también debe conservar la instrucción autorizada original. Si una orden se ejecuta a mejor precio, la posición resultante debe seguir siendo trazable al mismo permiso. Si la cantidad restante necesita un precio mayor, eso es una decisión nueva que requiere autorización según las reglas de la estrategia. Aumentar silenciosamente un límite para completar el objetivo convierte un ejecutor controlado en un componente de estrategia sin revisión.

Los estados de recuperación del bot evitan exposición duplicada

Considera un envío cuya respuesta nunca llega al bot. El registro local sabe que se envió un intento pero no sabe si se convirtió en una orden. El siguiente estado correcto es incierto. Mantén la reserva de exposición e inspecciona la plataforma utilizando los identificadores y registros de cuenta admitidos que puedan resolver el intento. No crees una orden nueva simplemente porque falta la primera respuesta.

Supón que la instrucción original solicitaba 100 unidades. Los registros de cuenta revelan después 40 ejecutadas y 60 aún abiertas. El bot solicita cancelar el resto, pero otras 15 unidades se ejecutan antes de que la cancelación sea efectiva. La posición conciliada es de 55 unidades, con 45 unidades ya no abiertas una vez confirmada la cancelación. Si el bot hubiera supuesto que falló el intento original y hubiera enviado otra orden de 100 unidades, podría haber superado sustancialmente su exposición prevista.

La recuperación debe persistir a través de reinicios del proceso. Escribe el identificador del intento y la reserva antes del flujo controlado de envío o como parte de él, según el diseño de consistencia del sistema. Al reiniciar, inspecciona los intentos sin resolver antes de aceptar recomendaciones nuevas para la misma exposición. Un inicio limpio del programa no implica una cuenta limpia. La plataforma todavía puede mantener órdenes creadas por el proceso anterior.

La guía sobre automatización de contratos de eventos extiende esta distinción al flujo circundante de investigación y revisión. La recuperación no es solo un detalle de ingeniería para interrupciones poco frecuentes. Forma parte del control de exposición de la estrategia porque la cuenta puede cambiar mientras el sistema local está desconectado, reiniciándose o esperando una respuesta.

Construye un bucle de conciliación independiente de la estrategia

Un proceso de conciliación compara las expectativas locales con los registros autorizados de la cuenta. Debe ejecutarse aunque no se genere ninguna señal nueva. Compara órdenes abiertas, cantidades ejecutadas, posiciones, cargos y saldos disponibles utilizando identificadores y momentos de observación coherentes. Una discrepancia debe producir una excepción explícita en lugar de corregirse silenciosamente de una manera que borre el historial de cómo el modelo local se volvió incorrecto.

Separa las diferencias temporales ordinarias de las discrepancias sin explicar. Una actualización de ejecución puede llegar antes que la actualización correspondiente del saldo, según el recorrido de información de la plataforma. El sistema puede permitir un estado temporal documentado mientras espera una instantánea coherente. Sin embargo, una discrepancia que persiste más allá del proceso esperado debe bloquear nueva exposición en el alcance afectado hasta que se explique. El alcance puede ser un mercado, una cuenta o todo el ejecutor.

El registro de conciliación debe indicar qué observaciones respaldan la posición actual. Un operador debe poder ver que 55 unidades proceden de dos ejecuciones de 40 y 15, no de una diferencia inferida entre saldos redondeados. Conserva los ajustes de comisiones por separado para que un cambio de efectivo no se confunda con un cambio en la cantidad de contratos. Tras la resolución, conecta el pago con la posición real restante y el resultado final del contrato.

Quienes construyan sobre una interfaz de cuenta pueden utilizar el análisis anterior del bot de trading con la API de Kalshi para organizar los registros necesarios. El principio es independiente del lenguaje de implementación: la estrategia propone qué debería suceder, mientras la conciliación establece qué sucedió. No debe permitirse que ninguna de las funciones sustituya las pruebas faltantes por sus propias expectativas.

Añade límites a los sistemas de varias patas y de cotización

Un bot direccional a menudo puede expresar su exposición mediante una sola posición. Un sistema de varias patas necesita seguir si la combinación prevista está completa y qué queda si solo algunas órdenes se ejecutan. Un candidato de arbitraje de contratos de eventos depende de pagos compatibles y de una ejecución viable. El bot debe representar cada pata y los posibles resultados combinados, en lugar de registrar un par como completo cuando se acepta la primera orden.

Reserva capacidad para las patas sin terminar y define un tiempo o una condición máximos para permanecer sin emparejar. Si la segunda pata deja de estar disponible, el sistema necesita una respuesta predefinida coherente con los límites de pérdida de la cuenta. Esa respuesta podría incluir cancelar órdenes no ejecutadas, reducir la primera posición o mantener una exposición acotada para revisión. No debe suponer que cualquier cobertura a cualquier precio es automáticamente preferible a una decisión ordenada.

Un sistema de cotización afronta un reto distinto: ambos lados pueden seguir activos mientras las ejecuciones cambian el inventario. Por tanto, un creador de mercado de contratos de eventos necesita permisos que tengan en cuenta el inventario y una visión fiable de las cotizaciones pendientes. Una actualización de cotización que sustituye una orden antigua debe tener en cuenta cualquier intervalo durante el que ambas instrucciones puedan seguir activas. La exposición bruta y neta permitida del sistema debe reflejar esa posibilidad.

Estas extensiones ilustran por qué una función genérica de compra o venta no es una arquitectura completa de bot. Distintas estrategias necesitan representaciones distintas del trabajo incompleto. La base común es la autoridad explícita, la identidad de orden conservada y la conciliación; la capa específica de estrategia describe qué combinaciones de ejecuciones son aceptables y qué pruebas se requieren antes de la siguiente acción.

Sigue los relojes que gobiernan una decisión

Un bot debe conservar varios relojes porque responden preguntas diferentes. La marca temporal de la fuente del evento describe cuándo se publicó la información. La de recepción describe cuándo la obtuvo el proceso local. La del libro describe el estado de mercado utilizado para la recomendación. La de autorización describe cuándo la cuenta aprobó una acción. Fusionarlas en un único campo temporal puede ocultar una observación desactualizada tras un evento de procesamiento reciente.

Supón que una observación de una fuente se publicó a las 9:00, llegó al recolector a las 9:01 y se reprodujo después de un reinicio a las 9:10. La reproducción es nueva para el proceso reiniciado, pero las pruebas subyacentes tienen diez minutos de antigüedad. Una regla de actualidad basada solo en el momento de inserción local podría permitir que el bot trate la observación como actual. Conserva los momentos originales y marca explícitamente la reproducción para que la regla evalúe el hecho que se diseñó para restringir.

Las comparaciones de relojes también necesitan una política para valores faltantes o incoherentes. Si una fuente no proporciona una hora de publicación fiable, el sistema no debe inventarla. Puede utilizar una alternativa documentada con permisos más restrictivos o retener las acciones que requieran pruebas temporales más sólidas. El objetivo es hacer visible la incertidumbre temporal en el registro de decisiones, en vez de permitir que una marca temporal de apariencia precisa implique un conocimiento que el sistema no tiene.

Prueba con incidentes que cambian la cuenta

Un conjunto útil de pruebas se centra en transiciones con consecuencias. Simula un tiempo de espera agotado de la respuesta después de la aceptación, una ejecución parcial durante la cancelación, una instantánea de mercado desactualizada y un reinicio con una orden sin resolver. Verifica que el bot conserva la reserva correcta y rechaza acciones que podrían superar sus límites. Una prueba que simplemente confirma que una función devuelve el valor que se le asignó dentro ofrece pocas pruebas sobre estos recorridos reales de fallos.

Utiliza un pequeño conjunto de incidentes reproducibles con registros esperados conocidos. Para el ejemplo de 100 unidades, la prueba debe terminar con 55 ejecutadas y 45 canceladas, sin un segundo envío de 100 unidades. El modelo de efectivo debe reflejar los precios y cargos reales de ejecución en lugar de la estimación máxima original. Otra prueba puede omitir deliberadamente un evento de ejecución y exigir que la conciliación recupere la ejecución faltante mediante una consulta de cuenta.

Prueba también la inactividad inocua. Cuando el pronóstico no está disponible, la correspondencia del contrato está sin resolver o el estado de cuenta es incoherente, el resultado correcto puede ser ninguna orden. Un sistema evaluado solo por envíos satisfactorios puede premiar la actividad y pasar por alto las decisiones que evitan exposición no deseada. Registra por qué se rechazó una acción para que los operadores puedan distinguir una pausa deliberada de un fallo inadvertido.

El bot está preparado para un uso más amplio solo cuando sus registros hacen comprensibles el funcionamiento ordinario y la recuperación. Un operador debe poder identificar el contrato actual, las pruebas, el permiso, los compromisos abiertos y la posición confirmada sin adivinar. Esa transparencia no establece una ventaja de trading, pero hace revisable el comportamiento del programa y da a la estrategia una base fiable sobre la que evaluarse.