«¿Llegará a 30 grados?» deja margen para varias operaciones diferentes. La previsión redondeada de una aplicación meteorológica, la temperatura medida por una estación y un informe oficial publicado más tarde pueden discrepar. El mercado necesita decir cuál determina el pago antes de que alguien compre YES o NO.
Este sexto artículo de Cómo funcionan Polymarket y Kuest convierte esa pregunta en una regla comprobable y después sigue sus pruebas a través de las capas separadas del sistema. Una página legible, los bytes de resolución comprometidos y un documento de metadatos accesible demuestran cosas diferentes.
Reescribe la pregunta hasta que dos lectores obtengan la misma respuesta
Conserva nuestros ficticios Observatorio A, Ciudad B y Fecha C. «A las 12:00» debe identificar la hora de observación o el plazo de publicación; son eventos distintos. Reescribe el título así: «¿Será de al menos 30.0°C la observación de las 12:00 UTC del Observatorio A para la Ciudad B en la Fecha C?». Después especifica las pruebas:
Usa el CSV oficial de observaciones diarias del Observatorio A, estación B-01, para la Fecha C. Lee el campo de temperatura del aire en grados Celsius del registro con marca de tiempo 12:00:00 UTC. Usa la última revisión oficial disponible hasta las 13:00:00 UTC de la Fecha C, incluida una revisión publicada exactamente en ese límite. Compara directamente el valor numérico publicado con 30.0; no vuelvas a redondearlo. Un valor válido de 30.0 o superior significa YES; uno válido inferior significa NO. Ignora previsiones, otras estaciones y revisiones posteriores. Si, en ese límite, el registro se ha retirado, los registros contradictorios no tienen un orden autorizado de revisiones o no hay un registro válido disponible, usa el resultado especificado para datos no disponibles.
En un mercado real, sustituye cada nombre y fecha ficticios por la URL exacta de la fuente, el identificador de estación, la fecha del calendario y la definición del campo. «Sitio oficial» por sí solo deja a los lectores eligiendo entre páginas, réplicas y revisiones. Una fuente de respaldo también necesita una prioridad declarada; de lo contrario, añade otra elección después de conocerse el resultado.
Aquí, 29.96 significa NO aunque una aplicación muestre 30.0. Una corrección de 29.9 a 30.1 anterior al límite significa YES; la misma corrección posterior no cambia la observación seleccionada. La igualdad es expresamente YES, de modo que el umbral no tiene un empate sin resolver.
La hora de observación selecciona el registro. El límite selecciona su revisión. La política de pago gestiona las pruebas ausentes.
El resultado para datos no disponibles debe corresponder a la vía de contrato elegida. Para este ejemplo didáctico, supón un adaptador binario estándar que admita UNKNOWN: YES paga una unidad de garantía y NO cero para un resultado YES, a la inversa para NO, y cada uno paga la mitad para UNKNOWN. Es un supuesto explícito del modelo, no una regla universal de anulación ni una política de pago NegRisk.
Media unidad por token no es un reembolso de su precio de compra. Un participante que pagó 0.80 por YES recibe 0.50 bajo ese resultado supuesto. La mecánica de división y canje determina el pago; las reglas determinan qué resultado admitido debe comunicarse.
Un plazo de la fuente, el cierre de negociación y la hora de resolución cumplen funciones distintas. El primero selecciona las pruebas; el segundo controla la admisión de órdenes; el tercero registra un resultado. Por ejemplo, las órdenes podrían detenerse a las 11:55 UTC mientras las revisiones admisibles siguen abiertas hasta las 13:00; la resolución puede llegar después. El operador debe configurar la negociación por separado y una transacción retrasada no amplía el límite de las pruebas.
Sigue dos tipos de pruebas
Un mercado necesita tanto una pregunta de resolución definida como información de apoyo legible. Los datos auxiliares, o ancillary data, son los bytes adicionales de la pregunta utilizados por una integración concreta de oráculo; los metadatos descriptivos también pueden incluir imágenes, etiquetas y enlaces. Cumplen funciones distintas y no deben tratarse como compromisos intercambiables.
El adaptador público CTF de Polymarket es un ejemplo de datos de pregunta registrados con una codificación definida. Recalcular un compromiso requiere esa codificación exacta, no un párrafo visualmente parecido. Comprueba la interfaz publicada del despliegue elegido en lugar de generalizar un ejemplo a otras familias de adaptadores.
El compromiso de pregunta y un documento externo permiten comprobaciones distintas; una referencia no demuestra por sí sola integridad ni disponibilidad.
El contrato Conditional Tokens de Kuest con código verificado públicamente registra un creador y una referencia externa de metadatos. Una referencia localiza información; no demuestra por sí sola que un documento esté disponible, sea inmutable o coincida con el compromiso original de resolución. Recupera los documentos y compáralos con las pruebas de la pregunta registrada.
La documentación pública de creación de mercados de Kuest describe la interfaz de producto admitida. Un documento cargado, una condición preparada y un mercado negociable son observaciones distintas. Confirma los registros apropiados en lugar de inferir las tres cosas de una sola pantalla de éxito.
Identificadores parecidos cumplen funciones diferentes
Un slug localiza una página. Un identificador de pregunta identifica una pregunta según el esquema de su adaptador. Un identificador de condición combina oráculo, identificador de pregunta y número de resultados en la construcción pública CTF. Importan las entradas exactas; un texto de página parecido no establece condiciones idénticas.
Un identificador de posición identifica el activo mantenido y negociado. En CTF, su derivación también depende de la garantía y de la colección que representa el conjunto de resultados. Títulos o slugs coincidentes no establecen activos idénticos. La dirección del creador registra atribución y ciertos permisos; el identificador externo de metadatos localiza contenido descriptivo. Ninguno sustituye al identificador de condición o de posición.
Incluso «identificador de pregunta» no es una codificación universal. En la NegRiskIdLib específica de Polymarket, una pregunta comparte los primeros 31 bytes del identificador de su mercado y utiliza el último byte para el índice de pregunta. Aplica esa regla solo a esa familia de adaptadores, no a todas las preguntas de oráculo.
El campo metadata de una orden de negociación firmada es otro objeto. Por ejemplo, la definición pública de CTF Exchange V2 incluye bytes32 metadata a nivel de orden. Su presencia no demuestra que la firma comprometa el documento mostrado del mercado.
Una actualización rastreable sigue siendo una actualización
La extensión Conditional Tokens de Kuest registra el creador de la condición y la referencia externa actual de metadatos. El creador o un administrador CTF puede sustituir esa referencia. Cada llamada correcta incrementa un contador y emite el identificador de condición, la referencia anterior, la nueva y la dirección de quien actualiza.
La función examinada no se congela al resolverse el mercado ni comprueba que una cadena de sustitución apunte a contenido disponible y no vacío. Por tanto, un identificador de condición sin cambios no significa que su descripción actual mostrada nunca haya cambiado. Una actualización podría añadir una referencia de apoyo o corregir una imagen; compara los documentos reales antes de decidir si cambió la proposición.
Una actualización de referencia puede enriquecer un documento o cambiar su descripción. El evento revela quién cambió el puntero; compara los contenidos.
Cambiar el puntero no reescribe los bytes originales de la pregunta ni concede un nuevo derecho a comunicar pagos. La función de comunicación de CTF deriva la condición usando como oráculo a quien llama. El adaptador y su vía de resolución configurada gobiernan cómo llega un resultado a esa función; el permiso de editar metadatos es una facultad separada.
Supón que la versión A dice 30.0°C y la B dice 31.0°C. Un evento histórico hace visible la sustitución; no establece que 31.0 se haya convertido en el umbral legítimo. Compara ambas con los bytes auxiliares originales y la política aplicable de aclaraciones antes de interpretar el cambio.
Las aclaraciones necesitan autor y política
Polymarket ya tiene compromisos de pregunta on-chain. Su adaptador UMA CTF en la versión citada calcula el hash y almacena datos auxiliares ampliados, mientras que su tablón de anuncios registra actualizaciones atribuidas. Son mecanismos específicos del adaptador CTF, no una afirmación sobre la ABI de todas las vías actuales de Polymarket.
Una aclaración también necesita un autor identificable y una política aplicable. En el ejemplo público de Polymarket, una publicación atribuida no reescribe los datos auxiliares originales. No trates cualquier declaración que mencione una pregunta como una modificación oficial.
La documentación actual de resolución de Polymarket dice que el contexto de las aclaraciones debe preservar la intención fundamental. Identificar una columna CSV renombrada puede aclarar las pruebas; sustituir un umbral de 30.0 por 31.0 cambia la proposición. Una marca de tiempo demuestra cuándo se registró una declaración, no que tenga autoridad legítima.
Verifica el camino de la referencia a la pantalla
Una revisión práctica sigue las pruebas en orden:
- Identifica el despliegue. Registra red, direcciones de contratos, familia de adaptadores y una referencia de bloque. Obtén el recibo de creación, los bytes originales de la pregunta, la identidad del oráculo, el creador y el identificador de condición.
- Recalcula los identificadores apropiados. Usa la codificación, el tratamiento del inicializador y el número de resultados de esa implementación. Comprueba los identificadores de posición con la garantía real y la correspondencia de resultados.
- Sigue el historial de metadatos. Lee la referencia de preparación, la actual, el contador y los registros de actualización. Recupera documentos originales y de sustitución y después compara cambios y direcciones de quienes actualizaron.
- Comprueba integridad y disponibilidad por separado. Valida el contenido mediante el esquema real de transacciones o compromisos del sistema de almacenamiento. Conserva los bytes exactos recuperados y su procedencia; una referencia registrada no puede entregar un documento que nadie puede recuperar.
- Compara lo que ven los participantes. Contrasta la fuente, fechas, reglas y etiquetas de resultado mostradas con los datos originales de resolución y el contexto autorizado. Una interfaz legible no es una comprobación independiente de integridad.
Un documento accesible, una procedencia válida y una presentación coincidente son comprobaciones separadas. Ninguna establece por sí sola la resolución correcta.
Para un operador con marca propia, la aportación concreta de Kuest son referencias de metadatos vinculadas al creador y un historial visible de actualizaciones junto a los datos originales de resolución. Eso permite un catálogo revisable y un proceso de publicación con atribución. No pone toda la información del mercado on-chain, no garantiza la disponibilidad del documento ni resuelve una discrepancia sobre el significado.
Lanza tu propio mercado de predicción con Kuest aportando una audiencia y jurisdicciones definidas, una hoja de reglas desarrollada, políticas de fuentes y correcciones, una vía de resolución admitida y un plan para conservar pruebas accesibles. Prueba esas entradas con ejemplos ambiguos antes de aceptar operaciones.