Calcul précis du PnL de Polymarket : pourquoi votre calcul des gains et pertes pourrait être incorrect ?

Titre original : « Polymarket PnL Précis : pourquoi vos calculs de profit et perte peuvent être totalement erronés » Auteur original : Leo, analyste en cryptomonnaie

Auteur original :律动BlockBeats

Source originale :

Reproduction : Huoxing Finance

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 stratégie défaillante, mais le fait de ne pas pouvoir calculer correctement combien j’ai réellement gagné ou perdu.

Ce n’est pas que je sois incompétent. C’est que le calcul du PnL (profit et perte) de PM est en soi une zone de danger. L’API officielle vous donne des chiffres erronés, et le classement affiché par les sites d’analyse tiers est également incorrect. Vous écrivez votre propre script pour le calculer ? Probablement aussi erroné.

À 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 bénéfice de 11,4 millions de dollars. Ce n’est pas une différence de quelques points de pourcentage — c’est que le symbole de profit ou perte est inversé.

Cet article décompose chaque piège que j’ai rencontré. Que vous fassiez du trading, que vous développiez des outils ou que vous 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 cash).

En testant 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 symbole

gmanas : somme de cashPnl -$2,64 millions, classement réel +$502 000, inversion du symbole

Pour ces trois adresses, deux ont leur symbole de profit et perte inversé.

Raison : l’API /positions renvoie un cashPnl qui n’inclut pas les gains réalisés qui ont été clôturés ou rachetés. 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 encore réglées — souvent en perte latente.

Vous pensez calculer tout le profit et la perte, 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 transaction, 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 du résultat du 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 calcul de makerPnl ne correspond pas au flux USDC réel.

Quelle que soit l’ampleur de la déviation, la conclusion est la même : ne pas utiliser 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éduplication.

Mais ce n’est pas correct. 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 fills indépendants.

J’avais auparavant dédupliqué par txHash + asset, ce qui sous-estimait de 133 dollars le côté ACHAT. Sur la chaîne Polygon, une transaction hash 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 de /activity.

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

L’API /activity pagine avec offset ? Au-delà de 3000, elle renvoie une erreur 400. La documentation ne le mentionne pas.

Les trois adresses ci-dessus ont é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 comptes 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 sans limite.

Piège 5 : différences dans la définition du PnL du classement

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.

Dans mes tests, le PnL calculé par 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 du 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 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 : créer des tokens en USDC (dépense)

· MERGE : fusionner des tokens en USDC (recette)

· MAKER_REBATE : remises du market maker (recette)

· REWARD : récompenses / airdrops (recette)

· Source des données :

GET /activity?user=&limit=500, paginer avec end, puis faire la 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 avoir calculé avec la méthode du flux de trésorerie, croiser avec l’API du classement :

swisstony : +$5,6 millions (flux de trésorerie) / +$5,6 millions (classement), différence < $10

kch123 : +$11,4 millions / +$11,4 millions, différence < $10

gmanas : +$5,02 millions / +$5,02 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 des positions.

Une fois la méthode validée, j’ai analysé des centaines d’adresses majeures pour connaître leur vrai profit et perte. C’était une autre histoire.

Résumé

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

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

Dédupliquer par txHash puis calculer → non, plus de 100 dollars, on perd des fills réels

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

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

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