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 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 rankings equivocados. ¿Escribir tu propio script para calcular? La mayoría de las veces también estará mal.

¿Hasta qué punto son erróneos los datos? El tercer lugar en el ranking, 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. Para quienes hacen trading, desarrollan herramientas o revisan rankings, tarde o temprano se encontrarán con ellas.

Trampa 1: cashPnl no incluye las ganancias ya liquidadas

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

Prueba con las tres direcciones en el top 15 del ranking:

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

kch123: suma de cashPnl -$3.52 millones, ranking real +$11.4 millones, signo invertido

gmanas: suma de cashPnl -$2.64 millones, ranking real +$5.02 millones, signo invertido

Para esas tres direcciones, ¡el signo de ganancia y pérdida se invirtió en dos casos!

Razón: la API /positions no incluye el PnL realizado que ya ha sido cerrado o redimido. 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 sin liquidar, 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 sin liquidar.

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 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 diferencia 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 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 tiene múltiples eventos de transferencia de USDC, 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

Para la interfaz /activity, usar offset para paginar? Si pasa de 3000, da error 400. La documentación no lo especifica.

Los tres direcciones anteriores lo verificaron: 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 el criterio del PnL en el ranking

Después de calcular el PnL de una dirección, 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 PnL calculado con flujo de efectivo coincide mucho 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 de flujo de efectivo desde la API de datos. Sin usar campos precomputados, solo sumando las transacciones originales.

Fórmula:

PnL = SUMA (TRADE donde side=SELL) + SUMA (REDEEM) + SUMA (MERGE) + SUMA (REMAKE_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 en USDC (entrada)

· MAKER_REBATE: reembolso del creador de mercado (entrada)

· REWARD: recompensas/airdrop (entrada)

· Fuente de datos:

GET /activity?user=