Explicación del algoritmo subyacente de Polymarket

Trabajo original: @MrRyanChi, @insidersdotbot Fundador de la plataforma de trading de mercados de predicción

Prefacio: El lado B de Polymarket que no conoces

En los últimos seis meses, han aparecido cientos de millones de artículos sobre mercados de predicción en Twitter.

El noventa por ciento habla de cómo los programas de escritura de IA pueden llevar al mito de hacerse rico. Este es el "Yuan", el primer paso en tu exposición a este mercado naciente.

Otro 9% discute estrategias de trading específicas, intercambio de mercado y análisis de estrategias de dinero inteligente. Este es el "Dao", el primer paso para explorar tus propias estrategias de trading y comenzar a entender la mentalidad para ganar dinero en los mercados de predicción.

Sin embargo, el "Fa", que se refiere al diseño de trading subyacente de los mercados de predicción, los cálculos de PNL y las reglas del flujo de dinero, solo es discutido por ese 1% de personas, mayormente disperso en algunos tuits concisos. Estos expertos ermitaños parecen poco dispuestos, o carecen de la energía, para compartir sus métodos completos con todos a la vez.

Así que, el día que insiders.bot se lanzó y Polymarket completó su actualización v2, quiero deconstruir el "Fa" de este mercado en el que hemos estado operando desde la tecnología más fundamental.

El pasado octubre, escribí una versión simplificada que introducía a grandes rasgos varios componentes centrales de Polymarket. Esta vez, quiero mostrar realmente todos los detalles del diseño técnico y explicarlos en lenguaje sencillo.

Este artículo contiene el arduo trabajo de nuestro equipo durante los últimos ocho meses.

Durante estos ocho meses, el equipo de @insidersdotbot ha diseccionado todos los contratos inteligentes y la arquitectura de algoritmos subyacentes de Polymarket para lograr el trading más rápido y los cálculos de PNL más precisos. Esto es algo que solo nuestra propia API puede lograr, y hasta el día de hoy, nadie más puede hacerlo.

Por lo tanto, creo que podemos ser quienes mejor puedan diseccionar el "Fa" de Polymarket.

En este artículo, te ayudaré a entender cómo el contrato inteligente ctf-exchange-v2 subyacente maneja cada fondo, cómo el Relayer te ayuda a pagar el Gas y cómo el Riesgo Negativo asegura matemáticamente la conservación del valor.

Este no es un simple artículo de divulgación científica. Es una deconstrucción algorítmica integral de los mecanismos subyacentes de Polymarket desde la perspectiva de un desarrollador.

Comencemos por lo básico. Es decir, cuando colocas una orden, ¿qué estás enviando exactamente?

P.D. Este artículo también ha sido adaptado en estilo y estructura por IA, ¡¡¡siéntete libre de compartirlo con tu OpenClaw, Manus, Hermes o cualquier Agente de IA como material de entrenamiento!!!

Capítulo 1: Qué sucede desde el clic hasta la cadena (on-chain)

1.1 Las órdenes no son transacciones, son "intenciones"

En los intercambios descentralizados tradicionales (como Uniswap), cuando operas, tu billetera muestra un cuadro de confirmación, necesitas pagar tarifas de Gas y luego enviar una transacción a la red blockchain (Mempool) para esperar a que los mineros la empaqueten.

Pero en Polymarket, cuando colocas una orden, tu billetera generalmente muestra una solicitud de "firma", en lugar de una solicitud de "transacción". Además, no necesitas pagar ningún Gas.

Esto no es solo una optimización de la experiencia del usuario; es una diferencia fundamental en toda la arquitectura subyacente.

En Polymarket, una orden es esencialmente un fragmento de datos estructurados que cumple con el estándar EIP-712. Estos datos contienen lo que quieres hacer:

• ¿Eres un Maker o un Taker? ¿Qué Token (tokenId) quieres comprar?

• ¿Cuánto quieres pagar (makerAmount)?

• ¿Cuánto quieres recibir (takerAmount)?

Cuando firmas, simplemente estás sellando estos datos con tu clave privada, probando que "realmente quiero hacer esto". Luego, estos datos firmados se envían al servidor centralizado de Polymarket y se almacenan en un Libro de Órdenes de Límite Central (CLOB) fuera de la cadena (off-chain).

En esta etapa, no ha sucedido nada en la cadena de bloques. Tu dinero sigue en tu billetera y los tokens no han sido transferidos. Tu orden es solo un registro en la base de datos.

1.2 Expresión implícita del precio

Pausemos el tiempo en el momento en que envías la orden. Si observas de cerca la estructura de órdenes de los contratos subyacentes de Polymarket, encontrarás algo muy contraintuitivo: no hay un campo de "precio" en los datos de firma de la orden.

¿Cómo es esto posible? ¿Cómo puede haber una operación sin un precio?

En el diseño subyacente del protocolo de Polymarket, el precio es implícito. Se calcula en función de la cantidad que estás dispuesto a pagar y la cantidad que deseas recibir.

Si quieres comprar 100 contratos YES a un precio de $0.60:

• Necesitas pagar: $60 pUSD (makerAmount = 60)

• Quieres recibir: 100 contratos YES (takerAmount = 100)

• Precio implícito = makerAmount / takerAmount = 60 / 100 = $0.60

Si quieres vender 100 contratos YES a un precio de $0.60:

• Necesitas pagar: 100 contratos YES (makerAmount = 100)

• Quieres recibir: $60 pUSD (takerAmount = 60)

• Precio implícito = takerAmount / makerAmount = 60 / 100 = $0.60

(Nota: Aunque en el último SDK V2, los desarrolladores pueden ingresar directamente el precio y el tamaño, el SDK aún los convierte a makerAmount y takerAmount durante la firma subyacente. La inteligencia de este diseño radica en que el contrato inteligente no necesita entender qué es el "precio"; solo necesita manejar la lógica de "intercambio de activo A por activo B". Esto simplifica enormemente la lógica de cálculo en la cadena y reduce el consumo de Gas.)

1.3 Operador: El "policía de tráfico" de Polymarket

Dado que todas las órdenes están fuera de la cadena, ¿cómo se convierten en transferencias de activos reales en la cadena?

Esto nos lleva al papel de caja negra más central en la arquitectura de Polymarket: el Operador.

En el contrato inteligente ctf-exchange-v2, hay un modificador crucial: onlyOperator. Esto significa que solo una dirección específica controlada por Polymarket tiene la autoridad para llamar a funciones de ejecución como matchOrders y fillOrder.

Esto es completamente diferente de las DeFi tradicionales. En Uniswap, cualquiera puede llamar al contrato de enrutamiento. Pero en Polymarket, no puedes emparejar operaciones en la cadena tú mismo. Todo emparejamiento debe ser enviado por el Operador.

¿Por qué está diseñado de esta manera? Para eliminar el MEV (Valor Extraíble por Mineros) y el front-running.

En los libros de órdenes tradicionales en cadena, si alguien coloca una orden grande a un precio muy bajo, todos los bots de arbitraje pujarán frenéticamente en el Mempool (aumentando las tarifas de Gas) para intentar adelantarse a otros y consumir esa orden. Esto provoca que las tarifas de Gas se disparen y una mala experiencia para los usuarios comunes.

En Polymarket, todas las órdenes están en el CLOB fuera de la cadena. El motor de emparejamiento del Operador calcula quién debe operar con quién en el servidor, luego empaqueta el resultado en una transacción, que es enviada a la cadena por el Operador.

Debido a que solo el Operador puede enviar los resultados del emparejamiento, incluso si los bots en el Mempool ven esta transacción, no pueden hacer front-running porque no tienen la autoridad para llamar a las funciones de ejecución.

Esta es una arquitectura típica de "descentralización híbrida". El emparejamiento y la ordenación están centralizados (decididos por el Operador), pero la liquidación y la custodia de fondos están descentralizadas (ejecutadas por contratos inteligentes).

El Operador puede decidir a quién emparejar primero y a quién después, pero absolutamente no puede robar tus fondos porque debe proporcionar los datos EIP-712 que tú firmaste, y el contrato verificará estrictamente la firma.

P.D: Sin embargo, debo mencionar que nuestro equipo de @insidersdotbot parece haber descubierto recientemente una forma de explotar este mecanismo, permitiendo a los seguidores hacer front-running o retrasar significativamente las transacciones. Si hay alguna actualización, la anunciaremos en la cuenta oficial tan pronto como sea posible.

Capítulo 2: La economía del Relayer

2.1 La ilusión de "sin Gas"

Uno de los mayores puntos de venta de Polymarket son sus "transacciones sin Gas" para los usuarios. Solo necesitas pUSD para operar, sin necesidad de comprar POL (anteriormente MATIC) para mantener en tu billetera.

Pero las leyes físicas de la cadena de bloques no pueden violarse: mientras haya un cambio de estado en Polygon (como una transferencia de activos), alguien debe pagar las tarifas de Gas.

Dado que tú no pagaste, ¿quién lo hizo? La respuesta es: el Relayer.

2.2 La red de retransmisión del Relayer

Polymarket no permite que los usuarios envíen transacciones ellos mismos, sino que ha desplegado una infraestructura llamada Relayer Client (relayer-v2.polymarket.com).

En la arquitectura inicial, dichos servicios generalmente dependían de servicios de nivel empresarial como OpenZeppelin Defender Relay, manteniendo un grupo de firmantes para resolver conflictos de nonce bajo alta concurrencia.

Cuando tu aplicación crea una transacción (como Aprobar tokens, Redimir ganancias), la firmas con tu clave privada y la envías al Relayer. El Relayer actúa como un "Patrocinador de Transacciones", enviando esta transacción a la cadena y cubriendo las tarifas de Gas con su propio fondo común.

Arquitectura del Relayer y ciclo económico

2.3 ¿La lana sale de la oveja?

En muchas arquitecturas de meta-transacciones tempranas, después de que el Relayer cubre el Gas, generalmente deduce una tarifa del depósito del usuario (como 0.3% o unos pocos dólares fijos) para compensar los costos de Gas.

Pero Polymarket es extremadamente agresivo: en la arquitectura V2 actual, realmente cubren el monto total por ti.

La documentación oficial establece claramente: "Polymarket paga el gas para todas las operaciones enrutadas a través del relayer". Ya sea desplegar billeteras, autorizar tokens, o dividir (Split), fusionar (Merge) o redimir (Redeem), todo es sin gas y no se cobran tarifas operativas ocultas.

¿Por qué Polymarket está dispuesto a asumir esta pérdida?

Porque los costos de Gas en Polygon son muy bajos (generalmente solo unos pocos centavos), y la experiencia sin gas puede atraer una afluencia masiva de usuarios de Web2. Mientras los usuarios incurran en una pequeña tarifa de Taker durante el trading (que se discutirá más adelante), es suficiente para cubrir este costo de Gas extremadamente bajo.

Sabiendo esto, surge naturalmente la siguiente pregunta: ¿qué impacto tiene esta arquitectura "sin gas" en nuestro trading?

El mayor costo oculto es la latencia. Tu orden no solo tiene que pasar por el motor de emparejamiento de Polymarket, sino que si es una operación directa en cadena, también tiene que pasar por la verificación del Relayer, la estimación de Gas y la asignación de cola.

Capítulo 3: Tres métodos de emparejamiento, ¿y por qué los compradores también pueden operar entre sí?

Ahora entramos en la parte más dura y contraintuitiva de toda la arquitectura de Polymarket.

En los intercambios tradicionales (como el libro de órdenes de Binance), la lógica de emparejamiento es muy simple: Alicia quiere comprar 1 token por $60, Bob quiere vender 1 token por $60. El intercambio los empareja, el token pasa de Bob a Alicia y el dinero pasa de Alicia a Bob. Fin de la historia.

Pero en Polymarket (basado en el Marco de Tokens Condicionales CTF), las cosas son completamente diferentes. Porque aquí, los tokens pueden ser "creados de la nada" y "destruidos de la nada".

Cuando abres el código fuente de ctf-exchange-v2, encontrarás tres rutas de liquidación de activos completamente diferentes: COMPLEMENTARY, MINT y MERGE.

Estructura general de Complementary, Mint y Merge

3.1 COMPLEMENTARY (Emparejamiento complementario): Trading de segunda mano tradicional

Este es el método de emparejamiento más fácil de entender y el único método que tienen los intercambios tradicionales.

Escenario: El mercado ha existido por un tiempo y todos tienen fichas.

• Alicia quiere comprar 100 YES por $0.60.

• Bob tiene YES y quiere vender 100 YES por $0.60.

El Operador encuentra estas dos órdenes (COMPRA vs VENTA) y las empaqueta en la cadena. El contrato inteligente ejecuta una transferencia directa entre pares:

1. Transfiere 100 YES de la dirección de Bob a Alicia.

2. Transfiere $60 pUSD de la dirección de Alicia a Bob.

Este mecanismo tiene las siguientes características matemáticas y de ingeniería:

• Juego de suma cero: El suministro total de tokens del sistema no ha cambiado.

• Consumo mínimo de Gas: Solo involucra transferencias básicas, sin las operaciones complejas de CTF.

• Estandarización: En un mercado maduro y líquido, la gran mayoría de las operaciones diarias se realizan de esta manera.

3.2 MINT (Emparejamiento de acuñación): Creando liquidez de la nada

Esta puede ser la innovación más revolucionaria en Polymarket e incluso en toda la historia financiera.

Para explicarlo mejor, podemos referirnos a este escenario: Un mercado completamente nuevo acaba de lanzarse y nadie tiene tokens YES o NO.

• Alicia es extremadamente optimista; quiere comprar 100 YES por $0.60.

• Bob es extremadamente pesimista; quiere comprar 100 NO por $0.40.

Nota: ¡Ambos son compradores! ¡Ninguno tiene los tokens que el otro quiere!

En un libro de órdenes tradicional, estas dos órdenes solo pueden mirarse entre sí y nunca podrán ejecutarse. En Polymarket, si ocurre una COMPRA vs COMPRA (y los tokens son complementarios), ¡el Operador emparejará estas dos órdenes!

1. El contrato inteligente deduce $60 pUSD de la cuenta de Alicia.

2. El contrato inteligente deduce $40 pUSD de la cuenta de Bob.

3. El contrato inteligente toma estos $100 pUSD, los bloquea como garantía y luego llama a la función _mint para crear 100 YES y 100 NO de la nada.

4. Envía 100 YES a Alicia.

5. Envía 100 NO a Bob.

La activación de este mecanismo debe basarse en una condición matemática estricta: la suma de las ofertas de los compradores debe ser mayor o igual a $1.00.

Si Alicia ofrece $0.60 por YES y Bob ofrece $0.35 por NO, el total es solo $0.95. El contrato inteligente no puede acuñar un par de tokens completo por valor de $1.00 con $0.95. Este emparejamiento fallará directamente.

Mecanismo de emparejamiento MINT

Desde la perspectiva de un creador de mercado, este mecanismo es el arma definitiva para resolver el problema del "arranque en frío". Cuando el mercado recién abre, los creadores de mercado no necesitan gastar dinero para acuñar un montón de tokens para mantener (lo que ocuparía muchos fondos). Solo necesitan colocar órdenes de compra en ambos lados, YES y NO, simultáneamente (por ejemplo, $0.49 por YES, $0.49 por NO). Cuando los inversores minoristas vengan a vender, se activará la lógica de acuñación.

3.3 MERGE (Emparejamiento de fusión): La aniquilación de la liquidez

Donde hay creación, hay destrucción. MERGE es el proceso inverso de MINT.

Veamos un caso inverso. El mercado está a punto de cerrar y todos están cerrando sus posiciones.

• Alicia tiene 100 YES y quiere vender a $0.60.

• Bob tiene 100 NO y también quiere vender a $0.40.

Nota: ¡Ambos son vendedores! Nadie está dispuesto a pagar pUSD para comprar sus tokens.

En este punto, el mecanismo de Polymarket entrará en acción nuevamente. Al encontrar VENTA vs VENTA, el Operador hará su magia de nuevo:

1. El contrato inteligente toma 100 YES de Alicia.

2. El contrato inteligente toma 100 NO de Bob.

3. El contrato inteligente llama a la función _merge para destruir completamente estos 100 pares de YES+NO y desbloquear $100 pUSD de la tesorería.

4. Envía $60 pUSD a Alicia.

5. Envía $40 pUSD a Bob.

El mecanismo de fusión tiene las siguientes características matemáticas y financieras:

• Mecanismo deflacionario: El suministro total de tokens del sistema disminuye.

• Canal de salida: Asegura que incluso sin un "comprador", siempre que los precios de venta de YES y NO puedan sumar $1.00 (de hecho, renunciando a $1.00 de espacio), todos aún pueden retirar su dinero.

Entender estos tres métodos de emparejamiento te da una idea del ciclo de vida del mercado de Polymarket:

• Etapa temprana (Dominio de MINT): El mercado acaba de abrir y no hay tokens. Tanto los lados alcistas como bajistas inyectan fondos continuamente en el sistema a través del mecanismo MINT a cambio de tokens. El suministro total aumenta rápidamente.

• Etapa intermedia (Dominio de COMPLEMENTARY): El mercado tiene amplia liquidez y la mayoría de las operaciones son intercambios de tokens existentes. El suministro total se estabiliza.

• Etapa tardía (Dominio de MERGE): Los resultados se vuelven más claros y todos comienzan a cerrar sus posiciones. Tanto los lados alcistas como bajistas destruyen tokens a través del mecanismo MERGE para retirar su dinero. El suministro total disminuye.

Ten en cuenta que estas tres rutas no son elegidas subjetivamente por el Operador, sino que están estrictamente determinadas por las reglas de enrutamiento del contrato inteligente basadas en la dirección de las órdenes (COMPRA vs VENTA).

Ciclo de vida del mercado

Capítulo 4: Split/Merge/Redeem, ¿y por qué tu PnL es incorrecto?

Habiendo entendido el mecanismo de emparejamiento, veamos tres operaciones subyacentes que puedes usar todos los días pero que nunca has entendido realmente su impacto financiero: Split, Merge y Redeem.

Estas tres operaciones son las operaciones a nivel atómico de Polymarket. No son "operaciones" (no pasan por el libro de órdenes, no incurren en tarifas), sino que interactúan directamente con el contrato inteligente para la conversión de activos.

• Split: Le das al contrato $1 pUSD y el contrato te da 1 YES y 1 NO. El costo es siempre exactamente $1.

• Merge: Le das al contrato 1 YES y 1 NO y el contrato te devuelve $1 pUSD. La ganancia es siempre exactamente $1.

• Redeem: Después de que el mercado determina al ganador y al perdedor, el token ganador se intercambia por $1 pUSD y el token perdedor se pone a cero.

Comparación antes y después de la operación Split

4.1 ¿Quién usa estas operaciones?

• Creadores de mercado: Son los mayores usuarios de Split. Los creadores de mercado necesitan colocar órdenes en ambos lados simultáneamente, pero no quieren comprar tokens en el mercado (lo que incurre en tarifas). Dividen directamente $100,000 en 100,000 YES y 100,000 NO, y luego los colocan en el libro de órdenes.

• Arbitrajistas: Son los mayores usuarios de Merge. Cuando el mercado experimenta una fijación de precios errónea temporal, como que YES cae a $0.40 y NO cae a $0.55, los arbitrajistas comprarán rápidamente 1 YES y 1 NO (costo total $0.95) y luego llamarán inmediatamente a Merge para recuperar $1, obteniendo una ganancia neta libre de riesgo de $0.05. La condición matemática es muy clara: cuando Precio(YES) + Precio(NO) < 1 - tarifas, es obvio comprar y fusionar.

Por lo tanto, cuando intentas seguir el dinero inteligente de un arbitrajista o el dinero inteligente de un creador de mercado, debes evaluar con precisión el impacto de Split/Merge en el PnL. De lo contrario, no es un "dinero inteligente" que valga la pena referenciar.

Actualmente, incluyendo al propio Polymarket, nadie puede resolver el problema del cálculo de PnL. Por supuesto, es posible que lo hayas adivinado: insiders.bot ya ha resuelto este problema en los cálculos de PnL y en los navegadores de dinero inteligente.

4.2 Trampa de PnL: ¿Por qué tu ganancia es incorrecta?

Como se mencionó anteriormente, este es el error más común en todo el ecosistema de Polymarket. Casi todas las herramientas de seguimiento de PnL de terceros, incluidas algunas API oficiales, han tropezado aquí.

Déjame calcular un ejemplo para ti y verás qué tan profunda es esta trampa.

Paso 0: Supongamos que tienes un capital de $100. Eres optimista sobre el mercado "Ethereum superando los $5000".

Paso 1: Gastas $50 para ejecutar un Split. Ahora tienes 50 YES y 50 NO. Tu efectivo sigue siendo $50.

Paso 2: Sientes que 50 YES no son suficientes, así que vas al mercado y compras 50 YES a un precio de $0.40. Cuesta $20. El efectivo sigue siendo $30.

Paso 3: Vendes los 50 NO que tienes a un precio de $0.35. Recuperas $17.50. El efectivo se convierte en $47.50.

Ahora, tienes 100 contratos YES. ¿Cuál es tu costo real?

Cómo calculan la mayoría de las tablas de clasificación (Algoritmo incorrecto):

Solo miran tus registros de "trading". Ven que compraste 50 YES, costando $20. Ignoran completamente el Split (porque eso no es una operación).

Así que piensan que tu costo es: $20 / 50 = $0.40 cada uno.

Si el precio de mercado actual de YES sube a $0.60, mostrarían tu ganancia como: 100 × $0.60 - $20 = $40.

Cómo deberías calcular realmente (Algoritmo correcto, y el que usa insiders.bot):

Tu salida total de efectivo: $50 (Split) + $20 (compra) = $70.

Tu entrada total de efectivo: $17.50 (venta de NO)

Tu inversión neta: $70 - $17.50 = $52.50

Tu costo real: $52.50 / 100 = $0.525 cada uno.

Si el precio de mercado actual de YES es $0.60, tu ganancia real es: 100 × $0.60 - $52.50 = $7.50.

¿Ves la diferencia? La tabla de clasificación muestra que ganaste $40, pero en realidad solo ganaste $7.50. Los $32.50 de "ganancia fantasma" en el medio se deben a que el sistema no manejó correctamente el costo del Split y los ingresos de la venta de NO.

La fórmula matemática correcta de PnL debería ser:

PnL Total = Σ(ingresos por venta) + Σ(ingresos por Merge) + Σ(ingresos por Redeem) - Σ(gastos de compra) - Σ(gastos de Split) + Valor de mercado de la posición actual

Es por esto que ves a algunos grandes jugadores en la tabla de clasificación mostrando pérdidas de millones, pero en realidad, están haciendo una fortuna. Porque las posiciones ganadoras, después de ser redimidas, muchas herramientas "borran" estas posiciones de los registros históricos, dejando solo aquellas que aún están en pérdida.

Trampa de cálculo de PnL

Capítulo 5: Curva de tarifas

Si operas con frecuencia, descubrirás que las tarifas de Polymarket no son un porcentaje fijo. A veces te cobran $10 por comprar un contrato de $1000 y, a veces, solo $2.

¿Por qué? Echemos un vistazo a la fórmula de tarifas oculta en lo profundo del código:

Tarifa = C × tasaDeTarifa × p × (1 - p) (donde C es el monto de la transacción, p es el precio)

5.1 ¿Por qué p(1-p)?

Supongamos que quieres comprar 100 YES a una tasa del 2%:

• Si el precio de YES es $0.50: Tarifa = 100 × 2% × 0.50 × 0.50 = $0.50

• Si el precio de YES es $0.90: Tarifa = 100 × 2% × 0.90 × 0.10 = $0.18

• Si el precio de YES es $0.10: Tarifa = 100 × 2% × 0.10 × 0.90 = $0.18

¿Ves el patrón? La tarifa es más alta cuando el precio está en 0.50 (equilibrado). Cuando el precio se acerca a 0 o 1 (el resultado es casi seguro), la tarifa es extremadamente baja.

Más importante aún, hay simetría. Comprar YES a $0.90 y comprar NO a $0.10 son matemáticamente equivalentes. Si te cobran una tarifa alta por comprar YES a $0.90 y una tarifa baja por comprar NO a $0.10, los arbitrajistas se volverán locos comprando NO y luego arbitrando a través del mecanismo MINT. El diseño de p(1-p) asegura que, sin importar desde qué lado expreses tu opinión, los costos de fricción cobrados por el sistema sean absolutamente simétricos.

5.2 La belleza matemática oculta

Si has estudiado estadística, estarás muy familiarizado con la fórmula p(1-p). Es la fórmula de varianza de la distribución de Bernoulli (lanzamiento de moneda).

En todo el diseño del sistema de Polymarket, p(1-p) es la "fórmula de Dios":

1. Es la curva de tarifas: Cuanto mayor es la incertidumbre (varianza), más altas son las tarifas cobradas por el sistema.

2. Refleja la entropía de la información: Cuando apuestas al 50%, proporcionas la mayor cantidad de información nueva al mercado, por lo que tu costo es el más alto.

¿Quién paga las tarifas? Siempre es el Taker. El Maker siempre está exento de tarifas.

Este mecanismo alinea perfectamente los incentivos: cuando el mercado es más incierto (50/50), a los participantes tempranos se les cobrarán las tarifas más altas, protegiendo a los creadores de mercado de choques innecesarios; mientras que cuando el mercado es casi seguro, tarifas extremadamente bajas alientan a los arbitrajistas a entrar y empujar los precios hacia el 1 o 0 final.

Curva de tarifas

Capítulo 6: Riesgo Negativo, también conocido como la magia más elegante en DeFi

Si has jugado en mercados de múltiples resultados como elecciones, los Oscar o eventos deportivos en Polymarket, debes haber encontrado mercados de Riesgo Negativo.

Esta es la parte que más quema el cerebro de todo el artículo, pero también es la que mejor refleja la estética de la ingeniería de contratos inteligentes.

P.D. Esta es también la parte que nuestro cofundador @DakshBigShit resolvió después de un maratón de 36 horas mientras desarrollaba nuestra propia API.

6.1 Puntos de dolor de los mercados tradicionales de múltiples resultados

Supongamos que hay cuatro candidatos: A, B, C, D. Odias absolutamente a A y estás seguro de que A no puede ganar. Quieres "vender en corto" a A.

En un mercado binario tradicional, solo necesitas comprar el contrato NO de A. Pero en un mercado de múltiples resultados, si A pierde, significa que uno de B, C o D debe ganar. Por lo tanto, "vender en corto a A" es matemáticamente estrictamente equivalente a "ir en largo en B + ir en largo en C + ir en largo en D". (Esta frase es muy importante; léela repetidamente hasta que la entiendas.)

Si vas al mercado y compras contratos YES para B, C y D por separado, encontrarás un gran problema: muy baja eficiencia de capital. Porque necesitas pagar tres montos separados, y si los precios de estos tres suman más de $1.00, incluso podrías incurrir en una pérdida.

6.2 La magia del Adaptador de Riesgo Negativo (NegRiskAdapter)

Polymarket ha desplegado un contrato inteligente dedicado NegRiskAdapter para resolver este problema. Proporciona una función llamada convertPositions.

El propósito de la función es convertir instantáneamente tus contratos NO en contratos YES para todos los demás candidatos y devolverte un monto en efectivo.

Demostremos matemáticamente por qué esta conversión conserva el valor.

Configuración del escenario: Hay n candidatos.

• Tienes A acciones de contratos NO para el candidato 1 y A acciones de contratos NO para el candidato 2 (estás vendiendo en corto a ambos, 1 y 2).

• Tienes un total de m contratos NO diferentes (aquí m=2).

Antes de la conversión, el valor real de tus tenencias (en todas las líneas de tiempo posibles):

• Si gana el candidato 1: NO_1 no vale nada, NO_2 vale $1. Valor total = A.

• Si gana el candidato 2: NO_1 vale $1, NO_2 no vale nada. Valor total = A.

• Si gana el candidato 3 (gana cualquiera a quien no vendiste en corto): NO_1 vale $1, NO_2 vale $1. Valor total = 2A.

¿Qué te da el contrato después de llamar a convertPositions?

La fórmula es: devuelve A × (m-1) en efectivo, más A acciones de contratos YES para los candidatos 3, 4, ... n.

En este ejemplo, devuelve: A × (2-1) = A en efectivo! Más A acciones de YES para el candidato 3, A acciones de YES para el candidato 4...

Después de la conversión, el valor real de tus tenencias (en todas las líneas de tiempo posibles):

• Si gana el candidato 1: tus YES_3 y YES_4 no valen nada. Solo tienes efectivo A. Valor total = A. (¡Igual que antes de la conversión!)

• Si gana el candidato 2: tus YES_3 y YES_4 no valen nada. Solo tienes efectivo A. Valor total = A. (¡Igual que antes de la conversión!)

• Si gana el candidato 3: tu YES_3 vale $1, los demás no valen nada. Más efectivo A. Valor total = A + A = 2A. (¡Igual que antes de la conversión!)

Q.E.D. Independientemente de cómo se desarrolle el mundo, el valor antes y después de la conversión es absolutamente igual.

Prueba matemática de la conversión de Riesgo Negativo

6.3 ¿Por qué es este un proceso de aumento de entropía "irreversible de una sola vía"?

Este mecanismo de conversión tiene una propiedad física extremadamente encantadora: es de una sola vía e irreversible.

Puedes convertir NO en YES + efectivo. Pero nunca puedes convertir YES + efectivo de vuelta en NO.

¿Por qué? Porque a nivel subyacente del contrato inteligente, cuando conviertes NO en YES, el contrato realmente envía tus contratos NO a una dirección de agujero negro (Burn), y luego usa el espacio de garantía liberado de esto para "sintetizar" nuevos contratos YES. Esto no requiere inyectar nuevos fondos externos.

Pero si quieres revertirlo y convertir YES en NO, necesitas crear nueva garantía de la nada (porque los contratos NO cubren un rango mucho más amplio que YES). El adaptador no tiene la autoridad para usar los fondos de la tesorería.

Esto es como romper un huevo. NO es el huevo entero, que contiene todas las posibilidades. La operación de conversión es como romper el huevo, separándolo en yema (YES) y clara de huevo (efectivo). El proceso conserva el valor, pero nunca puedes volver a unirlos en un huevo entero.

Aquí hay una gran oportunidad de arbitraje: si descubres que el precio del NO de un determinado candidato es mayor que el precio total de los YES de todos los demás candidatos, puedes comprar ese NO, llamar a convertPositions para obtener efectivo y un montón de YES, y luego vender inmediatamente esos YES. Esta es la estrategia de arbitraje libre de riesgo de más alto nivel en mercados de múltiples resultados.

Capítulo 7: Los extremos físicos de la velocidad

Finalmente, hablemos de la dimensión más brutal del trading: el tiempo.

En el trading de alta frecuencia tradicional, discutimos microsegundos (millonésimas de segundo). En Polymarket, discutimos milisegundos. Pero hay una gran desigualdad estructural aquí.

Si te has mezclado en la sección de trading algorítmico de Reddit, encontrarás que todos los programadores que desarrollan bots para Polymarket se han quejado de lo mismo: "¿Por qué siempre tengo que esperar 300 milisegundos para las órdenes Taker, mientras que las órdenes Maker solo toman 25 milisegundos?"

7.1 ¿Por qué las órdenes Maker son rápidas y las órdenes Taker son lentas?

• Cuando colocas un Maker (orden límite): Tu orden (datos de firma) se envía al servidor de Polymarket. El servidor verifica la validez de la firma e inserta directamente este registro en la base de datos del CLOB (libro de órdenes) en la memoria. Luego te devuelve inmediatamente un ACK (reconocimiento). Todo el proceso ocurre completamente fuera de la cadena y requiere solo una escritura en la base de datos. Tiempo tomado: ~25 milisegundos.

• Cuando colocas un Taker (orden de mercado): Tu orden se envía al servidor. El motor de emparejamiento descubre que tu orden puede coincidir con un Maker en el libro de órdenes. En este punto, el Operador debe iniciar una compleja tubería de liquidación:

  1. Decidir qué ruta de emparejamiento usar (COMPLEMENTARY, MINT o MERGE).

  2. Construir datos de transacción en cadena que contengan firmas de ambas partes.

  3. Enviar la transacción al Relayer.

  4. El Relayer estima el Gas y asigna el Nonce.

  5. Transmitir la transacción a los nodos de Polygon.

  6. Esperar a que los nodos confirmen que esta transacción no se revertirá debido a saldo insuficiente u otras razones.

  Todo el proceso abarca múltiples microservicios e incluso toca los bordes de la cadena de bloques. Tiempo tomado: ~250 a 300 milisegundos.

7.2 ¿Qué significan estos 250 milisegundos?

Esta brecha física de 250 milisegundos da forma profundamente al ecosistema de Polymarket.

Primero, es muy difícil hacer front-running en Polymarket. Debido a que todas las órdenes Taker deben hacer cola esperando a que el Operador las procese, no puedes saltarte la fila aumentando las tarifas de Gas. El front-running en Mempool es temporalmente un problema inexistente aquí.

Segundo, la ventaja absoluta de las estrategias Maker. Debido a que la cancelación (Cancel) y las órdenes Maker son operaciones fuera de la cadena, solo toman 25 milisegundos. Cuando ocurren noticias de última hora, los creadores de mercado inteligentes pueden usar esta diferencia de tiempo de 250 milisegundos para cancelar sus órdenes antes de que se liquiden las órdenes Taker (esto se llama evitar la selección adversa).

7.3 El tiempo de inactividad de 90 segundos cada martes por la mañana

Hay otro detalle poco conocido sobre el tiempo. Según la documentación oficial, todos los martes a las 7:00 AM hora del Este, el motor de emparejamiento de Polymarket se reinicia. Durante estos aproximadamente 90 segundos, el sistema deja de procesar cualquier emparejamiento y la API devuelve un error HTTP 425 (Demasiado temprano).

Más cruelmente, V2 introdujo un mecanismo de Heartbeat. Si el servidor no recibe un latido del cliente en 10 segundos, cancelará automáticamente todas las órdenes abiertas para ese usuario. Durante estos 90 segundos de reinicio, los latidos de los creadores de mercado se interrumpen a la fuerza y sus órdenes serán eliminadas colectivamente por el sistema.

Estos 90 segundos representan un verdadero "vacío de liquidez" en el sistema. Para los modelos de fijación de precios de opciones, cómo fijar el precio del Theta (decaimiento temporal) de estos 90 segundos, y cómo aprovechar el mercado cuando el motor se reanuda en el segundo 91, es el rompecabezas definitivo para las mejores plataformas y estudios cuantitativos.

Comparación de la línea de tiempo de retraso

Capítulo 8: La reestructuración épica de V2 y la batalla definitiva contra el "Ghost Fill"

Si has leído hasta aquí, has captado el marco central de Polymarket. Pero si quieres seguir ganando dinero en este mercado en 2026, debes entender el gran terremoto que acaba de ocurrir.

Entre febrero y mayo de 2026, Polymarket se sometió silenciosamente a una épica actualización de arquitectura V2. Esta actualización no solo reestructuró las fórmulas de garantía y tarifas, sino que, más importante aún, lanzó la batalla definitiva para resolver el error más notorio en los mercados de predicción, a saber, los rellenos fantasma (Ghost Fill).

8.1 ¿Qué es Ghost Fill? La desconexión de estado entre la cadena y fuera de la cadena

Antes de la actualización de Polymarket V2, innumerables creadores de mercado y bots cuantitativos fueron atormentados por un fenómeno: tu bot captura una gran oportunidad en un mercado de nivel de 5 minutos (como BTC Up/Down 5m) y envía inmediatamente una solicitud Taker. La API de Polymarket devuelve instantáneamente: "¡Emparejado! ¡Éxito!". Tu alerta de Telegram también aparece con la emoción de "FILLED". Pero cuando abres Polygonscan para verificar el explorador de blockchain, descubres que esta transacción está marcada como REVERTED (fallida), desperdiciando tarifas de Gas por nada. Y tu posición permanece sin cambios.

El libro de órdenes muestra claramente una coincidencia, pero la cadena de bloques dice que no pasó nada. Esto es un relleno fantasma (Ghost Fill).

Para entender la esencia de este error, debemos volver a la arquitectura subyacente discutida en el Capítulo 1: Emparejamiento fuera de la cadena + Liquidación en la cadena.

Cuando la orden de compra de Alicia y la orden de venta de Bob coinciden en el Libro de Órdenes de Límite Central (CLOB) fuera de la cadena, el sistema solo dibuja un signo igual entre estas dos órdenes en la base de datos. La transferencia real de activos requiere que el Operador empaquete las firmas de ambas partes y las envíe a la cadena Polygon para la ejecución de TransferFrom.

Esto crea una brecha de tiempo fatal. Durante esta brecha de tiempo, el estado de la billetera del usuario puede cambiar.

8.2 Dos rutas de ataque de Ghost Fill

En la era temprana de V1 y la V2 recién lanzada, los hackers y creadores de mercado maliciosos explotaron esta brecha de tiempo para inventar dos métodos de ataque altamente destructivos:

• Primero: Ataque de incremento de Nonce de bajo costo (Era V1)

  En la arquitectura V1, los estados de las órdenes se gestionaban mediante un nonce global (número aleatorio). Los jugadores maliciosos podían publicar locamente órdenes falsas altamente atractivas (Spoofing) fuera de la cadena. Cuando un comprador real muerde el anzuelo y la orden muestra una coincidencia fuera de la cadena, el jugador malicioso puede llamar a la función incrementNonce en la cadena antes de que el Operador la envíe.

  Esta operación cuesta muy poco (unos pocos centavos en Gas) pero puede invalidar instantáneamente todas las órdenes de nonce antiguas para esa dirección. Cuando el Operador envía la transacción emparejada en la cadena, el contrato inteligente encuentra que el nonce es incorrecto y se revierte directamente. El atacante escapa ileso, mientras que el comprador real no solo pierde la oportunidad de trading, sino que también puede ser engañado por el libro de órdenes falso.

• Segundo: "Órdenes Zombis" de billeteras vacías (V2 temprana)

  La actualización V2 eliminó el nonce global y utilizó un hash de orden único para gestionar los estados de cancelación, bloqueando la primera ruta. Pero los hackers descubrieron rápidamente una vulnerabilidad más profunda: el engaño de saldo. Un usuario malicioso puede depositar $1000 en una billetera, firmar un montón de órdenes límite por un valor total de $10,000 y luego transferir inmediatamente todo el dinero fuera de la billetera. Debido a que las órdenes de Polymarket están firmadas fuera de línea, siempre que la firma sea válida y la aprobación del token (Approval) no sea revocada, estas órdenes parecen "legítimas" para el motor de emparejamiento fuera de la cadena. Pero en realidad, el saldo de esta billetera es $0.

  Cuando tu bot consume estas "órdenes zombis" y el Operador envía en la cadena, la función TransferFrom de la biblioteca Solady subyacente arrojará un error (código de error 0x7939f424) debido a un saldo insuficiente en el otro lado. Tu transacción se revierte de nuevo.

8.3 ¿Por qué los intercambios tradicionales no tienen este problema?

Podrías preguntar: ¿por qué Binance o los intercambios descentralizados tradicionales (como Uniswap) no tienen este problema?

Porque Binance es puramente centralizado; tu dinero existe en su base de datos y tiene control absoluto. El emparejamiento y la deducción ocurren atómicamente. Y Uniswap es puramente en cadena; el emparejamiento y la deducción se completan en la misma transacción de un contrato inteligente, también atómicamente.

Pero Polymarket eligió una arquitectura híbrida: el emparejamiento fuera de la cadena busca velocidad, mientras que la liquidación en la cadena busca transparencia. Mientras tanto, los fondos de los usuarios se almacenan en billeteras completamente autocustodiadas (como EOA o Gnosis Safe), donde los usuarios tienen derechos de disposición absolutos y pueden transferir dinero en cualquier momento.

Mientras los estados de financiación en ambos extremos del emparejamiento estén vinculados a la billetera autocustodiada verdaderamente libre del usuario, la "desconexión de estado" siempre existirá.

8.4 La solución definitiva: Billetera de depósito (Tesorería asociada)

El 4 de mayo de 2026, Polymarket anunció oficialmente una actualización importante a nivel de protocolo central, reduciendo directamente la proporción de rellenos fantasma de un pico del 30% al 0.17%, y con tendencia a cero.

¿Cómo lo hicieron? La respuesta es la introducción de la Billetera de depósito (Tesorería asociada).

Polymarket finalmente se dio cuenta de que la forma fundamental de resolver los rellenos fantasma es restringir la "libertad absoluta" de fondos de los usuarios. Bajo la nueva arquitectura, los usuarios ya no pueden participar directamente en el emparejamiento fuera de la cadena con sus billeteras nativas (EOA). Primero debes depositar fondos en una Billetera de depósito controlada por un contrato inteligente.

En esta tesorería:

• Tienes propiedad pero no derechos de disposición inmediata absoluta.

• Cuando colocas una orden fuera de la cadena, la tesorería bloquea lógicamente el saldo disponible correspondiente.

• Si quieres retirar dinero de la tesorería, esta operación de retiro (Revocación de estado) en sí misma tiene asignado un costo de tiempo físico. Debe someterse a una verificación por parte del contrato inteligente para asegurar que no tengas órdenes pendientes siendo emparejadas.

Al introducir esta capa de búfer, Polymarket vincula a la fuerza el estado de emparejamiento fuera de la cadena y el estado de financiación en la cadena, eliminando completamente la posibilidad de "órdenes de billetera vacía". Esto no es solo una victoria de ingeniería, sino también un compromiso profundo y una reconstrucción de la contradicción entre la "autocustodia" y la "eficiencia de trading" en las finanzas descentralizadas.

8.5 Otras actualizaciones hardcore en V2

Además de la solución definitiva al Ghost Fill, la arquitectura V2 también incluye varias actualizaciones profundas que cambian el panorama del mercado:

• Transferencia de poder de pUSD: El 28 de abril, la garantía subyacente cambió completamente de USDC.e a pUSD. Esto permitió a Polymarket obtener control sobre los activos subyacentes que generan intereses, permitiéndole proporcionar a los usuarios recompensas por tenencia anualizadas de hasta el 4.00%. pUSD se convirtió en la nueva infraestructura de eficiencia de capital.

• Implementación de la fórmula perfecta p(1-p): Se abandonó la aproximación aproximada de min(p, 1-p) de la era V1, y la fórmula de tarifas se modificó directamente a la fórmula de varianza de Bernoulli perfecta p × (1-p). La suavidad absoluta permite matemáticamente que los modelos de fijación de precios de los arbitrajistas sean más precisos.

• Eliminación de reductores de velocidad artificiales: En los primeros días, para proteger a los creadores de mercado de ser vencidos por bots de API, el código tenía codificado un retraso de Taker de hasta 500 milisegundos. Con la mejora del rendimiento del motor V2 y la introducción del mecanismo de Heartbeat (desconectarse durante 10 segundos borra las órdenes), el equipo oficial eliminó por completo este reductor de velocidad artificial a finales de febrero, declarando que Polymarket ha entrado oficialmente en el combate cuerpo a cuerpo de HFT (trading de alta frecuencia) a nivel de microsegundos. (Esta es también la razón por la que en insiders.bot nos estamos preparando para abrir el código fuente de la API pronto para unirnos a esta batalla.)

Conclusión: Ver a través de esta máquina desde cero

Desde el momento en que haces clic para colocar una orden:

• Tu firma se envía al libro de órdenes fuera de la cadena.

• El Relayer quema su Gas para allanar el camino para ti.

• El Operador busca la ruta de emparejamiento óptima para ti entre COMPLEMENTARY, MINT y MERGE.

• La curva de tarifas extrae elegantemente pequeños costos de fricción usando la fórmula p(1-p).

• Si tu operación es compleja, el NegRiskAdapter incluso realizará la alquimia de la conservación de material para ti.

En última instancia, todo se liquida dentro de esos decisivos 250 milisegundos. (Esta es también la razón por la que insiders.bot considera que la transparencia y la velocidad de seguir las operaciones son cruciales.)

Tu dinero no ha desaparecido. Solo está siguiendo estrictamente las leyes físicas de esta máquina precisa llamada ctf-exchange-v2, fluyendo hacia donde debería ir.

La próxima vez que veas probabilidades escandalosas o una oportunidad de arbitraje tentadora en Polymarket, no te apresures a hacer clic en Comprar. Primero, recorre los engranajes de esta máquina en tu mente.

Entendiendo estos "Fa" fundamentales, combinados con el "Dao" correcto, seguramente serás invencible.

P.D. La versión PDF de este artículo también está lista. Sigue a @insidersdotbot y envía un mensaje directo con "PDF" para obtenerla rápidamente.

Referencias

[1] Documentación oficial de Polymarket: Reinicios del motor de emparejamiento y mecanismo de Heartbeat.

[2] Documentación oficial de Polymarket: Tarifas y fórmula de cálculo p(1-p).

[3] Código fuente del contrato inteligente Polymarket/ctf-exchange-v2 (GitHub).

[4] NegRiskAdapter.sol: Implementación matemática de conversiones de múltiples resultados.

[5] leolabs.me: "Por qué tu PnL de Polymarket es incorrecto" (análisis contable de Split/Merge).

[6] Reddit r/algotrading y Binance Square: Anuncios de eliminación de retraso de Taker de Polymarket (febrero de 2026).

[7] Guía de migración de Polymarket V2: Transición de USDC.e a pUSD (abril de 2026).