Un bot de arbitraje de contratos de eventos necesita gestionar el periodo en que una combinación propuesta solo es parcialmente real. Un escáner puede identificar precios que parecen atractivos juntos, pero una cuenta recibe órdenes y ejecuciones individuales. Una orden puede aceptarse mientras otra se rechaza. Una cancelación puede llegar después de una ejecución adicional. Una respuesta puede desaparecer aunque la plataforma haya aceptado la solicitud. El bot debe describir esos estados sin fingir que el par previsto ya existe.
El problema central de diseño es la coordinación bajo incertidumbre. Reserva la capacidad necesaria para ambas patas, conserva sus identidades y mide la exposición que queda cuando no avanzan juntas. Los ejemplos ficticios de aquí utilizan pagos binarios de un dólar explícitamente compatibles. Ilustran controles de ejecución, no afirman que una operación real entre plataformas pueda completarse atómicamente ni que un arbitraje aparente carezca de riesgo.
Las reservas del bot de arbitraje empiezan con un par aprobado
El motor de ejecución debe recibir una definición revisada del par en lugar de dos nombres de mercado vagamente relacionados. Esa definición incluye el contexto de cada plataforma, el identificador de contrato, el lado del resultado, la versión de reglas y la relación de pagos. También debe indicar qué resultados excepcionales se han considerado y qué condiciones invalidan la correspondencia. Un par de contratos cuyo significado sigue sin resolverse pertenece a la investigación, no a la cola de trabajo preparado del ejecutor.
La instrucción candidata añade cantidades actuales, techos de precio, estimaciones de comisiones y momentos de observación. Indica el coste combinado máximo aceptable y la cantidad de exposición sin emparejar que la cuenta está dispuesta a tolerar. Esos límites son distintos. Un par puede ser asequible si se completa mientras su primera pata crea demasiada exposición direccional temporal para la cuenta. Ambas preguntas necesitan una respuesta antes de enviar cualquier orden.
Utiliza un identificador persistente de caso para conectar la definición, la recomendación, la autorización y las órdenes finales. Cada pata también debe tener su propia identidad estable de instrucción. El identificador del par explica por qué las órdenes pertenecen al mismo conjunto; los identificadores de patas permiten al sistema investigar un envío individual. Ninguno debe sustituirse simplemente porque una solicitud de red agote su tiempo de espera o se reinicie un proceso.
El artículo anterior sobre el bot de arbitraje de mercados de predicción ofrece la relación más amplia entre una oportunidad detectada y un proceso de trading. Este diseño comienza donde el análisis de pagos ya se ha revisado. Su trabajo es garantizar que la combinación real de la cuenta siga siendo visible mientras las órdenes pasan por estados diferentes.
Reserva fondos locales y capacidad de riesgo compartida
Supón que un par ficticio requiere 500 unidades de A Yes a un máximo de $0.37 y 500 unidades de B No a un máximo de $0.60. Supón que las reglas hacen que una unidad de cada una produzca un pago combinado de un dólar en los resultados modelizados. Los importes de compra sumarían $185 y $300. Con comisiones hipotéticas de $3 y $4, el coste total de adquisición es $492, lo que deja $8 por debajo del pago supuesto de $500.
El bot necesita $188 disponibles para A y $304 para B bajo esos supuestos. Si las patas utilizan cuentas separadas, la existencia de $492 en algún lugar de la cartera global es insuficiente. Cada cuenta necesita su propia capacidad utilizable antes de la ejecución. La reserva debe incluir los cargos apropiados y cualquier colchón adicional de recuperación elegido por el operador. El colchón es una política de control, no parte del beneficio proyectado salvo que se gaste realmente.
En el conjunto de la cartera, reserva la exposición pertinente al evento además del efectivo. Varios pares candidatos pueden depender del mismo evento o de la misma plataforma de segunda pata. Permitir que cada caso reserve fondos independientemente sin comprobar límites compartidos puede crear una acumulación excesiva de primeras patas sin terminar. Un servicio común de riesgo u otro método coherente de coordinación debe impedir que esos casos reclamen la misma capacidad restante.
Las reservas deben persistir durante la incertidumbre. Una orden rechazada con confirmación autorizada puede liberar su importe no utilizado. Una orden cuya respuesta falta no puede hacerlo. Un reinicio del proceso debe recargar las reservas sin resolver antes de aceptar casos nuevos. De lo contrario, el programa puede parecer tener un presupuesto nuevo mientras las cuentas todavía contienen compromisos creados durante la sesión anterior.
Elige deliberadamente una secuencia de ejecución
Enviar ambas patas casi al mismo tiempo reduce parte del retraso de secuenciación, pero no garantiza aceptación o ejecución simultáneas. Enviar primero una pata puede simplificar la coordinación, pero crea un periodo de exposición direccional conocida. Un sistema debe elegir su secuencia basándose en la liquidez observada, el comportamiento de las plataformas y la exposición permitida de la cuenta, y después evaluar los resultados de esa elección en lugar de tratarla como un detalle de implementación.
Una tentación habitual es ejecutar primero la pata más difícil. Eso puede ser razonable para un flujo probado, pero sigue necesitando una respuesta definida si desaparece la pata más fácil. Otro enfoque utiliza una orden en espera para un lado y reacciona a sus ejecuciones. Esto puede mejorar un precio de entrada cotizado y a la vez aumentar la posibilidad de que el precio complementario cambie antes de la respuesta. La medida pertinente es la combinación completada y sus casos sin terminar.
Las instrucciones de ejecución de una sola orden no crean una transacción entre plataformas. Por ejemplo, una instrucción de todo o nada puede restringir una pata en una plataforma que la admita, pero no obliga a otra plataforma a ejecutar su orden correspondiente. La documentación del ciclo de vida de órdenes de Polymarket describe varios comportamientos de órdenes individuales. El bot debe verificar el comportamiento real admitido para cada pata y evitar extender una garantía local a todo el par.
Documenta la secuencia elegida en el registro del caso. Registra cuándo se creó cada autorización, cuándo se envió cada solicitud y qué información estaba disponible antes del segundo envío. Estas pruebas permiten comparar después políticas de secuenciación. Sin ellas, un par satisfactorio puede ocultar la misma debilidad temporal que causa una ejecución parcial costosa en el caso siguiente.
Sigue las cantidades en cada fase
Para cada pata, distingue cantidades solicitadas, aceptadas, ejecutadas, canceladas y aún inciertas. Estos números responden preguntas diferentes. La cantidad solicitada expresa intención. La ejecutada establece una posición. La abierta todavía puede aumentar esa posición. La incierta representa exposición que el sistema local aún no ha resuelto. Combinarlas en un único porcentaje completado puede ocultar la dirección y el tamaño del riesgo restante.
Una cantidad emparejada es aquella para la que se han adquirido realmente las posiciones requeridas en proporciones compatibles. En el ejemplo simple de uno por uno, si A tiene 500 ejecutadas y B tiene 300, la cantidad emparejada es 300 y la cantidad A sin emparejar es 200. Si un pago más complejo requiere una proporción diferente, el cálculo de correspondencia debe seguir esa proporción revisada en lugar de suponer igualdad.
Mantén el cálculo de cantidad independiente de los saldos de efectivo. Un cambio de saldo puede incluir comisiones, transferencias u operaciones ajenas, por lo que es un mal sustituto de los registros de ejecución. Guarda el identificador, lado, cantidad y precio de cada ejecución, y elimina las entregas duplicadas de la misma ejecución. Un evento reproducido debe confirmar la información existente en lugar de crear una segunda entrada de posición.
La guía anterior sobre el bot de arbitraje de Kalshi puede ayudar a enmarcar los registros de cuenta para una implementación específica de una plataforma. La regla general es que la finalización del par debe derivarse de las cantidades reales de sus patas. Una cotización combinada positiva, un lote enviado o dos solicitudes reconocidas no pueden establecer por sí solos la posición completada.
Las ejecuciones parciales del bot de arbitraje crean una decisión nueva
Continúa el ejemplo ficticio con las 500 unidades A ejecutadas a $0.37, pero solo 300 unidades B ejecutadas a $0.60. Los importes de compra son $185 y $180, que suman $365 antes de cargos. Trescientas unidades forman pares completos y cuestan $291 antes de cargos. Las 200 unidades A restantes cuestan $74 y tienen exposición direccional. El resultado neto proyectado original de $8 para 500 pares completos ya no describe este estado de cuenta.
El bot debe dejar de evaluar el caso únicamente por su puntuación original de oportunidad. Ahora necesita una decisión de recuperación con cotizaciones actuales y límites explícitos. ¿Pueden adquirirse otras 200 unidades B dentro de un coste total autorizado? ¿Pueden venderse las unidades A sin emparejar dentro de una pérdida permitida? ¿Se permite mantenerlas temporalmente y durante cuánto tiempo? Cada opción debe utilizar la posición real existente y cantidades ejecutables actuales.
Supón que la regla escrita del operador permite reducir A sin emparejar a un precio de compra no inferior a $0.34 después de confirmar la cancelación de la orden B restante. Vender 200 unidades A a ese precio produce $68. La cuenta mantiene entonces 300 pares completos, que pagan $300 bajo los supuestos del ejemplo. Los ingresos combinados son $368 frente al importe de compra de $365, lo que deja $3 antes de cargos. Si los cargos totales reales de este recorrido son $5, el resultado final es una pérdida de $2.
Esa pérdida no demuestra que la aritmética de un par de $492 totalmente completado fuera errónea. Muestra que no ocurrió la ejecución prevista y que la recuperación tuvo un coste. El registro contable debe conservar ambos cálculos. Evaluar solo pares favorables completados y excluir casos parciales recuperados exageraría la utilidad de la política de ejecución.
Recomienda y gana USDC
Recomienda y gana USDCNuestro programa de afiliados paga en tiempo real.
Un envío con tiempo de espera agotado debe conservar su identidad
Cuando una solicitud agota su tiempo de espera, el bot sabe que falló la comunicación local. No necesariamente sabe si la plataforma aceptó la orden. Pasa la pata a un estado incierto, conserva su reserva y consulta los registros admitidos de órdenes y cuenta. Utiliza los identificadores originales de cliente o plataforma cuando estén disponibles. Si esos registros no pueden resolver inmediatamente el intento, la incertidumbre sigue formando parte del cálculo de exposición.
No crees una orden nueva simplemente porque la cantidad deseada aún no sea visible en la posición local. La orden original podría estar en espera, parcialmente ejecutada o aguardando en una fase de procesamiento específica de la plataforma. Una segunda instrucción puede duplicar la cantidad prevista. En un sistema emparejado, esto puede producir una pata ejecutada en exceso incluso después de completar el otro lado y convertir un caso nominalmente emparejado otra vez en exposición direccional.
La recuperación del bot de arbitraje de contratos de eventos necesita una condición de escalado. Tras un periodo definido o un error particular, el sistema puede deshabilitar casos nuevos en la cuenta afectada y solicitar revisión del operador. Es una respuesta de control ante pruebas faltantes, no una declaración de que la plataforma haya perdido la orden. El registro debe indicar exactamente qué sigue siendo desconocido y qué consultas o instantáneas de cuenta se han inspeccionado.
Cuando el intento se resuelva finalmente, actualiza el caso original en lugar de ocultarlo detrás de un registro de sustitución. Si se rechazó, libera la reserva no utilizada. Si se ejecutó, incorpora las ejecuciones y recalcula la cantidad emparejada. Si sigue abierto, decide si mantenerlo o cancelarlo utilizando el estado actual del caso. Cada resultado debe conservar la conexión con la autorización original.
La cancelación y la sustitución necesitan su propio límite
Cancelar una orden no revierte ejecuciones que ya ocurrieron. Tampoco establece que no ocurriera ninguna ejecución mientras la solicitud de cancelación estaba en tránsito. El bot debe seguir supervisando la pata hasta tener suficientes pruebas autorizadas para determinar la cantidad final ejecutada y la cantidad que ya no puede ejecutarse. Liberar toda la reserva inmediatamente después de enviar una cancelación puede subestimar el compromiso de la cuenta.
Una orden de sustitución introduce un problema similar. Si la orden antigua podría seguir activa, enviar otra vez toda la cantidad prevista puede duplicar temporalmente la cantidad capaz de ejecutarse. El ejecutor necesita una política documentada de sustitución coherente con el comportamiento real de la plataforma. Esa política puede requerir confirmación antes de sustituir o una reserva para cualquier solapamiento admitido. Nunca debe basarse en que la interfaz local oculte la orden antigua como prueba de que la plataforma la eliminó.
En el ejemplo de 500 frente a 300, supón que otras 40 unidades B se ejecutan durante la cancelación. La cantidad emparejada pasa a 340 y A sin emparejar baja a 160. Una venta de recuperación de 200 unidades A basada en la instantánea anterior corregiría el caso en exceso y dejaría exposición B sobrante. Por tanto, la decisión de recuperación debe utilizar un estado de cantidades conciliado o tener explícitamente en cuenta la incertidumbre restante.
El artículo relacionado sobre el bot de trading de mercados de eventos examina más ampliamente interrupciones y cambios programados. La ejecución emparejada añade un requisito específico: una acción de control en una pata puede cambiar lo que debería suceder en la otra. El sistema debe coordinar esas actualizaciones mediante un estado de caso compartido en lugar de permitir que cada pata opere como un programa de trading ajeno al otro.
Conserva un presupuesto de recuperación sin perseguir la finalización
Un presupuesto de recuperación define cuánto coste o pérdida adicionales puede aceptar el sistema para reducir una exposición sin terminar. Debe ser distinto del umbral original de entrada. La cuenta puede aceptar racionalmente una pérdida limitada tras una ejecución parcial para evitar mantener un riesgo de evento mayor, pero ese permiso debe ser explícito. De lo contrario, un bot puede justificar casi cualquier precio afirmando que está completando un arbitraje.
Establece el presupuesto en términos que el operador pueda revisar: coste máximo de adquisición sin emparejar, coste adicional máximo de finalización, pérdida máxima permitida de reducción y condiciones que requieren criterio humano. Un techo de precio para la segunda pata puede recalcularse a partir del coste real de la primera y del resultado permitido. El cálculo debe incluir los cargos reales ya incurridos y estimaciones conservadoras de la acción restante.
Un presupuesto no es una instrucción de gastar todo lo permitido. Compara las alternativas disponibles utilizando cantidades ejecutables actuales. Si la cancelación y una pequeña reducción restablecen una posición aceptable, el sistema no necesita forzar la finalización del tamaño original. Si ninguna alternativa encaja con los límites aprobados, pausa y muestra claramente la posición sin resolver. El riesgo restante de la cuenta debe ser visible aunque el bot no pueda resolverlo automáticamente.
El análisis anterior sobre el bot de arbitraje automatizado de Polymarket ofrece contexto para esta separación entre detección y acción controlada. La lógica de recuperación merece su propio conjunto de datos de evaluación porque se invoca bajo condiciones distintas de la entrada ordinaria. El comportamiento que funciona en instantáneas tranquilas puede fallar cuando la liquidez desaparece precisamente al ejecutarse la primera pata.
El inventario puede acumularse entre varios casos
Un bot puede operar muchos pares a la vez, pero la cuenta experimenta su inventario combinado. Dos casos sin terminar pueden dejar exposición al mismo resultado aunque sus identificadores de par difieran. Agrega posiciones y compromisos abiertos por evento y por escenario adverso pertinente. No supongas que los registros de casos separados crean límites de riesgo independientes.
Un creador de mercado de contratos de eventos utiliza el inventario para dar forma a decisiones posteriores de cotización. Un bot emparejado se beneficia de la misma consciencia cuando quedan patas sin terminar en la cuenta. Los casos nuevos podrían reducir un desequilibrio existente, aumentarlo o crear una exposición distinta bajo resultados excepcionales. El control de riesgo debe evaluar la cartera resultante en lugar de tratar cada par propuesto como automáticamente neutral.
Si el bot también participa en la creación de mercado de contratos de eventos, sus cotizaciones en espera pertenecen al mismo modelo de exposición. Una cotización creada para aportar liquidez puede ejecutarse mientras el motor de arbitraje reserva capacidad para una segunda pata. Presupuestos separados que se ignoran entre sí pueden superar ambos sus controles locales y fallar en el conjunto de la cuenta. Las reservas compartidas y la conciliación coherente son necesarias aunque las estrategias tengan objetivos distintos.
La conciliación periódica debe comparar el modelo local combinado con posiciones, órdenes y cargos autorizados. Un caso solo puede marcarse como cerrado operativamente cuando sus órdenes están resueltas y su posición restante está asignada correctamente. Si una posición residual deliberada se transfiere a otra estrategia, registra esa transferencia de responsabilidad. Eliminar el caso de una pantalla no debe eliminar su riesgo del registro contable.
Prueba los casos que cambiarían la decisión
Utiliza reproducciones de incidentes que ejerciten la coordinación, no solo el envío satisfactorio de órdenes. Una prueba debe aceptar A y rechazar B. Otra debe ejecutar parcialmente B durante una cancelación. Una tercera debe entregar la misma ejecución dos veces. Una cuarta debe reiniciar el proceso después de enviar una solicitud pero antes de registrar su respuesta. El resultado esperado debe especificar cantidades, reservas, siguientes acciones permitidas y cualquier pausa necesaria.
Para el caso desarrollado de ejecución parcial, verifica la aritmética independientemente: $365 gastados, $68 recuperados al reducir 200 unidades A sin emparejar, $300 recibidos de los pares compatibles restantes y $5 de cargos reales supuestos producen una pérdida de $2. La prueba no debe etiquetar el caso como un par rentable de 500 unidades simplemente porque esa fue la recomendación original. Debe conservar el motivo por el que el resultado difiere del plan.
Prueba también la decisión de no empezar. Rechaza un par con reglas que no coinciden, financiación local insuficiente, profundidad desactualizada o estado de cuenta sin resolver. Estas negativas forman parte del comportamiento previsto del bot. Un sistema que solo supera pruebas de ejecución activa puede seguir siendo inseguro porque nunca ha demostrado que respeta las condiciones bajo las que debe retenerse la ejecución.
La revisión final debe poder reconstruir cada caso desde la relación de pagos aprobada hasta el resultado de cuenta conciliado. Un bot de patas emparejadas es útil cuando hace explícitas las combinaciones incompletas, limita sus consecuencias y conserva suficientes pruebas para explicar la recuperación. Ese es el criterio práctico de automatización en un proceso donde dos precios atractivos no garantizan dos operaciones completadas.