Titre original : « Calcul précis du PnL de Polymarket : pourquoi vos calculs de gains et pertes peuvent être totalement erronés »
Auteur original : Leo, analyste en cryptomonnaie

Je travaille sur l’automatisation des transactions sur Polymarket depuis six mois, et la plus grande erreur que j’ai rencontrée n’est pas une défaillance de stratégie, mais le fait de ne pas pouvoir calculer correctement combien j’ai réellement gagné ou perdu.

Ce n’est pas une question de compétence. C’est que le calcul du PnL (profit et perte) de PM est une zone minée en soi. Les chiffres fournis par l’API officielle sont incorrects, et le classement affiché par les sites d’analyse tiers est aussi erroné. Vous écrivez votre propre script pour le calcul ? La probabilité qu’il soit aussi faux est élevée.

À quel point l’écart est-il énorme ? Le troisième dans le classement, kch123, a calculé une perte de 3,5 millions de dollars avec une méthode erronée, alors que le bénéfice réel est de 11,4 millions de dollars. Ce n’est pas une différence de quelques points de pourcentage — c’est que le symbole de gain ou de perte est inversé.

Cet article décompose chaque piège que j’ai rencontré. Que vous fassiez du trading, développiez des outils ou consultiez le classement, vous finirez par tomber dessus.

Piège 1 : cashPnl ne comprend pas les gains réalisés déjà réglés

La méthode la plus intuitive : utiliser l’interface /positions, faire la somme du champ cashPnl (profit et perte en espèces).

Test pratique sur trois adresses parmi les 15 premières du classement :

swisstony : somme de cashPnl +$35 000, classement réel +$5,6 millions, différence de 158 fois

kch123 : somme de cashPnl -$3,52 millions, classement réel +$11,4 millions, inversion du signe

gmanas : somme de cashPnl -$2,64 millions, classement réel +$5,02 millions, inversion du signe

Pour ces trois adresses, deux signent de gains ou pertes sont directement inversés.

Raison : le cashPnl renvoyé par l’API /positions n’inclut pas les gains ou pertes réalisés qui ont été clôturés ou rachetés. Après avoir automatiquement racheté la position en USDC, cette position disparaît de la réponse API. Ce qui reste, ce sont les positions non encore réglées — souvent en perte latente.

Vous pensez calculer tous les gains et pertes, mais en réalité, vous ne récupérez que la partie non encore réglée.

Piège 2 : le champ makerPnl ne correspond pas aux flux de trésorerie on-chain

Dans le JSONL des données de trading, il y a un champ makerPnl (profit et perte du market maker), qui semble destiné à calculer le PnL. Ne le croyez pas.

J’ai observé dans les données de market-making que la somme de makerPnl diffère d’un ordre de grandeur du résultat du flux de trésorerie on-chain. La différence précise peut varier selon le contexte, mais la direction est claire : la logique interne de makerPnl ne correspond pas au flux réel d’USDC.

Peu importe l’ampleur de l’écart, la conclusion est la même : n’utilisez pas ce champ pour calculer le PnL.

Piège 3 : ne pas dédupliquer par txHash seul

C’est contre-intuitif.

Un même txHash (hash de transaction) apparaît plusieurs fois. La réaction naturelle : données en double, déduplication.

Mais il ne faut pas faire ça. Le CLOB (order book on-chain) de PM peut faire matcher plusieurs ordres maker dans une seule transaction on-chain, et plusieurs enregistrements sous le même txHash sont de véritables fills indépendants.

J’avais auparavant dédupliqué par txHash + asset, ce qui sous-estimait de 133 dollars la partie BUY. Sur Polygon, j’ai vérifié qu’un seul txHash peut effectivement contenir plusieurs événements de transfert USDC, chacun correspondant à une transaction réelle.

Conclusion : ne pas dédupliquer uniquement par txHash. Pour calculer le PnL, il faut faire la somme directement sur les données brutes /activity.

Piège 4 : la pagination avec offset a une limite

Pour l’API /activity, utiliser offset (décalage) ? Au-delà de 3000, ça renvoie une erreur 400. Ce n’est pas indiqué dans la documentation.

Les trois adresses ci-dessus ont toutes été vérifiées : GET /activity?offset=3100 renvoie HTTP 400, avec le message d’erreur « max historical activity offset of 3000 exceeded ». Les gros traders ont souvent des dizaines de milliers de transactions, 3000 ne suffit pas.

Utiliser le paramètre end (en passant le timestamp de la dernière transaction de la page précédente - 1) pour faire la pagination n’a pas de limite.

Piège 5 : différences dans la méthodologie du classement PnL

Après avoir calculé le PnL d’une adresse, comparer avec le classement montre une petite différence.

Dans la majorité des cas, la différence est inférieure à 10 dollars (due à la volatilité en temps réel de la valeur des positions). Mais si la différence est significative, cela peut venir de : la fenêtre d’agrégation du classement, du délai de mise à jour du cache, ou du fait que l’utilisateur a lié plusieurs portefeuilles proxy.

En pratique, le PnL calculé par la méthode du flux de trésorerie est très proche de celui renvoyé par l’API lb-api. Si votre résultat diffère beaucoup, vérifiez d’abord si la pagination est complète (piège 4) et si vous utilisez les bons champs (pièges 1-2).

Méthode correcte

Après avoir testé plusieurs approches, la méthode la plus fiable que j’ai validée est la synthèse des flux de trésorerie via l’API Data. Sans utiliser de champs pré-calculés, en calculant directement à partir des transactions brutes.

Formule :

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + valeur de marché des positions

· TRADE ACHAT : dépenser USDC pour acheter des tokens (dépense)

· TRADE VENTE : vendre des tokens pour récupérer USDC (recette)

· REDEEM : racheter une position gagnante en USDC (recette)

· SPLIT : convertir USDC en tokens (dépense)

· MERGE : fusionner des tokens en USDC (recette)

· MAKER_REBATE : remise pour le maker (recette)

· REWARD : récompenses / airdrops (recette)

· Source des données :

GET /activity?user=&limit=500, pagination avec end, puis somme par type.

· Valeur de marché des positions :

GET /positions?user=, taille × prix actuel.

· Vérification croisée :

Comparer le résultat avec l’API du classement Polymarket (lb-api.polymarket.com/profit?window=all&address=X), une différence inférieure à 10 dollars est acceptable. La différence provient de la volatilité en temps réel de la valeur des positions.

Validation : test sur les 15 premiers du classement

Après avoir calculé avec la méthode du flux de trésorerie, croiser avec l’API du classement :

swisstony : méthode flux +$5,601,000, classement +$5,601,000, différence < 10$

kch123 : méthode flux +$11,396,000, classement +$11,396,000, différence < 10$

gmanas : méthode flux +$5,024,000, classement +$5,024,000, différence < 10$

Les écarts pour ces trois adresses sont tous inférieurs à 10 dollars, la différence provient de la volatilité en temps réel des positions.

Une fois la méthode validée, j’ai analysé des centaines d’adresses principales pour leurs gains et pertes réels. C’était une autre histoire.

Résumé

SUM(cashPnl) de /positions → non, ne comprend pas les gains réalisés, le signe peut être inversé.

Somme du champ makerPnl → non, ne correspond pas au flux de trésorerie on-chain.

Calcul après déduplication par txHash → non, plus de 100$, en supprimant des fills réels.

Pagination offset + somme → non, données tronquées, erreur au-delà de 3000.

Méthode flux de trésorerie API Data → la plus fiable actuellement, moins de 10$.

La première étape pour faire du quantitatif n’est pas de chercher de l’alpha. C’est d’abord de vérifier que vous calculez correctement.

Tout ce qui précède provient d’expériences concrètes, pas de théories. L’API de PM peut changer à tout moment, il est conseillé de croiser régulièrement avec l’API du classement pour valider vos résultats.

Lien original

Cliquez pour découvrir les offres d’emploi de BlockBeats

Rejoignez la communauté officielle de BlockBeats :

Telegram abonnement : https://t.me/theblockbeats

Groupe Telegram : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia