Los tokens YES y NO nacen como dos derechos respaldados por un conjunto completo de garantía. La división crea esos derechos, la fusión los reúne y el canje los paga según un resultado registrado. Comprar un token a otro trader es una operación distinta.
Este tercer artículo de Cómo funcionan Polymarket y Kuest sigue los activos que hay bajo la interfaz, el sistema de negociación y los contratos. Si todavía confundes pago y precio, empieza por qué significa el precio de un mercado de predicción.
Empieza por la garantía, no por un precio
Usa 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?». Supón que se han especificado la fuente y las reglas de redondeo, contingencia y anulación. Modelaremos una condición binaria estándar del Conditional Tokens Framework (CTF), con YES primero y NO segundo.
La garantía, o collateral, es el activo comprometido para respaldar las posiciones. En este ejemplo, un token ganador paga una unidad de garantía; una unidad no es automáticamente un dólar. Una stablecoin introduce riesgos de emisor, transferencia y valor incluso cuando una interfaz muestra el símbolo del dólar.
Todos los saldos siguientes omiten comisiones, gas y financiación. Usan una condición, un activo de garantía y ninguna posición superior. Estos supuestos permiten cuadrar cada unidad sin mezclar activos de otro mercado en el cálculo.
CTF suele usar un token ERC-20 como garantía y saldos ERC-1155 para los resultados. ERC-1155 permite que un contrato registre muchos identificadores de token: un saldo YES para la pregunta de temperatura y otro YES para unas elecciones son activos distintos, aunque ambos aparezcan con el mismo símbolo.
Un conjunto completo tiene una identidad precisa
Preparar una condición registra su oráculo, identificador de pregunta y número de resultados. No deposita garantía ni crea saldos de resultados para nadie. En el código CTF de Kuest examinado, la preparación y la división son funciones separadas.
En CTF, el identificador de condición es keccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount)). La dirección del oráculo forma parte de esa identidad: el mismo identificador de pregunta asignado a otro oráculo produce una condición distinta.
Una colección identifica un conjunto de resultados, incluida cualquier colección superior. La dirección de la garantía y el identificador de colección identifican entonces la posición. La derivación de colecciones tiene su propio algoritmo; usa la función auxiliar getCollectionId del contrato en lugar de inventar un hash de las etiquetas. La guía CTF para desarrolladores explica esa construcción.
Un mapa de construcción, no una fórmula de hash de colección. Diferentes garantías o rutas de colecciones producen distintas posiciones.
En nuestro ejemplo binario, la partición es [1, 2]: máscaras de bits que seleccionan por separado el primer y el segundo espacio de resultado. Juntas cubren todos los resultados sin solaparse. La colección superior tiene 32 bytes a cero, lo que significa que esta división parte de garantía y no de una posición superior ya condicional.
Por tanto, los títulos coincidentes no bastan para fusionar. Comprueba red, contrato de token, condición, garantía y ruta de colecciones. Un YES de Polymarket y un NO de Kuest no forman un conjunto completo local solo porque las preguntas se parezcan.
División: bloquear 100 y recibir 100 de cada resultado
Empieza con 100 unidades de garantía. Una división correcta las transfiere al contrato CTF y emite 100 YES más 100 NO para quien realiza la llamada. La implementación de división valida la partición y realiza estos cambios de activos en una transacción; si falla, la operación se revierte.
Un par corresponde a una unidad de garantía. La división crea ambos saldos de resultados sin elegir una previsión.
La cartera tiene ahora 200 tokens de resultado, pero solo 100 pares completos. Cada par YES–NO está respaldado por una unidad de garantía. En un resultado ordinario YES, su YES paga uno y su NO cero; un resultado ordinario NO invierte esa asignación. La división ha creado inventario, no ha duplicado la riqueza.
Mantener ambos lados tampoco expresa una previsión direccional. Un creador de mercado puede dividir para obtener inventario que ofrecer a ambos lados. Vender después algunos YES deja una exposición distinta porque la cartera conserva los NO correspondientes; la división por sí sola no aportó un comprador ni aseguró ingresos de negociación.
En cambio, una compra ordinaria puede transferir tokens existentes entre cuentas. Si otro trader te vende 10 YES existentes, su saldo YES baja y el tuyo sube; esa transferencia no tiene por qué emitir nuevos YES o NO. El origen del inventario y el precio pagado por él son preguntas diferentes.
Fusión: quemar 40 pares y liberar 40 de garantía
Antes de la resolución puedes fusionar cantidades iguales de los resultados correspondientes. A partir de 100 YES y 100 NO, fusiona 40 pares: el contrato quema 40 de cada uno y devuelve 40 de garantía. Conservas 60 YES, 60 NO y 40 de garantía disponibles para gastar.
Quemar pares correspondientes libera su respaldo. Los saldos de resultados restantes no se queman ni se pagan.
Este registro sigue solo nuestra cartera y el respaldo atribuible a sus conjuntos completos; no es todo el saldo del contrato. Se siguen excluyendo comisiones, gas y financiación.
Los saldos de la cartera se enumeran como garantía / YES / NO.
Etapa | Saldos de la cartera | Respaldo |
|---|---|---|
| Inicio | 100 / 0 / 0 | 0 |
| Dividir 100 | 0 / 100 / 100 | 100 |
| Fusionar 40 | 40 / 60 / 60 | 60 |
| Fusionar los 60 restantes | 100 / 0 / 0 | 0 |
La última fila es un posible siguiente paso, no un paso que demos antes del ejemplo de canje que viene después. Devuelve la cartera a sus saldos iniciales antes de costes y demuestra conservación, no beneficio.
Con 60 YES y solo 20 NO correspondientes puedes fusionar como máximo 20 pares. Los 40 YES restantes mantienen exposición al resultado. Un YES aislado no puede liberar una unidad completa antes de la resolución porque no cubre el resultado NO.
La implementación de fusión no necesita un resultado de pago. La recombinación de conjuntos completos funciona antes de la resolución; la función no se limita a ese periodo. Usa el respaldo del par en lugar de encontrar un comprador en el libro de órdenes.
Canje: usar el resultado, no la última cotización
Retoma ahora el estado anterior con 40 de garantía y 60 de cada token. Si el resultado registrado es YES, canjear esos saldos seleccionados paga 60 de garantía por YES y cero por NO. La cartera llega a 100 de garantía antes de costes; los tokens canjeados se queman.
Una cartera que solo mantuviera los 60 YES recibiría el mismo pago YES de 60 unidades. El canje no exige que su propietario aporte también NO. Esa es la diferencia clave frente a una fusión anterior a la resolución: un resultado registrado determina qué derechos individuales pagan.
En la función de canje examinada, el importe de cada posición seleccionada es su saldo multiplicado por el numerador de pago correspondiente y dividido por el denominador. El denominador es la suma de los numeradores registrados. Seleccionar una posición canjea todo su saldo en esta función CTF; no hay un argumento de cantidad parcial.
Garantía recibida por cada 100 tokens de cada resultado, antes de costes. El caso 50/50 es una capacidad del CTF normal, no una promesa ni un resultado admitido por NegRisk.
Para 100 de cada token, [1, 0] paga 100 a YES / 0 a NO, y [0, 1] paga 0 a YES / 100 a NO. Un pago CTF normal admitido de [1, 1] tiene denominador 2 y paga 50 a cada lado. Son importes de garantía recibida, no beneficio neto; los costes de adquisición siguen importando.
Esa capacidad de pago fraccionado no es una promesa universal de reembolso por anulación. Las reglas del mercado y su mecanismo de resolución deben permitir el resultado. Un evento NegRisk vinculado necesita sus propias reglas de pago y recuperación admitidas; no supongas que se aplica una alternativa binaria ordinaria.
El contrato calcula con unidades base enteras y redondea las divisiones hacia abajo. Si un token de garantía tiene seis decimales, 100 unidades significan 100000000 unidades base; una unidad base con un pago por mitades se redondea a cero. Los decimales mostrados nunca deben pasarse como enteros sin procesar al contrato.
Que el reloj llegue a la hora de cierre del mercado no establece un pago. El canje requiere un denominador de pago registrado distinto de cero; el oráculo y su proceso configurado deben proporcionar primero el resultado. Eso puede introducir una espera incluso después de finalizar la negociación.
Vender y canjear son salidas distintas
Vender requiere interés de compra ejecutable. Transfieres tokens de resultado a un comprador por el precio acordado, sujeto a la cantidad disponible, los costes de ejecución y una liquidación correcta. Puede cerrar una posición antes del resultado, pero el punto medio mostrado no es una oferta de compra disponible.
Una venta necesita un comprador y un precio ejecutable. El canje necesita un resultado registrado y la vía de contrato correcta.
El canje utiliza el pago registrado y la vía de contrato apropiada tras la resolución. No requiere un nuevo comprador en el libro. Una adquisición a 0.60 seguida de un pago ganador de una unidad produce 0.40 de ganancia bruta por token; un resultado perdedor produce una pérdida de 0.60, antes de costes en ambos casos.
Comprar ambos resultados por debajo de su valor de fusión solo permite una diferencia bruta después de que se ejecuten realmente cantidades iguales del mismo conjunto completo. Los lados sin ejecutar, identificadores incorrectos, comisiones, aprobaciones, fallos de transacción y riesgo de la garantía pueden borrar esa diferencia o dejar exposición direccional. Una cotización por sí sola no es una estrategia completada.
La diferencia de Kuest: el contexto del creador acompaña a las posiciones
Kuest conserva esta mecánica de activos CTF y amplía la preparación de condiciones con una dirección de creador y una referencia externa de metadatos. Su función de actualización de metadatos limita las actualizaciones al creador o a un administrador y registra la referencia anterior, la nueva y quien actualiza.
Para un operador, eso ofrece una forma, en el código fuente, de asociar una condición a su creador y rastrear cambios de referencias de metadatos. No almacena el documento completo del mercado en el registro CTF, no congela todas las reglas mostradas ni decide el pago. Los operadores siguen necesitando documentos accesibles y una vía de resolución claramente identificada.
La guía pública CTF separa las operaciones de división, fusión y canje del registro de posiciones. Un adaptador NegRisk es otra vía de contrato; identifica su interfaz publicada y su garantía antes de intentar la misma operación de inventario.
Los permisos siguen esa vía: dividir necesita una autorización de gasto de garantía para el destino CTF o adaptador correspondiente. La fusión y el canje de riesgo negativo también necesitan permiso para que el adaptador gestione las posiciones CTF. Las aprobaciones de negociación no autorizan automáticamente estas operaciones de inventario.
Comprobación de versión, a 30 de octubre de 2026: la documentación actual de gestión de posiciones de Polymarket distingue los adaptadores de garantía CTF del Router y PositionManager de Protocol V2. Un número de versión o un nombre de método parecido no demuestra compatibilidad con otra plataforma. Usa la vía documentada para la posición real.
Las explicaciones CTF de Kuest anteriores pueden comprobarse en su contrato de Polygon con código verificado públicamente. No establecen la garantía, los permisos o el mecanismo de resolución activos para cada mercado listado. Antes de habilitar operaciones de inventario, confirma esos detalles y muestra división, fusión y canje como movimientos de activos distintos.
¿Planeas esa experiencia para tu audiencia? Crea tu propio mercado de predicción con Kuest y aporta las reglas del mercado, las jurisdicciones de la audiencia prevista y los requisitos de liquidez necesarios para elegir la configuración operativa adecuada.