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 parce que je suis incompétent. C’est parce que le calcul du PnL de PM est une zone à risques. Les chiffres fournis par l’API officielle sont incorrects, et le classement affiché par les sites d’analyse tiers est également erroné. Vous écrivez votre propre script pour le calcul ? Probablement encore faux.

À quel point la déviation est-elle é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 profit 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 signe du gain ou de la perte est inversé.

Cet article décompose chaque piège que j’ai rencontré. Que vous soyez trader, développeur d’outils ou observateur du classement, vous finirez par tomber dessus.

Piège 1 : cashPnl ne comprend pas les gains réalisés déjà clôturé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 les trois adresses en tête 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 : l’API /positions ne retourne pas le cashPnl des positions déjà clôturées ou rachetées. Après avoir automatiquement racheté une position gagnante en USDC, cette position disparaît de la réponse API. Ce qui reste, ce sont les positions non clôturé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 clôturé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 par rapport au calcul basé sur les 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 aux flux USDC réels.

Quelle que soit l’ampleur de la déviation, 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 : dédupliquer.

Mais ce n’est pas correct. Le CLOB (order book on-chain) de PM peut faire matcher plusieurs ordres maker dans une seule transaction. Les multiples 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 distincts, 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) ? Si on dépasse 3000, erreur 400. La documentation ne le mentionne pas.

Les trois adresses ci-dessus ont toutes été vérifiées : GET /activity?offset=3100 retourne une erreur HTTP 400, avec le message 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 (timestamp de la dernière transaction de la page précédente - 1) pour faire la pagination par curseur 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, il y a souvent une 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, le délai de rafraîchissement du cache, ou le fait que l’utilisateur a lié plusieurs portefeuilles proxy.

En pratique, le PnL calculé par la méthode flux de trésorerie est très proche de celui retourné 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 recommandée

Après avoir testé plusieurs approches, la méthode la plus fiable que j’ai validée est la synthèse via l’API Data en utilisant les flux de trésorerie. Sans pré-calculs, 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 USDC d’une position gagnante (recette)

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

· MERGE : fusionner des tokens en USDC (recette)

· MAKER_REBATE : remise pour le market 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 premières adresses

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

swisstony : flux de trésorerie +5,601 millions $, classement +5,601 millions $, différence < 10 $

kch123 : flux de trésorerie +11,396 millions $, classement +11,396 millions $, différence < 10 $

gmanas : flux de trésorerie +5,024 millions $, classement +5,024 millions $, 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 de la valeur des positions.

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

Résumé

SUM(cashPnl) depuis /positions → pas fiable, ne comprend pas les gains réalisés, signe potentiellement inversé

Somme du champ makerPnl → pas fiable, incohérence avec les flux on-chain

Déduplication par txHash → pas fiable, supprime des fills réels, surtout si > 100 $

Pagination offset + somme → pas fiable, données tronquées, erreur > 3000

Méthode flux de trésorerie via Data API → la plus fiable actuellement, différence < 10 $

La première étape pour faire du quantitatif n’est pas de chercher de l’alpha. C’est de s’assurer 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 vérifier 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

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

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