Cálculo preciso de PnL en Polymarket: ¿Por qué tus ganancias y pérdidas podrían estar equivocadas?

Título original: «Cálculo preciso de PnL en Polymarket: por qué tus ganancias y pérdidas pueden estar completamente equivocadas» Autor original: Leo, analista de criptomonedas

Autor original:律动BlockBeats

Fuente original:

Reproducción: Mars Finance

He estado haciendo trading automatizado propio en Polymarket durante medio año, y la mayor trampa que he pisado no fue un fallo en la estrategia, sino que ni siquiera podía calcular correctamente cuánto había ganado.

No soy malo en esto. Es que el cálculo de PnL de PM en sí mismo es una zona de minas. La API oficial te da números incorrectos, y los sitios de análisis de terceros también muestran clasificaciones equivocadas. ¿Escribir tu propio script? Probablemente también esté equivocado.

¿Hasta qué punto son las desviaciones? El tercer lugar en la clasificación, kch123, calculó una pérdida de 3.5 millones de dólares con un método incorrecto, cuando en realidad ganó 11.4 millones de dólares. No es una diferencia de unos pocos puntos porcentuales: ¡el signo de ganancia y pérdida está invertido!

Este artículo desglosa cada trampa en la que he caído. Ya seas trader, desarrollador de herramientas o simplemente consultes las clasificaciones, tarde o temprano te encontrarás con esto.

Trampa 1: cashPnl no incluye las ganancias ya liquidadas

El método más intuitivo: usar la interfaz /positions, sumar el campo cashPnl (ganancia/pérdida en efectivo).

Tomando los tres primeros en la clasificación y verificando:

swisstony: suma de cashPnl +$35,000, clasificación real +$5,6 millones, diferencia de 158 veces

kch123: suma de cashPnl -$3.52 millones, clasificación real +$11.4 millones, signo invertido

gmanas: suma de cashPnl -$2.64 millones, clasificación real +$5.02 millones, signo invertido

En los tres casos, ¡el signo de ganancia y pérdida está invertido!

Razón: la API /positions devuelve un cashPnl que no incluye las ganancias o pérdidas realizadas que ya han sido cerradas o redimidas. Cuando una posición ganadora se redime automáticamente a USDC, esa posición desaparece de la respuesta de la API. Lo que queda son las posiciones no liquidadas, que suelen mostrar pérdidas flotantes.

Crees que estás calculando toda la ganancia o pérdida, pero en realidad solo estás considerando la parte no liquidada.

Trampa 2: el campo makerPnl no coincide con el flujo de efectivo en la cadena

En los datos de trading en formato JSONL hay un campo makerPnl (ganancia/pérdida del creador de mercado), que parece estar diseñado para calcular PnL. Pero no confíes.

Observando los datos de creación de mercado, el resultado de sumar makerPnl (SUM(makerPnl)) difiere en un orden de magnitud con el cálculo basado en el flujo de efectivo en la cadena. La magnitud exacta puede variar según el escenario, pero la dirección es la misma: la lógica interna de makerPnl no coincide con el flujo real de USDC.

Independientemente de cuán grande sea la desviación, la conclusión es la misma: no uses ese campo para calcular PnL.

Trampa 3: no se puede deduplicar solo por txHash

Esto es contraintuitivo.

Si una misma txHash (hash de transacción) aparece varias veces, la reacción natural sería: datos duplicados, eliminar duplicados.

Pero no se puede hacer así. El libro de órdenes en cadena (CLOB) de PM puede hacer coincidir múltiples órdenes maker en una sola transacción en cadena, y varias entradas con el mismo txHash son en realidad ejecuciones independientes.

Antes, deduplicaba por txHash + asset, y en el lado de compra (BUY) subestimé en 133 dólares. En Polygon, verifiqué que un solo txHash puede tener múltiples eventos de transferencia USDC, cada uno correspondiente a una transacción real.

Conclusión: no deduplicar solo por txHash. Para calcular PnL, suma directamente los datos originales de /activity.

Trampa 4: el límite en la paginación con offset

Para la interfaz /activity, ¿usar offset (desplazamiento)? Cuando pasa de 3000, da error 400. La documentación no lo especifica.

Verifiqué con los tres casos anteriores: GET /activity?offset=3100 devuelve HTTP 400, con el mensaje de error “max historical activity offset of 3000 exceeded”. Los principales usuarios tienen decenas de miles de transacciones, 3000 no es suficiente.

Usar el parámetro end (el timestamp de la última entrada de la página anterior - 1) como cursor de paginación no tiene límite.

Trampa 5: diferencias en la definición de PnL en la clasificación

Tras calcular el PnL de una dirección y compararlo con la clasificación, hay una pequeña diferencia.

En la mayoría de los casos, la diferencia es menor a 10 dólares (debido a la volatilidad en tiempo real del valor de mercado de las posiciones). Pero si la diferencia es mucho mayor, las causas posibles incluyen: la ventana de agregación de la clasificación, retrasos en la actualización del caché, o que el usuario tenga varias wallets proxy vinculadas.

En pruebas, el método de flujo de efectivo coincide mucho con la API lb-api. Si tu resultado difiere mucho, primero verifica si la paginación fue completa (trampa 4) y si usaste los campos correctos (trampas 1-2).

Método correcto

Tras probar varias alternativas, el método más confiable que validé es sumar los datos de la API de flujo de efectivo. Sin usar campos precomputados, simplemente sumando las transacciones originales.

Fórmula:

PnL = SUMA(TRADE donde side=SELL) + SUMA(REDEEM) + SUMA(MERGE) + SUMA(MAKER_REBATE) + SUMA(REWARD) - SUMA(TRADE donde side=BUY) - SUMA(SPLIT) + valor de mercado de la posición

· TRADE BUY: gastar USDC para comprar tokens (salida)

· TRADE SELL: vender tokens para recuperar USDC (entrada)

· REDEEM: redimir posiciones ganadoras por USDC (entrada)

· SPLIT: acuñar USDC en tokens (salida)

· MERGE: combinar tokens en USDC (entrada)

· MAKER_REBATE: reembolso del creador de mercado (entrada)

· REWARD: recompensas/airdrop (entrada)

· Fuente de datos:

GET /activity?user=&limit=500, paginar con end, y sumar por tipo tras obtener todos los datos.

· Valor de mercado de la posición:

GET /positions?user=, tamaño × precio actual.

· Validación cruzada:

Comparar los resultados con la API de clasificación de Polymarket (lb-api.polymarket.com/profit?window=all&address=X), y si la diferencia es menor a 10 dólares, se considera correcto. La diferencia se debe a la volatilidad en tiempo real del valor de mercado.

Verificación: clasificación de los 15 principales en la práctica

Tras calcular con flujo de efectivo, cruzar con la API de clasificación:

swisstony: +$5,601,000 en flujo de efectivo, clasificación +$5,601,000, diferencia < $10

kch123: +$11,396,000 en flujo de efectivo, clasificación +$11,396,000, diferencia < $10

gmanas: +$5,024,000 en flujo de efectivo, clasificación +$5,024,000, diferencia < $10

Las diferencias en los tres casos son menores a 10 dólares, y se deben a la volatilidad en tiempo real del valor de mercado.

Una vez que el método funciona, lo apliqué para analizar las ganancias y pérdidas reales de cientos de direcciones principales. Eso fue otra historia.

Resumen

SUM(cashPnl) desde /positions → no funciona, no incluye ganancias ya liquidadas, y el signo puede invertirse

Sumar el campo makerPnl → no funciona, no coincide con el flujo en cadena

Deduplicar por txHash y luego calcular → no funciona, más de 100 dólares, elimina ejecuciones reales

Paginación con offset + suma → no funciona, datos truncados, error >3000

API de flujo de efectivo → actualmente el método más confiable, diferencia menor a 10 dólares

El primer paso para hacer trading cuantitativo no es buscar alpha. Es asegurarte de que tus cálculos sean correctos.

Todo lo anterior proviene de experiencias reales, no de deducciones teóricas. La API de PM puede cambiar en cualquier momento, por lo que se recomienda verificar periódicamente con la API de clasificación para validar tus cálculos.