Por Canuto  

Polymarket estrenará Protocol V2 sin trasladar automáticamente las apuestas abiertas en su antiguo sistema CTF. La actualización exige distinguir los saldos, contratos y permisos de cada versión, aunque los usuarios de la aplicación no necesitan una migración técnica.

***

  • Las posiciones existentes del Conditional Tokens Framework (CTF) permanecen en sus contratos; moverlas a V2 requiere una operación separada.
  • Las integraciones deben soportar ambos sistemas y gestionar por separado identificadores, firmas y permisos para comprar o vender.
  • Polymarket anunció mercados de prueba del 5 al 30 de octubre y planteó el 2 de noviembre como fecha tentativa para los mercados nuevos.

 

 

Polymarket ha aclarado que las apuestas existentes no pasarán automáticamente a Protocol V2.

La actualización Protocol V2 de Polymarket no trasladará automáticamente las posiciones que los usuarios mantienen bajo el antiguo Conditional Tokens Framework (CTF). Quienes quieran mover esas apuestas al nuevo sistema deberán recurrir a un mecanismo de migración distinto, mientras que la actualización del software de trading, por sí sola, no cambia dónde están registrados sus saldos.

La distinción importa sobre todo para las integraciones que operan mediante contratos y para los usuarios que interpretan el calendario de despliegue como una fecha límite para convertir todas sus posiciones. Según la guía de migración de Polymarket, las apuestas antiguas siguen en el sistema original y los mercados V2 utilizan contratos y permisos diferentes; los clientes de la aplicación y del sitio web, en cambio, no necesitan ejecutar una migración técnica.

Las apuestas CTF y las posiciones V2 permanecen separadas

El cambio central de Protocol V2 consiste en incorporar un sistema de posiciones separado, no en reemplazar de manera automática cada saldo que ya existe en CTF. Las posiciones antiguas permanecen en el libro mayor asociado al sistema anterior, mientras que los saldos V2 se registran en un contrato distinto llamado PositionManager.

Eso significa que una integración no puede tratar todas las posiciones de un mercado como si pertenecieran al mismo contrato. La guía de migración de contratos de Polymarket indica que las herramientas deben reconocer los saldos correspondientes a cada versión y conservar los identificadores CTF para los mercados antiguos, incluso cuando una respuesta incluya identificadores de ambas generaciones.

Polymarket sí ofrece una vía separada para que los titulares trasladen posiciones CTF a V2, pero esa posibilidad no equivale a una conversión automática al actualizar el software de trading. El registro de contratos señala que Polymarket debe registrar primero la condición o el evento relevante, y la documentación de indexación describe los eventos que conectan el saldo CTF anterior con el nuevo saldo en PositionManager.

La separación entre actualización y migración evita confundir el cambio de infraestructura con una operación sobre las apuestas existentes. En términos prácticos, la guía no presenta el 2 de noviembre como una fecha límite para mover todas las posiciones, sino como una fecha tentativa para el cambio de los mercados creados recientemente.

Desarrolladores deberán gestionar identificadores, firmas y permisos distintos

Para las integraciones de trading, el primer ajuste consiste en seleccionar el identificador de posición correcto según la versión del mercado. Aunque la respuesta de Polymarket pueda mostrar campos de identificador de ambas generaciones, las órdenes V2 emplean identificadores de posición y las órdenes CTF conservan el identificador de su sistema.

También cambia el dominio de firma que valida las órdenes, un detalle técnico que separa ambas rutas de trading. Las órdenes V2 utilizan la versión 3 del dominio de firma, mientras que las órdenes CTF mantienen la versión 2 y su exchange correspondiente; una integración debe respetar esa diferencia para no procesar una operación bajo el formato equivocado.

Los permisos de gasto tampoco se heredan de una versión a otra, por lo que las aprobaciones existentes de CTF no habilitan las operaciones V2. Para comprar, la cuenta que custodia los activos del comprador debe autorizar a ExchangeV3, el nuevo contrato de trading, a utilizar suficiente pUSD, el colateral de Polymarket, para cubrir tanto la compra como las comisiones.

La venta requiere otra autorización: ExchangeV3 debe poder operar sobre las acciones del PositionManager que pertenecen al vendedor. En consecuencia, las integraciones necesitan contemplar permisos separados para compras y ventas, además de consultar los saldos con las distinciones correspondientes entre acciones V2 y acciones CTF.

Las herramientas que crean, combinan o canjean posiciones directamente mediante contratos también deben adaptar su flujo a Router, el componente que emplea V2 para esas operaciones. Crear posiciones requiere aprobar que Router gaste pUSD; combinarlas o canjearlas exige concederle permisos de operador en PositionManager, junto con actualizar la lectura de saldos y pagos.

Calendario de pruebas y pasos para usuarios de la aplicación

En un anuncio del 5 de octubre, Rajath Alex informó que Polymarket ejecutaría mercados de prueba en vivo, conocidos como mercados canary, entre el 5 y el 30 de octubre. El calendario describió el 2 de noviembre como un cambio tentativo para los mercados recién creados, no como una obligación para que todos los usuarios conviertan sus apuestas anteriores.

Para quienes operan desde la aplicación o el sitio web, Polymarket no exige una migración técnica de las posiciones. La instrucción para esos usuarios es completar los avisos de aprobación que aparezcan en la aplicación, una diferencia importante frente a las integraciones que sí deben modificar su manejo de contratos, firmas y permisos.

La documentación citada cubre el trading onchain basado en Polygon, mientras que Polymarket dirige a quienes usan Polymarket US a documentación independiente. Por eso, las indicaciones técnicas sobre CTF, PositionManager y Router no deben asumirse automáticamente como instrucciones para esa plataforma estadounidense.

El nombre V2 también puede generar confusión porque Polymarket registró otros lanzamientos con etiquetas de versión parecidas. Su changelog indica que CLOB V2 salió el 28 de abril y Data API v2 el 4 de septiembre, ambos en 2026; el despliegue de Protocol V2 en octubre añade, en cambio, el sistema separado de posiciones.

Las integraciones que ya utilizan pUSD y el formato de órdenes CTFExchangeV2 conservan el mismo colateral, las billeteras, las credenciales del libro de órdenes y los endpoints, según la guía de Polymarket. Aun así, la empresa recomienda comprobar compras, ventas y saldos tanto en un mercado V2 como en uno CTF, para verificar que el software identifica y gestiona correctamente cada ruta.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados