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

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

No soy malo. Es que el cálculo de PnL en 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 para calcular? La probabilidad de error sigue siendo alta.

¿Lo desproporcionado? 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 obtuvo una ganancia de 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 ellas.

Trampa 1: cashPnl no incluye las ganancias ya liquidadas

La forma más intuitiva: usar la interfaz /positions y sumar el campo cashPnl (ganancias y pérdidas en efectivo).

Prueba con las tres direcciones en los top 15 de la clasificación:

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 esas tres direcciones, en dos casos el signo de ganancia y pérdida está invertido.

Razón: la API /positions devuelve cashPnl sin incluir 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 tienes 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.

He observado en los datos de mercado que la suma de makerPnl difiere en un orden de magnitud con el resultado del 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 cálculo de makerPnl no coincide con el flujo real de USDC.

No importa cuán grande sea la discrepancia, la conclusión es la misma: no uses ese campo para calcular PnL.

Trampa 3: no se puede deduplicar solo por txHash

Esto es lo más contraintuitivo.

Si un mismo txHash (hash de transacción) aparece varias veces, la reacción natural sería: datos duplicados, eliminarlos.

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

Antes, deduplicaba por txHash + asset, y en el lado de compra (BUY) subestimé 133 dólares. En la cadena Polygon, verifiqué que un solo hash de transacción tiene múltiples eventos de transferencia de 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

¿Usar offset para paginar en /activity? Si pasa de 3000, da error 400. La documentación no lo especifica.

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

Usar el parámetro end (el timestamp de la última transacción 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

Después de calcular el PnL de una dirección, 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 las posiciones). Pero si la diferencia es mucho mayor, las causas posibles incluyen: la ventana de agregación en la clasificación, retrasos en la actualización del caché, o que el usuario tenga varias wallets proxy vinculadas.

En pruebas, el PnL calculado con el método de flujo de efectivo coincide casi exactamente con el valor devuelto por lb-api. Si la diferencia es grande, 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 he validado es sumar los datos del API de flujo de efectivo. Sin usar campos precomputados, solo sumando las transacciones originales.

Fórmula:

PnL = SUMA (TRADE donde side=SELL) + SUMA (REDEEM) + SUMA (MERGE) + SUMA (REWARD_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 posición ganadora por USDC (entrada)

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

· MERGE: combinar tokens de vuelta en USDC (entrada)

· REWARD_REBATE: reembolso del creador de mercado (entrada)

· REWARD: recompensas/airdrop (entrada)

· Fuente de datos:

GET /activity?user=