pUSD y Protocolo V2 de Polymarket explicados

Dos mejoras con nombres parecidos se confunden con facilidad. CLOB V2 cambió el exchange, el backend de órdenes y el token de colateral. El Protocolo V2 añadió una segunda forma de mantener posiciones de resultado. Esta guía explica ambas a partir de la propia documentación de Polymarket, deja el detalle para desarrolladores en lo mínimo e indica dónde las páginas callan o se contradicen. Una cronología con fechas de las entradas del registro de cambios está en un artículo aparte.

¿Qué es pUSD?

La documentación de Polymarket describe pUSD como el token de colateral de todo el trading en Polymarket. En lo técnico es un token ERC-20 en Polygon respaldado por USDC. ERC-20 es un estándar de tokens, y la documentación llama a pUSD un wrapper que representa un derecho sobre USDC. El contrato inteligente garantiza el respaldo, y la página afirma que no hay paridad algorítmica ni reserva fraccionaria. Un par completo de tokens Sí y No de un mercado está respaldado por 1 pUSD de valor.

pUSD se puede transferir como cualquier otro token ERC-20, pero está pensado para funcionar dentro de Polymarket: la documentación dice que por ahora no hay planes de listarlo en exchanges externos. Polymarket Perps usa el mismo token, ya que el colateral de Perps es pUSD (consulta la guía de Perps).

¿Por qué lo introdujo Polymarket?

La documentación da un motivo breve: liquidación en USDC nativo, que describe como un estándar más eficiente en capital, más escalable y mejor alineado con las instituciones a medida que la plataforma crece. El colateral anterior a pUSD era USDC.e, la forma con bridge de USDC, y pUSD lo sustituyó. Las páginas no comparan los dos tokens ni dicen más sobre la decisión.

¿Cómo se consigue pUSD?

Depende de cómo uses Polymarket.

• En polymarket.com. El sitio convierte tus fondos automáticamente tras una aprobación única. Después simplemente ves un saldo y operas.
• Depositando. El bridge se encarga de la conversión: los activos de otras cadenas se convierten automáticamente a pUSD en Polygon. Puedes enviar USDC nativo o USDC.e con bridge.
• A través de los contratos. La documentación nombra dos grupos que lo envuelven a mano, los usuarios avanzados y los traders que solo usan la API, que convierte USDC.e en pUSD mediante el contrato Collateral Onramp. No describe otras interfaces.

En el sentido contrario, un retiro desenvuelve el pUSD con el Collateral Offramp, y también puedes retirar el propio pUSD, aunque algunos exchanges ya no aceptan depósitos directos de pUSD. Sobre las comisiones, la página Fees dice que Polymarket no cobra comisión por depositar o retirar USDC, y la página Withdraw dice que no cobra comisiones por retirar; un servicio que uses por el camino puede cobrar la suya.

¿Qué tipo de wallet usa una cuenta?

La página Wallets dice que la Deposit Wallet es la predeterminada y que todas las wallets de cuenta desplegadas a partir del 4 de mayo de 2026 usan una, con las wallets Proxy y Safe como tipos heredados. Polymarket 101 lo formula de forma más estrecha: los nuevos usuarios de la API usan deposit wallets, y las wallets Safe y Proxy siguen siendo compatibles para las personas y las integraciones que ya las usan. La página Contracts añade que pUSD y las wallets de cuenta de Polymarket funcionan con ambos sistemas de posiciones, algo que se trata más abajo.

¿Qué cambió con CLOB V2?

CLOB V2 es la mejora que introdujo pUSD. El registro de cambios de Polymarket la describe como una mejora coordinada formada por nuevos contratos de exchange, un backend del CLOB reconstruido y pUSD como nuevo token de colateral. Entró en funcionamiento el 28 de abril de 2026 sobre las 11:00 UTC, y el trading estuvo en pausa aproximadamente 1 hora. Para los traders, los efectos visibles fueron estos:

• Las órdenes abiertas se eliminaron, así que lo que estaba pendiente antes del cambio hubo que volver a colocarlo.
• Las comisiones las fija el protocolo en el momento del emparejamiento en lugar de formar parte de la orden firmada. La guía de comisiones trata las tasas.
• La atribución de builder ahora pasa por un campo opcional de builder code en la orden. La guía de migración dice que los builder codes permiten la atribución y el reparto de ingresos para los integradores.

¿Qué es el Protocolo V2?

El Protocolo V2 es un cambio distinto de CLOB V2, y sus páginas de migración parten de integraciones que ya usan pUSD y el formato de orden de CTF Exchange V2. La documentación dice que introduce nuevos tokens de posición, además de nuevos contratos para operar, para las operaciones con posiciones y para la resolución. Una rareza de nombres: la página Contracts pone la misma insignia Poly v2 en el token pUSD y en sus contratos Onramp y Offramp que en PositionManager, mientras que el registro de cambios y la guía de migración vinculan pUSD con la entrada en producción de CLOB V2, que es la lectura que sigue esta guía.

El núcleo del Protocolo V2 es un segundo registro para las posiciones de resultado. Los mercados del Conditional Tokens Framework (CTF) guardan sus saldos de Sí y No en el contrato Conditional Tokens. Los mercados del Protocolo V2 los guardan en un contrato llamado PositionManager, que pasa cada operación a un módulo: BinaryModule para un mercado Sí/No sencillo, NegRiskModule para eventos con varios resultados y CombinatorialModule para posiciones construidas a partir de un conjunto de tramos. Las posiciones combinatorias, que combinan varios resultados existentes en un nuevo par Sí y No, usan Protocol V2 y no el Conditional Tokens Framework. Las órdenes de posiciones V2 se liquidan a través de un contrato de exchange aparte, ExchangeV3, y las divisiones, fusiones y canjes pasan por un contrato llamado Router.

El Protocolo V2 también alcanza la resolución. Polymarket 101 dice que los mercados V2 también pueden usar otros mecanismos de resolución. La página Contracts muestra el camino: los resultados van desde los módulos de reporter, a través de un OracleAggregator, hasta el módulo que posee la condición, con módulos reporter llamados OO, Chainlink y EOA. Los datos de resolución nombran un reporter para cada condición resuelta: UMA_OO, CHAINLINK o EOA. Las páginas no desarrollan "OO" ni "EOA" ni dicen qué mercados usan qué reporter. La guía de resolución cubre el camino de UMA por completo.

¿Cómo se relacionan los dos sistemas de posiciones?

Los dos sistemas de posiciones de Polymarket. Fuente: docs.polymarket.com/trading/positions/how-positions-work, verificado 19 de octubre de 2026.

Los dos sistemas guardan los resultados Sí y No como tokens ERC-1155 (el estándar que nombra la página 101 para las participaciones de resultado), y la documentación dice que esos saldos significan lo mismo desde el punto de vista económico para un trader. Dividir pUSD en un par Sí y No, volver a fusionar el par y canjear tras la resolución existen en ambos, a través de contratos distintos. La página How Positions Work advierte de que un CTF token ID no debe enviarse a PositionManager, ni un Position ID a Conditional Tokens; dice que el descubrimiento de mercados aporta los identificadores que necesita cada flujo.

¿Qué pasa con lo que ya tienes? La descripción general dice que lo que ya tienes en CTF no se convierten, y la página de migración de contratos añade que actualizar una integración no convierte los saldos CTF existentes. La página Contracts también describe una vía de migración desde posiciones CTF hacia PositionManager, pero Polymarket tiene que registrar primero la condición o el evento, y las páginas no dicen quién puede usarla ni cuándo. Para los usuarios de la app y la web de Polymarket, la descripción general dice que no hace falta ninguna migración técnica más allá de completar las solicitudes de aprobación que aparezcan.

Qué cambió para los traders y qué no

Qué cambió

• El colateral es pUSD en lugar de USDC.e, así que los saldos, los costes de las órdenes y los pagos están en pUSD.
• Algunos mercados mantienen sus posiciones en el registro del Protocolo V2, y la app de Polymarket puede mostrar solicitudes de aprobación.

Qué siguió igual

• La página de pUSD de Polymarket lo expresa así: en el día a día, no cambia nada. Sigues depositando, consultando un saldo, operando y retirando.
• Una participación ganadora se sigue canjeando por $1.00 cada uno y una perdedora no vale nada, la guarde el sistema que la guarde.
• La página Prices & Orderbook dice que el libro de órdenes se comparte entre mercados, mientras que la ruta de liquidación depende de qué sistema guarda los tokens.
• Para las integraciones que ya usan pUSD, la descripción general dice que el colateral, las wallets, las credenciales del CLOB y los endpoints no cambian con el Protocolo V2.

Qué revisar en la página de un mercado

• Las reglas de resolución. Definen cómo se resuelve el mercado, y algunos mercados pueden usar mecanismos distintos de UMA. Consulta la guía de resolución.
• La unidad. Los saldos, los costes de las órdenes y los pagos están en pUSD, no en USDC.e, mientras que una orden limit se coloca con un precio y un número de participaciones.
• Las solicitudes de aprobación. La descripción general dice a los usuarios de la app y la web de Polymarket que completen las solicitudes de aprobación que aparezcan. Las páginas no dicen qué aprueban esas solicitudes.
• La versión, si lees datos. Los datos de mercado de la API Gamma llevan una versión: "v1" para los mercados CTF y "v2" para los del Protocolo V2. El consejo de la documentación es que lee el campo version del mercado, porque la presencia de un campo de ID no lo indica. Las páginas usadas para esta guía no dicen que la app de Polymarket la muestre.
• Los avisos oficiales. El registro de cambios y la página de estado anuncian cambios e incidencias; el artículo de cronología lista las entradas del registro de cambios con fecha.

Para desarrolladores

Los desarrolladores tuvieron más trabajo. Para CLOB V2, producción ya no admite los SDK heredados de V1 y las órdenes firmadas con V1, y cambiaron la estructura de la orden y el dominio de firma; la guía Migrating to CLOB V2 tiene los detalles. Para el Protocolo V2, Polymarket publica páginas de migración para integraciones de SDK, de API y de contratos inteligentes, todas accesibles desde la descripción general. En resumen: eliges los identificadores según la versión del mercado, concedes aprobaciones nuevas porque los permisos de CTF existentes no se trasladan a V2, firmas las órdenes V2 contra el exchange V2 y mantienes la compatibilidad con CTF para los mercados CTF. Esta guía se detiene aquí a propósito.

PolyTerminal es una interfaz independiente para Polymarket y no está operada ni avalada por Polymarket. Las órdenes enviadas a través de PolyTerminal llevan el builder code de Polymarket de PolyTerminal, y PolyTerminal puede cobrar un builder fee adicional a las comisiones propias de Polymarket. Esta página es educativa y no es asesoramiento de inversión. Las reglas se compararon con la documentación oficial el 19 de octubre de 2026; comprueba la fuente antes de actuar según una cifra.