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 propio 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 es que sea torpe. 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 para calcular? La mayoría de las veces también estará mal.

¿La desviación es tan disparatada? 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 que haya una diferencia de unos pocos puntos porcentuales: ¡los signos de ganancia y pérdida están invertidos!

Este artículo desglosa cada trampa en la que he caído. Para quienes hacen trading, desarrollan herramientas o consultan clasificaciones, tarde o temprano se encontrarán con ellas.

Trampa 1: cashPnl no incluye las ganancias ya liquidadas

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

Prueba con las tres direcciones en los primeros 15 lugares del ranking:

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, ¡los signos de ganancia y pérdida están invertidos en dos casos!

Razón: la API de /positions devuelve un cashPnl que no incluye las ganancias realizadas que ya se han cerrado o redimido. Cuando una posición ganadora se redime automáticamente en USDC, esa posición desaparece de la respuesta de la API. Lo que queda son las posiciones sin liquidar, que suelen estar en pérdida flotante.

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

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

En los datos JSONL de las operaciones, hay un campo makerPnl (ganancia/pérdida del creador de mercado), que parece estar 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 cálculo basado en el flujo de efectivo en la cadena. La diferencia 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.

No importa 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 lo más contraintuitivo.

Si un 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 maker en una sola transacción en la 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é 133 dólares. En la cadena Polygon, verifiqué que un solo hash de transacción puede tener múltiples eventos de transferencia USDC independientes, cada uno correspondiente a una transacción real.

Conclusión: no se puede 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 de error “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 el ranking

Tras calcular el PnL de una dirección, al compararlo con el ranking, 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 del ranking, 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 los resultados del API 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, simplemente calcula las entradas y salidas de fondos desde los registros originales de transacciones.

Fórmula:

PnL = SUM(TRADE donde side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE donde side=BUY) - SUM(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 en 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 o airdrops (entrada)

· Fuente de datos:

GET /activity?user=