Firmar una orden da permiso para negociar bajo condiciones determinadas. No significa que la operación haya ocurrido. La API puede aceptarla, el libro puede cruzar una parte y la transacción de liquidación todavía puede fallar.
Este quinto artículo de Cómo funcionan Polymarket y Kuest sigue la autorización detrás de los libros YES y NO conectados. Recorremos las capas separadas del sistema: qué firma el participante, qué hace cumplir el servicio de cruce y qué registra realmente la blockchain.
Empieza por una instrucción y después sigue los activos
Conserva nuestra pregunta hipotética: «¿Publicará el Observatorio A una temperatura de al menos 30.0°C en la Ciudad B a las 12:00 UTC de la Fecha C?». Comprar su token YES significa adquirir el activo de resultado especificado; firmar una orden BUY solo autoriza adquirirlo.
Usamos un mercado binario estándar del Conditional Tokens Framework (CTF) y unidades genéricas de garantía. Los ejemplos de importes suponen seis decimales, fondos y permisos suficientes y ningún coste de gas o financiación; las comisiones aparecen por separado cuando se indican.
Las explicaciones siguientes usan estándares públicos de firma, ejemplos públicos de CTF Exchange y flujos hipotéticos de activos. Las carteras, los tipos de orden y las comisiones admitidos por cada plataforma deben obtenerse de su documentación pública actual de integración.
Tres autorizaciones cumplen funciones diferentes
Una firma de orden autoriza una instrucción concreta de negociación. La autenticación de API identifica a un solicitante autorizado ante un servicio. Una firma de lote de cartera autoriza un conjunto separado de llamadas de cartera, como establecer una autorización de gasto.
Una credencial de API identifica a un solicitante autorizado ante un servicio; no es la clave privada del participante ni sustituye una firma de orden. La guía pública de carteras y autenticación de Polymarket proporciona un ejemplo de producto documentado.
Objetos separados, comprobaciones separadas. Un lote de cartera tiene su propio nonce y plazo; esos campos no pasan a formar parte de la orden de negociación.
EIP-712 define el hash y la firma de mensajes estructurados. Su dominio puede vincular una instrucción a una cadena, nombre de aplicación, versión y contrato verificador, impidiendo que una firma prevista para un dominio sea válida en otro.
El código público de firma de CTF Exchange V2 muestra un dominio EIP-712 específico de la aplicación. El nombre o la versión de un dominio forma parte del contexto firmado; no demuestra que otro sistema de negociación acepte el mismo mensaje. Los límites de reutilización también dependen del estado y las reglas de validación del contrato real.
Los importes contienen el precio
En la definición pública de orden de CTF Exchange V2, la instrucción firmada incluye el token, el lado, los importes maker y taker y las identidades de las cuentas, entre otros campos. La firma autoriza ese mensaje definido, no el precio que una interfaz muestre después.
Aquí, maker nombra la cuenta que aporta activos, incluso si su orden toma liquidez de inmediato. Ese nombre de campo difiere del papel de negociación maker, que significa una orden que permanece en el libro antes de que otra negocie contra ella.
En una BUY, makerAmount es la garantía ofrecida y takerAmount los tokens solicitados. Una orden que ofrece 60 por 100 YES codifica un límite de 60 ÷ 100 = 0.60; en una SELL que ofrece 100 YES por 60, el precio es, en cambio, takerAmount ÷ makerAmount.
No hay un campo de precio firmado independiente que sustituya esa relación. Cambiar el precio mostrado sin reconstruir y firmar los importes correspondientes no puede cambiar las condiciones autorizadas.
Una marca de tiempo puede describir cuándo se creó una orden sin ser una fecha de vencimiento exigible. Una integración debe distinguir los campos firmados de las instrucciones del servicio y comprobar su significado en la especificación pública actual de órdenes.
La validación decide si la orden puede entrar en el libro
Antes de enviar una orden, verifica el activo previsto, el límite de precio, la cantidad, la cuenta y el tipo de orden admitido. Las comprobaciones del cliente y un acuse de recibo de la API no sustituyen una liquidación correcta del contrato.
Un tick de precio es el incremento permitido entre precios cotizados. Comprueba las especificaciones públicas actuales del mercado antes de firmar. Una comprobación del cliente, una respuesta del servicio y una regla del contrato establecen cosas distintas; un mínimo mostrado por sí solo no demuestra una restricción on-chain.
Los fondos y los permisos son comprobaciones diferentes: una BUY necesita garantía utilizable y una autorización de gasto suficiente para el contrato de liquidación; una SELL necesita los tokens de resultado y la aprobación de transferencia. Una firma por sí sola no proporciona ninguno, y comprobar el saldo en la admisión no puede impedir todos los cambios posteriores de esa cuenta.
Post-only significa que una instrucción pretende añadir interés que permanezca en el libro en lugar de tomar liquidez inmediatamente. Comprueba las combinaciones documentadas y el comportamiento de rechazo de la plataforma; la etiqueta por sí sola no define todas las implementaciones.
La vigencia de la orden indica al servicio de cruce qué hacer con la cantidad sin ejecutar:
- GTC — good till cancelled: dejar la cantidad restante admisible en el libro hasta su cancelación.
- GTD — good till date: permitir que permanezca hasta un vencimiento especificado.
- FAK — fill and kill: ejecutar de inmediato la cantidad disponible y descartar el resto.
- FOK — fill or kill: exigir que toda la cantidad solicitada pueda ejecutarse o no ejecutar nada.
Una orden de servicio que vence y un plazo firmado del contrato son compromisos diferentes. Verifica dónde aplica el vencimiento la especificación actual y qué ocurre con las transacciones ya enviadas. La presencia de un campo en una solicitud no establece por sí sola una garantía del contrato.
Un cruce todavía necesita una liquidación correcta
Considera estos hitos didácticos: firmada → aceptada/en el libro → cruzada → enviada → confirmada. Una orden puede rechazarse antes de su admisión; una orden aceptada puede producir varios cruces parciales y transacciones de liquidación. Estas etiquetas explican responsabilidades, no definen una enumeración universal de API.
Un cruce parcial deja cantidad para cruces posteriores cuando su vigencia lo permite. Una liquidación fallida requiere conciliación antes de cualquier reintento.
El contrato público de CTF Exchange V2 muestra cruce autorizado y comprobaciones del contrato antes del movimiento de activos. Los ejemplos directos, por emisión y por fusión del artículo 4 explican los posibles movimientos de activos y sus requisitos de financiación.
La transacción es atómica: si una transferencia o comprobación requerida revierte, sus cambios de estado se deshacen. Eso no deshace otra transacción que ya tuvo éxito, y una transacción revertida puede consumir gas igualmente.
Un hash de transacción identifica una transacción enviada, no una compra correcta. Comprueba su recibo y el estado de confirmación requerido por la red elegida. Hasta conocer el resultado, una interfaz debería preservar esa incertidumbre en lugar de informar de activos entregados.
En la interfaz de un operador, conserva por separado el identificador de orden, la cantidad cruzada y la referencia de transacción. Si una transacción falla o sigue siendo incierta, concilia su resultado real antes de reintentar; cambiar una etiqueta local no puede mover activos.
Las ejecuciones parciales consumen el activo ofrecido
Supón que una BUY en el libro ofrece 60 de garantía por 100 YES y una primera ejecución recibe 40 YES exactamente a 0.60. Sin comisiones, consume 24 de garantía y deja 36 de garantía de capacidad firmada, equivalentes a 60 YES a ese mismo precio.
Una SELL en el libro que ofrece 100 YES por 60 de garantía consume 40 YES en esa ejecución y recibe 24 de garantía. Su importe maker restante es 60 tokens, no 36 de garantía. Ambas órdenes tienen 60 YES pendientes de negociar, pero sus contadores restantes on-chain usan activos diferentes.
La misma ejecución de 40 tokens, distintas unidades de contador. Ejecución exacta al precio límite; se excluyen comisiones.
La aritmética pública de CTF Exchange V2 trabaja en unidades base enteras. En el modelo proporcional de división con redondeo hacia abajo usado a continuación, el importe recibido es igual al importe aportado × importe taker firmado ÷ importe maker firmado, redondeado hacia abajo. La conciliación exacta requiere las reglas de redondeo de la vía real.
Por ejemplo, vender 1.000001 tokens de una orden firmada de 3 tokens por 1.8 de garantía calcula 1,000,001 × 1,800,000 ÷ 3,000,000, redondeando hacia abajo a 600,000 unidades base de garantía. Las ejecuciones pequeñas y las comisiones necesitan, por tanto, las reglas de redondeo de la implementación; multiplicar precios mostrados ya redondeados no basta para una conciliación exacta.
Las comisiones necesitan su propio registro
Supón una compra directa de 100 YES por 60 de garantía y una comisión hipotética de 0.60 para cada participante. El comprador necesita 60.60 de garantía; el vendedor recibe 59.40. Los 1.20 restantes son las comisiones totales, de modo que todo el efectivo del comprador queda contabilizado.
Comisiones hipotéticas, no una tarifa actual. Salida del comprador 60.60 = ingreso del vendedor 59.40 + comisiones totales 1.20; 100 YES existentes pasan al comprador.
En este ejemplo explícito, la comisión de BUY se añade al efectivo necesario del comprador y la de SELL se descuenta de los ingresos. Los cargos, destinatarios y redondeos reales deben comprobarse para la plataforma y la vía elegidas; el ejemplo no es una tabla de comisiones.
La cancelación tiene un límite
Una solicitud para retirar una orden abierta afecta a su cantidad restante sin ejecutar. No revierte ejecuciones completadas. Trata la confirmación de cancelación y cualquier transacción de liquidación pendiente como registros separados; comprueba ambos antes de reutilizar los fondos.
Si la liquidación ya se había enviado, una cancelación posterior en el libro no puede prometer detenerla. Comprueba el resultado de la transacción antes de suponer que los activos siguen disponibles, especialmente cuando la orden original se había ejecutado parcialmente.
Cancelar el resto y liquidar un cruce anterior pueden ocurrir a la vez. Ninguna de las protecciones con retraso revierte una transacción correcta.
Una restricción más amplia de la cuenta no equivale a cancelar una orden. Los controles de recuperación pueden tener alcances, retrasos y autoridades distintos. Usa la documentación pública del contrato y del producto para la cuenta real, en lugar de suponer que todos los controles detienen de inmediato.
La Deposit Wallet tiene un periodo separado de pausa y espera de emergencia antes de las retiradas de emergencia o la revocación de aprobaciones. En ese código, pausar la cartera por sí solo no deshabilita la ejecución de lotes ni la validación de firmas; no es un interruptor inmediato de parada de negociación.
Los nombres de versión no definen una integración
La orden CTF anterior de Polymarket firmaba taker, expiration, nonce y feeRateBps. Su orden separada de CTF Exchange V2 elimina esos campos y añade timestamp, metadata y builder; el precio sigue siendo una relación entre importes.
El repositorio V2 también elimina fillOrder/fillOrders y conserva el cruce por el operador mediante matchOrders. Este CTF Exchange V2 es distinto de la arquitectura de posiciones Protocol V2 en polymarket-v2-external; Kuest no hereda automáticamente las actualizaciones de ninguno de los dos repositorios.
La ausencia de vencimiento en una estructura del contrato no significa que un producto no tenga órdenes con vencimiento. La documentación actual del ciclo de vida de Polymarket describe GTD a nivel de producto; su guía de posiciones distingue los registros CTF y Protocol V2. Verifica la vía del mercado real antes de crear una integración.
Qué debería comunicar un operador de Kuest
La guía pública para operadores de Kuest separa la aplicación del operador de los servicios compartidos. Comunica a los participantes el flujo de cuenta admitido, la estimación completa de comisiones y estados diferenciados de aceptación, cruce y confirmación; son requisitos observables del producto, no detalles de implementación.
La documentación pública de comisiones de Kuest describe la participación del operador en las comisiones de negociación y el reparto configurable con afiliados. Repartir una comisión es distinto de cobrar un cargo adicional sobre el nominal de la operación. Usa la configuración pública actual y los registros de liquidación para explicar lo que paga un participante.
Para un operador con marca propia, eso crea una decisión concreta de integración: conservar la identidad correcta del builder, mostrar el cargo total real y conciliar su reparto con los registros de liquidación. Un código o un frontend con marca propia no garantiza por sí solo la admisión, el derecho a una comisión ni ingresos.
Lanza tu propio mercado de predicción con Kuest con una política de ejecución comprensible para tus participantes: jurisdicciones previstas de la audiencia, reglas precisas del mercado y vía de resolución, cantidades de negociación necesarias, flujo de cartera admitido, información sobre comisiones y estados separados de aceptación, cruce y confirmación.