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 soy malo. Es que el cálculo de PnL en PM en sí mismo es una zona peligrosa. 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 es alta de que también esté mal.

¿Lo 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 ganó 11.4 millones de dólares. No es una diferencia de unos pocos puntos porcentuales: ¡el signo de ganancias y pérdidas está invertido!

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 ello.

Trampa 1: cashPnl no incluye las ganancias ya liquidadas

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

Prueba real con las tres direcciones principales en 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

Las tres direcciones, dos de ellas con signos de ganancias y pérdidas invertidos.

Razón: la API /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 no liquidadas, que suelen mostrar pérdidas flotantes.

Crees que estás calculando todas las ganancias y pérdidas, pero en realidad solo estás viendo 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 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 desviación, la conclusión es la misma: no uses este 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, eliminar duplicados.

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.

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

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

Verifiqué con las tres direcciones: GET /activity?offset=3100 devuelve HTTP 400, con el mensaje de error “max historical activity offset of 3000 exceeded”. Los usuarios principales tienen 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, al 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 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 casi exactamente 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 rutas 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, calculando directamente las entradas y salidas de fondos en los registros 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 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/airdrop (entrada)

· Fuente de datos:

GET /activity?user=