Bot de trading de sí y no: lados, precios y comisiones

La correspondencia de lados empieza por los identificadores

Almacena explícitamente el identificador del contrato y el de cada resultado. Una etiqueta como Sí solo tiene significado dentro de un contrato concreto. Dos mercados vecinos pueden tener ambos un resultado Sí y referirse a umbrales, fechas o fuentes diferentes. La correspondencia debería vincular la condición de la estrategia con el resultado exacto que enviará el ejecutor, junto con una referencia versionada de las reglas que explique la relación.

Mantén comprar y vender como campos de acción separados. Una compra añade la posición seleccionada y consume el efectivo o las garantías necesarios según los mecanismos reales de la cuenta. Una venta reduce o modifica de otro modo la posición conforme al modelo admitido por la plataforma. No supongas ventas en corto sin restricciones ni que un complemento económico siempre pueda expresarse mediante la misma acción operativa.

Por ejemplo, una recomendación de comprar 120 unidades de No debería seguir siendo una compra de No en el registro de instrucción. El sistema también puede calcular su exposición direccional equivalente a Sí para analizar el riesgo, pero esa vista derivada no debe sustituir la identidad real de la orden. Si el adaptador la convierte silenciosamente en una venta de Sí, puede crear una instrucción que la cuenta no admite o una trayectoria de efectivo distinta de la aprobada por la comprobación de riesgo.

La guía anterior para comprar automáticamente participaciones Sí y No de Polymarket aporta contexto sobre la selección de resultados. Una prueba sólida de correspondencia debería utilizar intencionadamente nombres de contratos similares y lados opuestos. El objetivo es demostrar que el bot selecciona el resultado y la acción aprobados, en lugar de limitarse a producir un precio aparentemente plausible.

Distingue las cotizaciones observadas de las derivadas

Una plataforma puede comunicar directamente los libros de ambos resultados o exponer una representación de la que se deriva una oferta de venta del lado opuesto. El bot debería documentar esa correspondencia y conservar la observación original. Una cotización derivada debería identificar el lado de origen, el precio, la cantidad y la marca temporal que la respaldan. Esto permite a quien revisa examinar la transformación cuando la acción real de la cuenta parece sorprendente.

La documentación del libro de órdenes de Kalshi describe matrices de ofertas de compra de Sí y No con relaciones complementarias de ofertas de venta. En un ejemplo estándar de un dólar, una oferta de compra de Sí de $0.33 corresponde a una oferta de venta de No de $0.67. Esa relación puede informar un cálculo de compra de No, pero no convierte cualquier valor mostrado de Sí en un dato de entrada adecuado. Un punto medio o una última operación antigua no son lo mismo que la oferta de compra actual del lado opuesto.

Conserva la profundidad junto con el precio. Si la oferta de compra de origen solo respalda 40 unidades, la oferta de venta derivada respalda esa cantidad en ese nivel, no una compra ilimitada. Una cantidad adicional exige niveles adicionales y un nuevo cálculo del coste medio. Un adaptador que derive el precio correcto, pero adjunte la cantidad equivocada, todavía puede crear una recomendación inexacta.

La guía relacionada sobre software de trading de probabilidades examina los datos normalizados de forma más amplia. Un formato interno útil debería etiquetar el tipo de observación y su origen. La normalización solo hace comparables los valores cuando conserva los hechos necesarios para interpretarlos; eliminar información de lado o marca temporal puede hacer que una estructura de datos limpia sea menos fiel que la respuesta original.

Conserva la precisión de precios y cantidades

Trata los precios y las cantidades conforme a las unidades documentadas y la precisión permitida por la plataforma actual. No supongas que todos los mercados utilizan centavos enteros o contratos completos. Una cadena decimal que representa dólares no debería leerse como un entero en centavos, y un campo de cantidad no debería redondearse simplemente porque una interfaz muestre menos dígitos. El adaptador necesita una regla de conversión explícita con pruebas en los límites pertinentes.

Utiliza cálculos adecuados para el dinero y la precisión requerida. Las representaciones binarias de coma flotante pueden producir pequeños artefactos de redondeo, así que la implementación debería utilizar un enfoque decimal o de punto fijo verificado cuando corresponda. El requisito importante es que la conversión y el redondeo sean deterministas bajo las reglas reales de la plataforma. Una técnica de programación concreta no basta si no se ha comprobado su resultado frente a los precios y cantidades admitidos.

El bot debería distinguir entre redondear la visualización y redondear la orden. Mostrar un precio con dos decimales para facilitar la lectura no autoriza a enviar ese valor redondeado si el límite realmente permitido o previsto difiere. Del mismo modo, una cantidad de orden reducida para cumplir un incremento debería reflejarse en la autorización y en el cálculo de exposición. El redondeo silencioso puede cambiar la economía o dejar una posición residual inesperada.

El análisis anterior de la API de trading de Kalshi ayuda a identificar la necesidad de adaptadores específicos para cada plataforma. Las pruebas de aceptación deberían incluir valores próximos a los incrementos permitidos, las cantidades mínimas y los límites de cuenta. Un bot que solo funciona con números redondos conocidos no ha demostrado que pueda conservar correctamente todo el intervalo de datos de entrada admitidos.

La contabilidad de comisiones empieza antes del envío

Estima los cargos del lado, precio, cantidad y función de ejecución realmente contemplados utilizando los términos actuales específicos del mercado. Guarda la estimación por separado del cargo que finalmente comunique la cuenta. La estimación informa el permiso; el cargo real determina el registro final. Una diferencia de comisiones debería poder explicarse sin reescribir la recomendación original como si hubiera tenido una previsión perfecta.

Supongamos que el bot ficticio propone comprar 120 unidades de No a una oferta de venta ejecutable de $0.67. El coste de compra es $80.40. Supongamos cargos estimados de adquisición de $1.60, lo que produce un compromiso total de $82. Bajo el pago ordinario indicado, un acierto de No paga $120 y produce una ganancia de $38, mientras un fallo de No produce una pérdida de $82. Estas cifras deberían aparecer con sus supuestos en lugar de como un porcentaje genérico de beneficio.

La autorización de cuenta debería reservar el coste máximo de compra permitido y una provisión suficiente para cargos. Si la orden puede ejecutarse en varios niveles hasta un precio máximo, utiliza el compromiso máximo pertinente en lugar de solo la primera oferta de venta observada. Las comisiones también pueden comportarse de manera distinta ante ejecuciones parciales o cambios de función de ejecución, por lo que la política debería contemplar la tabla real en lugar de suponer un importe universal por unidad.

La documentación actual de comisiones de Polymarket utiliza parámetros específicos de cada mercado. Eso es un motivo para verificar la tabla aplicable, no para copiar un valor predeterminado en todos los bots. Los $1.60 hipotéticos anteriores son un dato educativo y no describen el cargo de una plataforma identificada para esa cantidad o precio.

Un registro completo de orden conecta intención y pruebas

Los registros de órdenes de un bot de trading de sí y no deberían conservar la recomendación, la autorización, el intento de envío, la identidad de orden de la plataforma y las ejecuciones posteriores. La recomendación explica por qué se consideró la acción. La autorización acota lo que puede hacer la cuenta. El registro de envío establece qué se envió. Las ejecuciones establecen qué cambió la cuenta. Mantener estas etapas separadas facilita localizar errores.

Cada intento necesita una identidad persistente. Si se pierde una respuesta, el bot puede investigar ese intento en lugar de crear otra orden sin explicación. Almacena con el intento el lado, la acción, la cantidad y el precio límite originales. Un proceso de recuperación no debería tener que reconstruirlos a partir de una instantánea posterior de posición o del recuerdo del operador sobre una etiqueta del panel.

Los registros de ejecución necesitan identificadores estables, cantidades reales, precios y cargos. La entrega repetida de una ejecución no debería aumentar la posición dos veces. Una orden parcialmente ejecutada debería conservar su compromiso sin ejecutar hasta que se complete, rechace o cancele con pruebas suficientes. La vista de riesgo de cuenta depende tanto de las unidades confirmadas como de las que todavía pueden llegar.

Un bot de trading de mercados binarios utiliza estos registros para mantener una exposición acotada y la contabilidad de liquidación. El adaptador de Sí-No añade una responsabilidad específica: cada registro debe conservar qué resultado se mantenía y qué acción lo creó o redujo. Una cantidad correcta en el lado equivocado sigue produciendo el pago posible equivocado.

Una salida debe utilizar la oferta de compra del lado mantenido

Continuemos con la compra ficticia de No con un coste total de $82. Supongamos que después la cuenta considera vender las 120 unidades de No a una oferta de compra ejecutable de $0.63. Los ingresos brutos de venta serían $75.60. Con un cargo supuesto de salida de $1.20, los ingresos netos serían $74.40, produciendo una pérdida de $7.60 respecto al coste de adquisición. El cálculo utiliza la oferta de compra de No porque la cuenta vende No.

Utilizar directamente la oferta de venta de Sí como precio de venta sería incorrecto sin la transformación revisada correspondiente. El bot debería obtener o derivar el precio de la acción real, verificar su cantidad disponible y aplicar la estimación actual de cargos. Una función auxiliar compartida llamada obtener precio es peligrosa si quienes la llaman no pueden especificar si necesitan una oferta de venta para comprar, una oferta de compra para vender o una referencia no ejecutable.

Una recomendación de salida también debería indicar si cierra toda la tenencia o solo una parte. Vender 60 de las 120 unidades deja 60 unidades de No con pago contingente. El bot no debería marcar el contrato como sin posición simplemente porque se aceptó la instrucción de salida. Las ejecuciones de venta confirmadas determinan la cantidad restante, y cualquier resto abierto sigue formando parte del posible estado futuro de la cuenta.

El artículo relacionado sobre el bot de trading de probabilidades explica cómo pueden normalizarse los formatos de cotización antes de evaluarlos. Esa conversión no sustituye la selección del libro según la acción. Un precio correctamente convertido para comprar un lado sigue siendo el dato equivocado para calcular lo que recibiría la cuenta al venderlo.

Los límites según el lado necesitan una interpretación por escenarios

Los límites de riesgo pueden utilizar cantidades, compromiso de efectivo o pérdidas posibles, pero la correspondencia de las tenencias con los escenarios debe respetar el contrato. Para lados exactamente complementarios de una pregunta binaria estándar, cantidades iguales de Sí y No pueden formar un pago emparejado bajo las reglas indicadas. Las cantidades desiguales dejan exposición residual. Entre contratos diferentes, quizá no exista en absoluto una compensación aparente entre Sí y No.

Supongamos que una cuenta mantiene 120 unidades de No y 80 de Sí en el mismo contrato ficticio. Bajo el modelo sencillo, 80 unidades forman pares y quedan 40 unidades direccionales de No. Si gana Sí, la cuenta recibe $80; si gana No, recibe $120. Los costes de adquisición y cargos determinan el resultado neto en cada caso. Una cantidad neta de menos 40 puede resumir la diferencia direccional, pero no debería sustituir las tenencias brutas ni el historial de efectivo.

Las cantidades brutas importan operativamente porque vender o gestionar cada lado puede exigir acciones e inventarios separados. Un panel de riesgo que solo muestra exposición neta puede ocultar el capital comprometido en ambos lados. También puede ocultar qué órdenes siguen activas y pueden cambiar el equilibrio. Mantén disponibles para revisión las tenencias brutas, la cantidad emparejada y la exposición residual.

La guía anterior de la API de bots de Polymarket ofrece contexto para los registros de cuenta específicos de cada resultado. El bot debería explicar cualquier medida neta derivada en términos de posiciones reales y relaciones de pago verificadas. Un modelo de riesgo se vuelve poco fiable cuando se trata un cómodo número con signo como prueba de una compensación que no respaldan los términos del contrato.

Las órdenes desconocidas deben conservar su lado original

Si se agota el tiempo de respuesta de la solicitud de compra de No, el bot debería conservarla como una compra incierta de No con su cantidad y límite de coste originales. No debería responder enviando una venta de Sí simplemente porque ambas acciones pueden estar relacionadas económicamente en un modelo simplificado. Ese cambio introduce una nueva acción de cuenta y puede exigir inventario, permisos y tratamiento de efectivo diferentes.

Investiga el intento original mediante los registros admitidos de órdenes y cuenta. Si se ejecutó parcialmente, incorpora las unidades de No confirmadas y conserva cualquier resto sin resolver. Si fue rechazado, libera la reserva no utilizada correspondiente. Si sigue abierto, decide si mantenerlo o cancelarlo conforme a la estrategia actual. Estas decisiones deberían utilizar la identidad original y pruebas reales de cuenta.

Una ejecución durante la cancelación puede cambiar el equilibrio entre lados. Supongamos que se confirman 50 unidades de No al solicitar la retirada y que se ejecutan otras 15 antes de completarse la cancelación. La posición es de 65 unidades de No, no 50. Si el bot ya había enviado una compensación basada en la cantidad anterior, la cartera resultante necesita una nueva conciliación. El sistema no debería forzarla a encajar en la exposición neta prevista editando un campo resumen.

Prueba estos casos con una cuenta inicial deliberadamente asimétrica, como una pequeña tenencia de Sí y una solicitud de compra de No mayor. Esto facilita detectar errores de lado frente a una prueba que comienza desde cero en todos los campos. El resultado esperado debería especificar tenencias brutas, efectivo y pago posible, no solo una cantidad final con signo.

Concilia comisiones y liquidación sin perder el rastro de auditoría

Después de la ejecución, sustituye los cargos estimados por los cargos reales de cuenta en los cálculos de rendimiento, conservando la estimación original para revisión. Si después se confirma un cargo adicional de adquisición de $0.20 en el ejemplo de salida, el coste total de adquisición sube de $82 a $82.20. Con los mismos ingresos netos de venta de $74.40, la pérdida pasa a $7.80. El ajuste debería tener una fuente y una hora identificables.

En la liquidación, utiliza la cantidad final restante de cada lado. Una posición de No vendida íntegramente no tiene ningún pago restante de No, aunque el pronóstico original resulte acertado después. Una posición parcialmente vendida solo liquida las unidades conservadas. El registro contable final debería conectar el resultado oficial, las cantidades mantenidas, los importes acreditados y cualquier tratamiento excepcional especificado por el contrato.

Distingue un cambio de pronóstico de una corrección contable. Una nueva estimación no altera el efectivo ya pagado, y un ajuste de comisiones no cambia el resultado sobre el que pregunta el contrato. Los registros del bot deberían permitir representar ambos cambios sin corromper el otro. Esta separación ayuda a quien revisa a entender por qué difieren el valor proyectado y el rendimiento final.

Si la cuenta no concilia, conserva la discrepancia y limita la nueva actividad afectada hasta entenderla. Una diferencia sin explicar no debería ocultarse en ganancias o pérdidas varias solo para cerrar el caso. Las discrepancias pequeñas pueden revelar un problema repetido de conversión de unidades o ejecuciones duplicadas que se volvería sustancial con un tamaño mayor.

Compara cargos estimados y reales según la acción

Una revisión de comisiones debería identificar si una diferencia procede del precio, la cantidad, la función de ejecución o una tabla incorrecta. Supongamos que el bot estimó un cargo para una compra totalmente inmediata, pero parte de la orden quedó en el libro antes de ejecutarse. El tratamiento real depende de las reglas actuales de la plataforma y del mercado. El registro contable debería conservar cómo se clasificó cada ejecución en lugar de asignar a todas las unidades la misma función según la intención original.

La comparación también necesita una unidad coherente. Un cargo expresado como importe en efectivo no debería compararse directamente con un porcentaje del pago máximo o una provisión por unidad. Convierte cada medida explícitamente y conserva el valor comunicado original. Esto ayuda a distinguir un error real del modelo de costes de una visualización que utiliza denominadores distintos.

Si la estimación era conservadora y los cargos reales fueron menores, libera la reserva no utilizada solo después de que los registros pertinentes respalden esa decisión. No declares la reserva no utilizada como ingreso. Era capacidad retenida para un posible coste, no dinero ganado operando. Esta distinción evita que el rendimiento aparente del bot mejore simplemente porque su estimación inicial era deliberadamente prudente.

Prueba el adaptador con cuatro acciones y dos resultados

Un conjunto útil de aceptación incluye comprar Sí, vender Sí, comprar No y vender No cuando cada acción esté permitida por la cuenta real. Para cada una, verifica el lado del libro seleccionado, la cantidad, el efecto sobre el efectivo y las tenencias restantes. Después aplica ambos resultados ordinarios de resolución y confirma el pago resultante. Esto cubre comportamientos más relevantes que demostrar repetidamente una única compra exitosa de Sí.

Añade pruebas de una cotización derivada del lado opuesto, profundidad insuficiente, un cambio de comisiones y una ejecución retrasada. Los registros esperados deberían conservar la observación original y la interpretación normalizada. Si una conversión utiliza uno menos la oferta de compra opuesta, verifica la correspondencia tanto del precio como de la cantidad. Si el mercado utiliza incrementos más precisos, incluye valores que fallarían bajo un supuesto de centavos enteros.

El bot terminado debería permitir expresar una afirmación sencilla para cada acción: esta cuenta compró o vendió esta cantidad de este resultado a estos precios reales, bajo este permiso, con estos cargos y esta exposición restante a pagos. Esa claridad es el propósito de la automatización que distingue lados. Mantiene los cálculos de probabilidad del software conectados con las posiciones y flujos de efectivo que la cuenta realmente posee.