Titre original : « Calcul précis du PnL de Polymarket : pourquoi vos 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 aussi erroné. Vous écrivez votre propre script pour le calculer ? Probablement encore faux.

À quel point la déviation est-elle énorme ? Le troisième du classement, kch123, a calculé une perte de 3,5 millions de dollars avec une méthode erronée, alors que le résultat réel est un profit 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à réglés

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

Test pratique sur les trois adresses du top 15 :

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

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

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

Pour ces trois adresses, deux signes de profit ou perte sont directement inversés.

Raison : l’API /positions ne renvoie pas le cashPnl des positions déjà clôturées ou rachetées. Lorsqu’une position gagnante est automatiquement rachetée 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 pas y croire.

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

Peu importe 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 il ne faut pas faire ça. 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 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 de /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. La documentation ne le mentionne pas.

Les trois adresses ci-dessus ont toutes été testées : GET /activity?offset=3100 renvoie HTTP 400, avec le message d’erreur « max historical activity offset of 3000 exceeded » (décalage maximum de 3000 dépassé). 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, il y a souvent 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, 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 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), ou si vous utilisez les mauvais champs (pièges 1-2).

Méthode correcte

Après avoir testé différentes 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 = SOMME(TRADE où side=SELL) + SOMME(REDEEM) + SOMME(MERGE) + SOMME(MAKER_REBATE) + SOMME(REWARD) - SOMME(TRADE où side=BUY) - SOMME(SPLIT) + valeur de la position

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

· TRADE SELL : vendre des tokens pour récupérer USDC (revenu)

· REDEEM : racheter USDC en clôturant une position gagnante (revenu)

· SPLIT : créer des tokens à partir d’USDC (dépense)

· MERGE : fusionner des tokens en USDC (revenu)

· MAKER_REBATE : remise pour le market maker (revenu)

· REWARD : récompenses ou airdrops (revenu)

· Source des données :

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

· Valeur de la position :

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 le top 15 du classement

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

swisstony : flux de trésorerie +560 100 dollars, classement +560 100 dollars, différence < 10 dollars

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

gmanas : flux de trésorerie +5 024 000 dollars, classement +5 024 000 dollars, différence < 10 dollars

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 principales pour leurs gains et pertes réels. C’était une autre histoire.

Résumé

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

Somme du champ makerPnl → impossible, ne correspond pas aux flux de trésorerie on-chain

Dédupliquer par txHash puis calculer → impossible, supprime des fills réels pour +100 dollars

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

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

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