El sitio web de un mercado de predicción es la entrada a un sistema con varias funciones. La interfaz presenta un mercado, el sistema de negociación cruza órdenes, los contratos liquidan movimientos de activos y los servicios de datos hacen legible el resultado. Un oráculo proporciona la respuesta final del mercado mediante su proceso de resolución configurado.
Esas funciones se realizan en lugares distintos. Pulsar un botón, aceptar una orden y liquidar una operación son hitos diferentes. Entender estos límites explica por qué un mercado puede ser visible aunque no se pueda negociar, o por qué una transacción completada puede tardar en aparecer en una cartera.
Este es el segundo artículo de Cómo funcionan Polymarket y Kuest. Empieza por qué significa realmente el precio de un mercado de predicción si todavía no conoces los precios y los pagos.
Cuatro capas, cuatro responsabilidades
| Capa | Función |
|---|---|
| Interfaz | Presentar preguntas, reglas y controles de la cuenta |
| Sistema de negociación | Validar órdenes y encontrar interés de negociación compatible |
| Contratos | Aplicar las reglas de activos y permisos de la vía seleccionada |
| Servicios de datos | Organizar metadatos, saldos y actividad para las aplicaciones |
La descripción general de las API de Polymarket refleja esta separación: Gamma facilita el descubrimiento, CLOB gestiona las órdenes y el estado del mercado en tiempo real, y Data API proporciona actividad de cuentas y mercados. Los WebSockets ofrecen actualizaciones; no sustituyen las reglas de liquidación subyacentes.
Una página no es un identificador de posición
Un evento agrupa mercados relacionados para presentarlos. Un mercado binario formula una pregunta concreta que puede resolverse y ofrece resultados YES y NO separados. Un evento puede contener varios mercados, por lo que la dirección de su página no basta para especificar una orden. Consulta el modelo de mercados y eventos de Polymarket.
En el Conditional Tokens Framework, o CTF, el identificador de pregunta identifica la entrada para la resolución. El identificador de condición se deriva de la dirección del oráculo, el identificador de pregunta y el número de espacios de resultado. El identificador de una posición de resultado también depende de la garantía y de la ruta de colecciones. No es seguro sustituir unos identificadores por otros.
Un mapa de agrupación, no una fórmula de hash. Selecciona el mercado y el resultado exactos antes de leer su libro o enviar una orden.
La guía de datos on-chain de Polymarket distingue esas derivaciones CTF de los identificadores de Protocol V2. Un título coincidente en otro sitio no demuestra que sea el mismo activo.
Sigue una orden a través del sistema
Primero, la interfaz encuentra un mercado y obtiene sus identificadores de resultado y su configuración de negociación. El cliente prepara una orden y el firmante correspondiente autoriza sus condiciones. Firmar una orden no es la misma acción que difundir una transacción a la blockchain.
La instrucción firmada llega al libro central de órdenes limitadas, o CLOB. El servicio comprueba su admisibilidad y busca órdenes compatibles. Una orden admitida puede permanecer abierta si no puede ejecutarse de inmediato; un cruce es un acuerdo para negociar según las reglas del sistema, todavía no una prueba de entrega de activos.
Después llega la liquidación. Un servicio de ejecución envía una transacción a los contratos correspondientes en Polygon. La vía de liquidación valida la operación autorizada y actualiza los activos si la ejecución tiene éxito. Una transacción fallida no se convierte en una compra correcta solo porque la API hubiera comunicado antes un cruce.
Las flechas continuas siguen la instrucción hacia la liquidación. Las discontinuas muestran datos registrados que vuelven a la interfaz; no mueven la garantía.
Polymarket documenta el ciclo de vida de una orden e indica por separado a las integraciones que esperen a la liquidación de la ejecución antes de comprobar la posición resultante. Importan la inclusión de la transacción y el estado de confirmación requerido; un identificador de orden por sí solo no basta.
Por último, los indexadores procesan los cambios registrados y las API ofrecen vistas actualizadas. La interfaz ya puede mostrar la posición y la actividad. Estas etapas necesitan mensajes de estado separados, en lugar de un único «éxito» ambiguo.
Los contratos forman una familia, no una sola caja
Un sistema basado en CTF reparte responsabilidades entre varias familias de contratos. Los nombres siguientes describen funciones; los contratos y permisos exactos dependen de la vía.
Un mapa de responsabilidades. Estos paneles no afirman que cada transacción llame a las cinco familias.
| Familia | Función |
|---|---|
| Carteras, fábricas e infraestructura de actualización | Mantener activos y aplicar reglas de propiedad, firma e implementación |
| CTF Exchange o una vía de negociación de riesgo negativo | Validar y liquidar las órdenes cruzadas correspondientes |
| Conditional Tokens | Registrar saldos de resultados CTF y permitir división, fusión y canje |
| Adaptadores de oráculo y vías de resolución | Conectar una respuesta aceptada con el pago registrado para una condición |
| Apoyo de comisiones, recompensas y depósito en garantía | Atender procesos adicionales de contabilidad, incentivos o financiación cuando estén configurados |
Liquidación y resolución responden a preguntas distintas. La liquidación pregunta si esta operación puede mover activos. La resolución pregunta qué pago implican las reglas del mercado. La documentación de resolución de Polymarket distingue actualmente mercados basados en UMA de mercados de subida o bajada con Chainlink TWAP; un motor de cruce no decide ese resultado al elegir un precio de negociación.
La versión importa. Polymarket documenta actualmente sistemas de posiciones CTF y Protocol V2. Protocol V2 usa PositionManager, mientras que CTF usa Conditional Tokens. Su registro de contratos enumera componentes de liquidación diferentes. «Exchange V2» no es intercambiable con «Protocol V2»; identifica siempre conjuntamente la versión del mercado, el registro y la vía.
Los datos hacen utilizable el registro, pero pueden retrasarse
Un indexador convierte eventos de contratos en registros consultables. Una API puede combinar esos registros con metadatos del mercado, precios o cálculos. Son datos útiles para la aplicación, pero su ritmo de actualización puede diferir del de un recibo de transacción o de un flujo de órdenes en tiempo real.
La guía de datos on-chain de Polymarket describe eventos de transferencia y de ejecución de operaciones. Esos registros no contienen todas las órdenes pendientes fuera de la cadena. Del mismo modo, llamar a un indexador «subgrafo del libro de órdenes» no lo convierte en el libro en tiempo real. Una cotización actual y una ejecución histórica pertenecen a registros distintos.
Si una cartera parece desactualizada, compara su hora de actualización con la transacción y el registro correspondiente. Si desaparece una cotización, examina el libro actual. Son investigaciones distintas; actualizar un catálogo no prueba ni una orden sin ejecutar ni la desaparición de fondos.
Un relayer ayuda a enviar transacciones; no elimina las dependencias
Un relayer puede enviar acciones de cartera admitidas, como el despliegue o las aprobaciones. La documentación de carteras de Polymarket describe acciones patrocinadas que permiten operar a la cuenta sin mantener el token nativo de gas para esas llamadas. Se sigue consumiendo gas; su coste se paga por otra vía.
Un relayer de carteras y los servicios de cruce y liquidación de la plataforma tienen funciones diferentes. Importan la disponibilidad, las llamadas admitidas y las políticas de patrocinio. No supongas que cada operación pasa por un relayer de carteras ni que el patrocinio demuestra algo sobre la custodia, la autoridad de actualización o la corrección del oráculo.
La diferencia de Kuest: la presentación puede cambiar y la vía seguir compartida
La guía pública de arquitectura de Kuest distingue la marca y el catálogo del operador de la infraestructura de negociación compartida. Los operadores pueden seleccionar mercados para sus audiencias y usar servicios comunes de ejecución compatibles.
La ejecución compartida requiere servicios, red y activos coincidentes. Una marca separada no crea ni garantiza liquidez.
Dos sitios con marca propia que usan los mismos servicios y activos de Kuest pueden mostrar un interés de negociación común y presentar catálogos diferentes. Para un operador, esto significa reutilizar la infraestructura de ejecución y seleccionar una experiencia enfocada en una audiencia.
El operador presenta el mercado a los traders; un creador de mercado aporta interés de negociación mediante órdenes. Estas funciones de los participantes son distintas de los servicios que cruzan y liquidan operaciones. Crear un mercado no aporta por sí mismo contrapartes dispuestas a negociar ni cantidades ejecutables.
Los servicios compartidos de Kuest no fusionan su libro con el de Polymarket, y una pregunta reflejada no hace que los saldos sean transferibles entre plataformas.
Las familias de contratos anteriores explican responsabilidades, no un inventario completo de despliegue. Antes de operar un mercado, verifica la red real, las direcciones de contratos, el código publicado, los permisos y el sistema de posiciones admitido. Una auditoría del proyecto original no cubre automáticamente otro despliegue o modificaciones propias.
Para un operador, la revisión útil es concreta: ¿qué activos de mercado muestra este sitio, qué servicios aceptan sus órdenes, qué contratos las liquidan y cuán recientes son los registros mostrados? Una nueva marca debería facilitar encontrar esas respuestas.
¿Quieres crear esa experiencia para tu audiencia? Crea tu propio mercado de predicción mediante la configuración guiada de Kuest.