Original title: Polymarket PnL Accurate Calculator: Why do you count all the gains and losses as wrong
Original by Leo, Encryption Analyst

I've been studying automation for six months in Polymarket, and the biggest pit I've ever stepped on is not a tactical failure, it's not even the right amount of money I made。

It's not my dish. It's PM's PnL calculation itself is a minefield. The official API gave you the wrong number and the third-party analysis website showed the wrong ranking. You write your own script? Probably wrong。

how far is the deviation? 3rd on the list of kch123, with a loss of $3.5 million and an actual profit of $11.4 million. it's not a few percentage points away — it's all the opposite。

This is a story about every pit I step on. Traders, tool-writers, watchers will meet sooner or later。

Pit 1: CashPnl does not contain settled profits

The most intuitive approach is to pull/positions interfaces, to sum the cashPnl field。

Take the top 15 addresses and three addresses

swisstony:cashPnl Summation + $35 000, actual + $5.6 million, 158 times the difference

kch123:cashPnl Summon- $3.52 millionQuite the score+ $11.4 million, sign invert

gmanas:cashPnl Summon$2.64 millionQuite the score+ $5.02 million, sign invert

Three addresses, two profit-deficit symbols directly reverse。

Reason: CashPnl returned from /propositions interface does not contain registered PnL that has been closed/reRED. After winning the slot was redeemed to USDC, this position disappeared from the API response. What remains is the open hold — often at a loss。

You think you're counting all the profits and losses, but you've only got the outstanding portion。

Pit 2: markerPnl field does not match the chain cash flow

There's a markerPnl field in JSONL, and the name is for your PnL. Don't believe it。

I've seen in the market data that the numbers calculated by SUM (makerPnl) are one order of magnitude different from the results of the chain cash flow accounting. The specific multiple may vary depending on the scene, but in the same direction: the internal calculation logic of the markerPnl does not match the actual USDC flow。

Whatever the deviation, the conclusion is the same: do not count PnL with this field。

Pit 3: Unable to press txHash alone Heavy

This is the anti-intuitive。

The same txHash (trade Hashi) has several records, and normal people react first: repeat data, take it heavy。

This cannot be done. PM's CLOB can set up multiple marker orders in a chain transaction, and multiple records under the same txHash are real independent bills。

I used to press txHash + asset to get heavy, but the BUY side dropped $133. On the Polygon chain, there are indeed several independent USDC Transfer events in one transaction, each of which corresponds to a real deal。

Conclusion: txhash alone cannot be heavy. To calculate the PnL, you need to sum the original data。

pocket 4:offset with ceiling

/activity interface flips pages, using infoset? more than 30000 direct 400 errors. it's not in the document。

All three addresses above have been verified: GET/activity?offset=3100 returns HTTP 400, error message max physical activity of 3000 obtained. The head player's got thousands of deals, 3,000 not enough。

use an end parameter (transmits the last time stamp of the previous page - 1) for a trip to flip the page without an upper limit。

Pit 5: PnL caliber difference

You've finished an address, PnL, and you're on the run。

in most cases the gap is within $10 (real-time fluctuations from warehouse market value). however, if the gap is significantly greater, the possible reasons include the aggregation window on the list, the delay in the cache cleanup, or the multiple proxy wallet binding by the user。

In fact, PnL, a single address calculated by cash flow method, is the same as lb-api returns. If there is a wide gap in results, check whether the page is complete (pit 4) and whether the wrong field (pit 1-2) is used。

The right way

After trying all kinds of bad roads, I verified that the most reliable method was Data API cash flow aggregation. No projection fields are required to account for the movement of funds directly from the original transaction records。

Formula:

PnL = SUM (TRADE where side=SELL) + SUM (REDEM) + SUM (MERGE) + SUM (MAKER REBATE) + SUM (REWARD) - SUM (TRADE where side=BUY) - SUM (SPLIT) + hold market value

TRADE BUIY: USDC buy token (expenditure)

TRADE SELL: sell token recovery USDC (income)

• REDEEM: WINNING POSITION REDEEMED USDC (INCOME)

• SPLIT: USDC found token (expenditure)

• MERGE:token against merge back to USDC (income)

MAKER REBATE: Maker Home Helper (income)

REWARD: Incentives/airdrops (income)

Data sources:

GET/activity?user=< Adress> & limit=500, flipping pages with an end, full-size sum。

:: Market value of holdings:

Get/propositions?user=< Adress> size x curPrice。

:: Cross-check:

Compared to the Polymarket ranking API (lb-api.polymarket.com/profit?window=all&adress=X), the difference & lt; $10. The difference is due to real-time fluctuations in the market value of holdings。

Validation: Top 15

AFTER THE CASH FLOW METHOD, CROSS-CHECK THE LIST API:

swisstony: cash flow method + $5.601 million, ranking + $56.01 million, gap & lt; $10

kch123: cash flow method + $11396,000, ranking + $11396,000, gap & lt; $10

gmanas: cash flow method + $50.24 million, ranking + $50.24 million, gap & lt; $10

The error in all three addresses is within $10 and the difference is due to real-time fluctuations in the market value of the warehouse。

After the method went through, I analyzed it for 100 head addresses. That's another thing。

Summary

SUM(cashPnl) from /positionsNo, no, no, no, no

makePnl field sumOh, no, it doesn't match the cash flow on the chain

Press txHash to recalculateoh, no, $100+, cut the real one

page flip + sum♪ no, data cut, > 3000

Data API Cash Flow Method• most reliable at present, < $10

the first step in quantifying is not to find alpha. make sure you're right。

ALL OF THE ABOVE COMES FROM THE ACTUAL PEDALS, NOT THEORETICAL. PM'S API CAN ADJUST BEHAVIOR AT ANY TIME AND RECOMMENDS THAT YOU CROSS-CHECK YOUR CALCULATIONS REGULARLY WITH THE API RANKING。

Original Link