Polygon y Polymarket: Lectura de datos de mercados de predicción onchain

Alcance y qué cubre esta guía

Este artículo trata sobre la relación técnica entre Polygon y Polymarket: cómo se representan onchain las posiciones de un mercado de predicción, cómo consultarlas mediante métodos JSON-RPC estándar y cómo medir si tu capa de acceso a Polygon es suficientemente buena para la carga de trabajo. Está escrito para desarrolladores que construyen paneles, pipelines de analítica o herramientas de trading que necesitan leer la actividad de Polymarket en lugar de realizar operaciones a través de la interfaz de Polymarket.

Se aplican dos supuestos en todo el documento. Primero, tienes un endpoint JSON-RPC de Polygon que controlas o en el que confías, proporcionado como RPC_URL; esta guía nunca codifica un endpoint público. Segundo, entiendes conceptos básicos de JSON-RPC de Ethereum como bloques, logs y eth_call. Si necesitas un repaso sobre la selección de endpoints, la guía de endpoints RPC cubre los fundamentos, y la guía de endpoints RPC multicadena explica cómo estructurar el acceso entre redes.

• Comportamiento documentado: Polymarket ha operado en Polygon PoS, con autocustodia mediante Safe y resolución a través del oráculo optimista de UMA.
• Recomendación: trata cualquier cifra de un panel como una hipótesis hasta que la reproduzcas a partir de logs sin procesar.
• Medición: la latencia, la completitud de logs y el comportamiento ante reorganizaciones deben probarse contra tu propio endpoint.

Cómo se mapea Polymarket en Polygon

Un mercado de predicción necesita tres cosas de su capa de liquidación: una forma de mantener colateral, una forma de representar participaciones de resultados y una forma de resolver mercados. En Polygon, el colateral suele ser una stablecoin como USDC, las participaciones de resultados son tokens similares a ERC-20 o posiciones registradas en un contrato de mercado, y la resolución la impulsa un oráculo que publica una respuesta que el contrato de mercado acepta tras una ventana de disputa.

Polygon ha descrito la arquitectura pública de Polymarket como una combinación de verificabilidad onchain, autocustodia mediante cuentas inteligentes Safe y resolución de disputas descentralizada a través del Optimistic Oracle de UMA. Esto significa que la superficie onchain útil para un integrador no es un solo contrato, sino un conjunto: fábricas de mercados, contratos de mercados individuales, contratos de tokens condicionales y cuentas Safe que mantienen los fondos de los usuarios. La página de la red Polygon es el lugar para confirmar los identificadores de cadena y los parámetros actuales de la red antes de escribir cualquier código.

• Colateral: saldos de stablecoin mantenidos por contratos de mercado o Safe.
• Posiciones: participaciones de resultados tokenizadas cuyos saldos cambian con las operaciones.
• Resolución: resultados reportados por el oráculo y aceptados por los contratos de mercado tras un período de disputa.
• Cuentas: cuentas inteligentes basadas en Safe en lugar de cuentas de propiedad externa simples para muchos usuarios.

Un modelo mental para leer el estado de un mercado de predicción

Trata cada mercado de Polymarket como una pequeña máquina de estados. Comienza en un estado de trading, pasa a un estado de resolución propuesta cuando se envía una respuesta del oráculo y finalmente se liquida. Cada transición emite eventos, y esos eventos son la fuente de datos fiable más barata porque están indexados y se pueden filtrar por dirección y tema.

La consecuencia práctica es que debes construir tu pipeline en torno a los logs, no en torno al sondeo repetido con eth_call de cada mercado. Los logs te permiten reconstruir operaciones, divisiones, fusiones y redenciones en orden. Las llamadas son mejores para lecturas puntuales como un saldo actual o el estado de resolución de un mercado. Mezclar ambos sin un límite claro es la causa más común de doble conteo en paneles de mercados de predicción.

Requisitos previos y configuración del entorno

Necesitas Node.js 18 o posterior para los ejemplos en JavaScript, y curl más un shell para las comprobaciones RPC sin procesar. Exporta tu endpoint y un rango de bloques que quieras inspeccionar. No confirmes claves reales; los ejemplos solo usan marcadores de posición.

Configura RPC_URL con un endpoint de Polygon de tu proveedor. Si aún estás decidiendo entre acceso compartido y dedicado, la página de nodo dedicado explica cuándo merece la pena el coste de un nodo privado, y precios de RPC muestra cómo se asigna el volumen de solicitudes a los planes.

export RPC_URL="https://your-polygon-endpoint.example"
export FROM_BLOCK=60000000
export TO_BLOCK=60001000
node --version

Verificación de la identidad de la cadena y el rango de bloques con curl

Antes de consultar cualquier contrato, confirma que estás en la cadena que crees. eth_chainId devuelve el identificador de cadena, y eth_blockNumber te dice hasta dónde se ha sincronizado el endpoint. Una discrepancia aquí invalida todos los resultados posteriores.

Ejecuta lo siguiente y registra las salidas. El resultado de verificación esperado es un ID de cadena que coincida con el valor documentado de Polygon y un número de bloque que avance entre dos llamadas separadas por unos segundos. Si el número de bloque es estático, tu endpoint está desactualizado o en caché.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'

sleep 5

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"eth_blockNumber","params":[]}'

Obtención de logs relacionados con Polymarket en JavaScript

El siguiente paso es extraer logs de una dirección de contrato conocida en un rango de bloques acotado. Debes proporcionar la dirección tú mismo desde una fuente de confianza, como el contrato listado en la página del mercado o una etiqueta verificada de un explorador de bloques. El script siguiente obtiene logs, imprime el recuento y sale con un código distinto de cero si el endpoint devuelve un error, lo que lo hace utilizable en una comprobación de CI.

Mantén los rangos pequeños al principio. Muchos proveedores limitan los resultados de eth_getLogs, y un truncamiento silencioso parece idéntico a un mercado tranquilo. Compara el recuento devuelto con un segundo proveedor o un explorador de bloques antes de confiar en él.

const RPC_URL = process.env.RPC_URL;
const ADDRESS = process.env.MARKET_ADDRESS;
const FROM = process.env.FROM_BLOCK;
const TO = process.env.TO_BLOCK;

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(JSON.stringify(json.error));
  return json.result;
}

const logs = await rpc('eth_getLogs', [{
  address: ADDRESS,
  fromBlock: '0x' + Number(FROM).toString(16),
  toBlock: '0x' + Number(TO).toString(16)
}]);

console.log('log count:', logs.length);
console.log('first block:', logs[0]?.blockNumber ?? 'none');

Lectura del estado de resolución de un mercado con eth_call

Las lecturas puntuales usan eth_call contra un bloque específico. Necesitas el fragmento del ABI del contrato para la función que estás llamando. El ejemplo siguiente asume una función que devuelve un indicador booleano de resolución; sustituye el selector y el ABI reales del contrato que estás inspeccionando. Codificar la llamada a mano es propenso a errores, así que usa una biblioteca como viem o ethers en producción.

El resultado de verificación esperado es un valor decodificado que coincida con lo que muestra la página del mercado en el mismo bloque. Si no coincide, fija explícitamente el número de bloque y vuelve a intentarlo; el estado puede cambiar entre tu lectura y la lectura de la interfaz.

import { createPublicClient, http, parseAbi } from 'viem';

const client = createPublicClient({
  transport: http(process.env.RPC_URL)
});

const abi = parseAbi([
  'function resolved() view returns (bool)'
]);

const blockNumber = await client.getBlockNumber();
const resolved = await client.readContract({
  address: process.env.MARKET_ADDRESS,
  abi,
  functionName: 'resolved',
  blockNumber
});

console.log({ blockNumber, resolved });

Medición del comportamiento del endpoint para esta carga de trabajo

La analítica de mercados de predicción tiene mucha carga de logs y es a ráfagas. Durante un evento importante, muchos clientes solicitan el mismo rango de bloques reciente a la vez. Debes medir tres cosas en tu propio endpoint: la latencia de consulta de logs para un rango fijo, la tasa de éxito bajo consultas idénticas repetidas y si los resultados son consistentes entre dos endpoints.

Ejecuta cada medición al menos 30 veces y registra los resultados en una tabla como la siguiente. No rellenes números de este artículo; las celdas están intencionalmente en blanco porque solo tu entorno puede producirlos. Una comparación útil es un endpoint compartido frente a un nodo dedicado, que la guía de alojamiento de nodos blockchain describe en términos operativos.

• | Métrica | Endpoint A | Endpoint B | Notas |
• | --- | --- | --- | --- |
• | Latencia mediana de eth_getLogs, 1.000 bloques | | | Misma dirección y rango |
• | Latencia p95 | | | Atención a los límites del proveedor |
• | Tasa de éxito en 30 ejecuciones | | | Contar errores JSON-RPC |
• | Concordancia del recuento de logs | | | Debe coincidir exactamente |
• | Deriva de eth_blockNumber en 60 s | | | Debe ser distinta de cero |

Solución de problemas comunes de integración

La mayoría de los fallos se engloban en unas pocas categorías. Los errores de rango demasiado grande significan que el proveedor limita eth_getLogs; divide el rango y pagina. Los resultados vacíos en un mercado activo suelen indicar una dirección incorrecta, un filtro de temas incorrecto o un rango anterior a la existencia del mercado. Los recuentos inconsistentes entre proveedores suelen indicar que un endpoint está retrasado o aplica un límite de resultados sin avisarte.

Si eth_call se revierte, comprueba que estás leyendo en un bloque donde el contrato existe y que tu ABI coincide con el bytecode desplegado. Si una posición mantenida en Safe parece faltar, recuerda que el propietario es el Safe, no la clave de firma del usuario; consulta la dirección del Safe, no la EOA. Para patrones más amplios de fiabilidad de endpoints, la categoría de fiabilidad y consistencia es la referencia adecuada.

• Errores de rango: pagina en ventanas de tamaño fijo y registra el recuento de cada ventana.
• Logs vacíos: verifica la suma de comprobación de la dirección, topic0 y el bloque de despliegue.
• Reversiones: fija el número de bloque y confirma el ABI contra el código fuente verificado.
• Saldos faltantes: consulta el contrato Safe, no el firmante.

Limitaciones, compensaciones y qué no asumir

Los datos onchain te dicen lo que se liquidó, no lo que se pretendía. La casación de órdenes offchain, la visualización en la interfaz y algunos metadatos pueden no aparecer nunca en los logs, por lo que una reconstrucción puramente onchain puede infravalorar la actividad. La resolución por oráculo introduce una ventana de disputa durante la cual el resultado aparente de un mercado puede cambiar; trata los resultados propuestos como provisionales hasta que se cierre la ventana.

También hay una dimensión de gobernanza e infraestructura. El debate público ha planteado la posibilidad de que Polymarket opere su propia cadena o cambie la infraestructura de liquidación con el tiempo. Por lo tanto, cualquier integración debe leer las direcciones de los contratos y los ID de cadena desde la configuración en lugar de codificar suposiciones sobre dónde se ejecuta Polymarket. Este artículo describe el modelo basado en Polygon porque es el documentado y observable, no porque esté garantizado que persista sin cambios.

Próximos pasos para un pipeline de producción

Pasa de consultas ad hoc a un pipeline indexado: un trabajo de relleno que recorra los logs históricos en ventanas acotadas, una cola en vivo que siga los nuevos bloques y un trabajo de reconciliación que compare tus totales derivados con una segunda fuente. Almacena los logs sin procesar antes de decodificarlos para poder volver a derivar métricas cuando cambie un ABI o una interpretación.

Para la elección de endpoint, mantén la decisión separada del diseño del pipeline. La descripción general del servicio API explica cómo se estructura el acceso gestionado, y si quieres una recomendación directa en lugar de una metodología, las breves guías de RPC Assistant como mejor API RPC de Ethereum son el lugar adecuado para consultar. Por último, documenta tus propias cifras medidas de latencia y consistencia junto al pipeline para que los cambios futuros se puedan evaluar contra una línea base en lugar de contra un recuerdo.