Arbitraje en prediction markets: cómo cubrirse entre Polymarket y mirrors

Si ya operas un bot de Polymarket, la siguiente oportunidad quizá no sea crear otro modelo de predicción. Puede ser una segunda superficie de liquidez donde tu stack de pricing, ejecución y riesgo trabaje más.

El prediction market arbitrage parece sencillo en una hoja de cálculo: encontrar el mismo evento en dos venues, comprar el lado barato, vender el caro y quedarse con la diferencia.

En producción, el reto es demostrar que ambos instrumentos tienen el mismo payoff, mapear correctamente sus tokens de resultado, ejecutar los dos legs a precios reales y sobrevivir hasta el settlement.

Esto es especialmente importante en un mirror. Un mirror de Polymarket puede ofrecer una referencia externa y una posible cobertura para el flujo de Kuest, pero no convierte toda diferencia de precio en arbitraje sin riesgo.

Este artículo está dirigido a market makers cripto-native, traders cuantitativos y desks que ya entienden la ejecución cross-venue.

¿Qué es el arbitraje en prediction markets?

El arbitraje en prediction markets busca capturar una diferencia entre contratos económicamente equivalentes o construir una posición cuyo payoff combinado sea conocido mientras el coste de entrada sea menor.

Arbitraje con outcomes complementarios

En un mercado binario, YES y NO son resultados complementarios. Si puedes comprar YES en un venue y NO en otro por menos de 1 dólar en total, y ambos contratos tienen exactamente las mismas reglas de resolución, el valor bruto al liquidar es 1 dólar.

edge bruto = 1 $ - (precio de entrada de YES + precio de entrada de NO)

Fees, gas, slippage, partial fills, capital bloqueado y costes de settlement reducen el edge real.

Cobertura cross-venue del inventario

Un market maker no siempre intenta bloquear un payoff garantizado. Puede cotizar en Kuest y usar Polymarket para reducir el inventario creado por el flujo de clientes.

Si un cliente compra 1.000 contratos YES a tu ask en Kuest, tu sistema puede comprar exposición YES equivalente en Polymarket, siempre que el mercado externo tenga profundidad. Eso es una cobertura de inventario, no necesariamente arbitraje sin riesgo: el hedge puede ejecutarse parcialmente, ser más caro o desaparecer.

La distinción afecta al bot, al modelo de capital y a la gestión de riesgo. La guía de PredictEngine explica por qué hay que usar precios ejecutables y no solo midpoints. La documentación de Preduck ayuda a entender cómo comparar mercados cross-venue.

Por qué los traders de Polymarket buscan arbitraje en mirrors

Polymarket es una referencia natural por sus datos CLOB, libros activos, gran flujo de traders y bots, y una infraestructura de mercado ya conocida.

Una segunda superficie puede aportar audiencia de un operador, flujo diferente, campañas de liquidez financiadas y una oportunidad para reutilizar infraestructura de Polygon, USDC, pricing, CLOB e inventario. El market maker puede combinar P&L de trading con una compensación comercial por mantener profundidad.

Kuest conecta frontends de operadores con discovery, matching, wallets y datos de lifecycle compartidos. Los mercados con los mismos outcome token IDs usan los mismos libros Kuest. Por eso dos páginas de operadores no son necesariamente dos venues independientes.

Una diferencia entre dos frontends Kuest no es automáticamente una oportunidad de arbitraje.

El edge puede estar entre el flujo de la red Kuest y una referencia externa como Polymarket, o entre un mercado propio y otro contrato cuya resolución se haya validado de forma estricta.

Cómo funcionan los mirrors de Kuest

“Mirror” describe la relación con una fuente externa seleccionada. No significa que el frontend incruste simplemente el libro de otra plataforma.

El operador puede combinar mirrors de Polymarket, mercados propios y fuentes compartidas seleccionadas. Controla marca, dominio, experiencia y operaciones. Kuest proporciona CLOB, datos, matching, acciones de wallet relayed y settlement en Polygon.

Para un market maker:

1. La fuente define la especificación. Revisa pregunta, outcomes, cierre, fuente de resolución y casos extremos.
2. Kuest crea una representación compatible. El mirror tiene metadata y contexto de libro propios.
3. El mapping de outcomes debe ser explícito. El bot debe saber qué token Kuest corresponde a YES y NO.
4. El flujo se atribuye al operador de origen. Site, bot y SDK pueden entrar en sus economics.
5. El settlement necesita controles propios. La relación de precios vale tanto como el lifecycle del mercado.

Consulta la arquitectura de Kuest y el repositorio open source para entender el modelo de Polygon, USDC, APIs y SDKs.

La Polymarket hedge strategy: operar el mismo outcome entre venues

Una Polymarket hedge strategy comienza con la posición real de tu libro Kuest, no con la suposición de que YES significa lo mismo en cualquier página.

Cubrir un quote ejecutado con el mismo outcome

Si vendes 1.000 YES en Kuest a 0,54 $ y el ask equivalente en Polymarket es 0,55 $, puedes recomprar inventario hasta la profundidad disponible. El resultado es la venta Kuest menos compra de hedge, fees, gas, slippage y adverse selection.

Si solo se ejecutan 600 contratos en Polymarket, los 400 restantes siguen siendo exposición.

Construir un par completo

Si puedes comprar YES en Kuest a 0,53 $ y NO en Polymarket a 0,43 $, el par cuesta 0,96 $ y paga 1 $ si las reglas son idénticas. El edge bruto es 0,04 $ por par, antes de costes.

Esto requiere coincidencia exacta de resolución. Un título parecido no basta.

Ejemplo paso a paso de prediction market arbitrage

1. Valida el contrato: compara condición, orden de outcomes, cutoff y resolver entre Kuest y Polymarket.
2. Lee libros ejecutables: usa bid, ask y tamaño. La API de order book de Polymarket incluye niveles, timestamp, mínimo y tick size.
3. Elige la ruta de hedge: cubre solo la cantidad disponible, cruza el siguiente nivel, usa una ruta complementaria o reduce tus quotes.
4. Calcula el resultado:

resultado neto = ingreso Kuest - coste del hedge - fees - gas - slippage
                 - coste de capital e inventario

5. Reconcilia cada estado: accepted, partial fill, cancel, reject y resting deben quedar registrados.
6. Supervisa hasta settlement: resolución, disputas, redemption y cambios de relación siguen siendo relevantes.

Cómo encontrar mirrors y mapear outcome tokens

El shortcut más peligroso es hacer matching solo por título. Assymetrix explica cómo diferentes traders, fees, liquidez y reglas de resolución convierten titulares similares en instrumentos distintos.

Guarda al menos este mapping por mirror:

{
  "source": "polymarket",
  "sourceConditionId": "0x...",
  "sourceYesTokenId": "...",
  "sourceNoTokenId": "...",
  "kuestConditionId": "0x...",
  "kuestYesTokenId": "...",
  "kuestNoTokenId": "...",
  "resolutionSource": "...",
  "closeTime": "...",
  "mappingStatus": "verified"
}

Los detalles de mercado de Kuest incluyen mirror condition IDs, mirror token IDs, outcomes, fees, fuente de resolución y bid/ask. Rechaza operaciones cuando falte un ID, cambie el close time, la fuente sea distinta, el mercado esté pausado o no exista tamaño para un hedge completo.

Cómo cambia el arbitraje con shared liquidity

Los mercados compatibles usan libros Kuest comunes. Una orden de una página puede casar con flujo de otra, lo que mejora eficiencia de capital y reduce el cold start.

Pero dos páginas que muestran el mismo libro no son dos legs independientes. El edge puede surgir de la relación con Polymarket, del flujo de un operador, de fees o incentivos, de un desequilibrio de inventario o de una campaña financiada.

Consulta el protocolo Kuest y la página de market makers para entender la red y sus mandatos de liquidez.

Inventario del market maker: collateral, YES/NO y settlement

Un market maker binario gestiona USDC collateral, inventario YES, inventario NO y posiciones en venues externos. El hedge correcto depende del balance completo.

Un par YES/NO de la misma condición vale 1 $ en conjunto al resolver. Según la mecánica del venue, puede mintearse desde collateral o mergearse de vuelta. Mantén separadas las acciones físicas y contables: SELL YES debe seguir siendo SELL YES en el log aunque el settlement use un merge.

¿Cuánto edge queda después de fees, gas y slippage?

El midpoint no es un precio ejecutable. Modela precio y tamaño reales. Usa la API de spreads y la información CLOB como inputs.

edge neto = payoff o spread bruto
          - fees de todos los legs - gas - slippage
          - failed fills - capital bloqueado - coste del hedge
          - overhead operativo

La recompensa de una campaña Kuest debe ser una línea separada de revenue. Paga un servicio de liquidez definido y no debe ocultar adverse selection, pérdidas de inventario o coste del bond.

Principales riesgos del arbitraje en mirrors de Polymarket

Basis risk

Una sola cláusula puede cambiar el payoff. Compara fuente de datos, timestamp, cutoff, resolver y casos extremos.

Ejecución, latencia y liquidez

El leg barato puede desaparecer antes de que llegue el hedge. El mejor ask puede tener tamaño insuficiente.

Adverse selection

El trader que toma tu quote puede estar reaccionando a información nueva antes que tu bot.

Resolution, venue y operación

Outages, rate limits, órdenes rechazadas, wallets, websockets stale, disputas y liquidación tardía deben estar cubiertos por reconciliación y kill switches.

Riesgo regulatorio

Prediction markets, derivados y market making se regulan de forma distinta según jurisdicción. Obtén asesoramiento legal, fiscal y de compliance propio.

Cómo las campañas Kuest pagan por la liquidez

Una campaña puede definir mercado o serie, fechas, profundidad por lado, spread máximo, coverage, reward, bond y disponibilidad de hedge externo.

El flujo de escrow es:

1. El sponsor deposita reward y importes de protocolo.
2. Un market maker aprobado revisa y acepta los términos.
3. Deposita bond si corresponde.
4. Mantiene la liquidez durante el servicio.
5. Pasa por review y posible disputa.
6. Tras finalizar, la asignación queda disponible mediante pendingWithdrawals.

Escrow protege el mandato comercial, no garantiza fills del hedge ni ganancias. Revisa la API de creación de mercados y la API de resolución.

Bots de prediction market arbitrage e infraestructura API

Un bot serio es una state machine:

discover -> validar mapping -> leer depth -> calcular edge neto
         -> reservar collateral -> colocar primer leg
         -> confirmar fill -> colocar hedge -> reconciliar
         -> monitorizar settlement -> rebalancear inventario

Necesitas discovery, token mapping, order books, sizing, fills, inventory, routing, settlement monitoring, alertas, logs y kill switches. La guía de market data de Polymarket y su API de órdenes detallan los primitives.

Un bot Polymarket existente puede reutilizar wallet, CLOB, cancel-and-replace y controles de riesgo, pero debes validar IDs Kuest, shared books, auth, fees, semántica de órdenes, lifecycle y obligaciones de campaña.

Cómo empezar a hacer market making en Kuest

1. Abre la página de market makers de Kuest y el modelo de protocolo.
2. Solicita aprobación para la wallet operativa.
3. Filtra campañas por hedge Polymarket, spread, depth y duración.
4. Valida de forma independiente el mapping y el libro externo.
5. Acepta solo términos compatibles y deposita bond si se exige.
6. Empieza con tamaño conservador y comprueba order, fill y reconciliation.
7. Finaliza y retira la asignación después del servicio y review.

Por qué los market makers cripto-native son valiosos para Kuest

Kuest necesita desks que sepan cotizar un CLOB binario, gestionar inventario YES/NO, reconocer basis risk, manejar partial fills, operar Polygon/USDC y mantener kill switches, alertas y audit logs.

Ese conocimiento permite a los operadores lanzar mercados con profundidad creíble y da al maker acceso a nuevo flujo de comunidades y campañas financiadas en una red compartida.

Para seguir leyendo

• Arquitectura Kuest: operadores, shared liquidity y settlement
• Order book de Polymarket
• Enviar órdenes en Polymarket
• Investigación de Assymetrix sobre arbitraje cross-venue
• Guía de arbitraje en prediction markets
• Preduck: hedging y matching cross-venue

FAQ: Prediction Market Arbitrage

¿El arbitraje de Polymarket es sin riesgo?

No. El spread puede desaparecer y dos mercados parecidos pueden resolver de forma distinta. Incluso un par YES/NO exige reglas idénticas y fills completos.

¿Qué es un mirror de Polymarket?

Un mercado Kuest relacionado con un mercado fuente de Polymarket para que un operador pueda ofrecer el evento con su propia marca. Hay que verificar mapping, resolución y liquidez.

¿Cómo funciona una Polymarket hedge strategy?

El maker usa Polymarket para reducir la exposición creada al cotizar en otro venue: compra el mismo outcome, el complementario o un par completo. La ruta depende de contrato, depth, fees y partial fills.

¿Qué IDs debe mapear un bot?

Condition IDs de fuente y Kuest, token IDs YES/NO, fuente de resolución, close time y estado del mapping. Si hay ambigüedad, no debe operar.

¿Qué es MarketMakerEscrow?

Un smart contract en Polygon que coordina reward, bond, servicio, review y retiro de campañas de liquidez. No garantiza beneficios.

¿Kuest garantiza retornos de arbitraje?

No. Kuest ofrece infraestructura, red, datos y escrow. Pricing, ejecución, inventario, hedge y capital siguen siendo responsabilidad del market maker.