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 ? Il y a de fortes chances qu’il soit aussi faux.
À quel point l’écart est-il é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 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 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
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 de dollars, classement réel +11,4 millions de dollars, inversion du signe
gmanas : somme de cashPnl -2,64 millions de dollars, classement réel +5,02 millions de dollars, inversion du signe
Pour ces trois adresses, deux signes de profit ou perte sont directement inversés.
Raison : l’API /positions ne retourne 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 faites pas confiance.
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 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 claire : la logique interne de makerPnl ne correspond pas aux flux USDC réels.
Quelle que soit 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 : 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. Plusieurs enregistrements sous le même txHash sont de véritables exécutions distinctes.
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, 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
L’API /activity pagine avec un offset. Si on dépasse 3000, ça renvoie une erreur 400. La documentation ne le précise pas.
Les trois adresses mentionnées 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 définition du PnL dans le classement
Après avoir calculé le PnL d’une adresse, en le comparant au classement, il y a une petite différence.
Dans la majorité des cas, l’écart est inférieur à 10 dollars (dû aux fluctuations 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 correspond étroitement à 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 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) + la valeur de la position
· TRADE ACHAT : dépenser USDC pour acheter des tokens (dépense)
· TRADE VENTE : vendre des tokens pour récupérer USDC (revenu)
· REDEEM : racheter une position gagnante en USDC (revenu)
· SPLIT : convertir USDC en tokens (dépense)
· MERGE : fusionner des tokens en USDC (revenu)
· MAKER_REBATE : remise du market maker (revenu)
· REWARD : récompenses / airdrops (revenu)
· Source des données :
GET /activity?user=&limit=500, paginer avec end, puis faire la somme par type.
· Valeur de la position :
GET /positions?user=, calculée par size × prix actuel.
· Vérification croisée :
Comparer le résultat avec l’API de classement Polymarket (lb-api.polymarket.com/profit?window=all&address=X). Si la différence est inférieure à 10 dollars, c’est acceptable. La différence provient des fluctuations en temps réel de la valeur des positions.
Validation : test sur les 15 premières adresses
Après avoir calculé avec la méthode du flux de trésorerie, croisez avec l’API de classement :
swisstony : flux de trésorerie +$5,601,000, classement +$5,601,000, différence < $10
kch123 : flux de trésorerie +$11,396,000, classement +$11,396,000, différence < $10
gmanas : flux de trésorerie +$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 étant due aux fluctuations 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 connaître leur vrai gain ou perte. 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 aux flux on-chain
Dédupliquer par txHash puis calculer → non, plus de 100 dollars, cela supprime de véritables exécutions
Pagination offset + somme → non, données tronquées, erreur >3000
Méthode flux de trésorerie API Data → la plus fiable actuellement, < $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 de 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 : https://t.me/theblockbeats
Telegram groupe : https://t.me/BlockBeats_App
Twitter officiel : https://twitter.com/BlockBeatsAsia
