Original Title: “Polymarket PnL Accurate Calculation: Why Your Profit and Loss Might Be Completely Wrong”
Original Author: Leo, Cryptocurrency Analyst

I’ve been developing automated trading on Polymarket for half a year, and the biggest pitfall I’ve encountered isn’t strategy failure, but that I couldn’t even accurately calculate how much I earned.

It’s not that I’m bad at it. It’s that PM’s PnL calculation itself is a minefield. The numbers provided by the official API are wrong, and the rankings displayed on third-party analysis sites are also incorrect. You write your own scripts to calculate? Most likely, they’re still wrong.

How big is the deviation? The third-place address kch123, using an incorrect method, calculated a loss of $3.5 million, but the actual profit was $11.4 million. It’s not just a few percentage points off — the profit and loss signs are reversed.

This article breaks down every pit I’ve fallen into. Traders, tool developers, ranking viewers — you’ll encounter these sooner or later.

Pit 1: cashPnl Does Not Include Settled Profits and Losses

The most intuitive approach: pull the /positions interface and sum the cashPnl (cash profit and loss) fields.

Testing the top 3 addresses on the ranking:

swisstony: Sum of cashPnl +$35k, actual ranking +$5.6 million, difference of 158 times

kch123: Sum of cashPnl -$3.52 million, actual ranking +$11.4 million, sign reversed

gmanas: Sum of cashPnl -$2.64 million, actual ranking +$5.02 million, sign reversed

For these three addresses, two of the profit and loss signs are directly reversed.

Reason: The cashPnl returned by the /positions API does not include realized PnL from closed/redeemed positions. When a winning position is automatically redeemed into USDC, that position disappears from the API response. What’s left are unsettled positions — often showing unrealized losses.

You think you’re calculating all profits and losses, but you’re only getting the unsettled part.

Pit 2: makerPnl Field Is Inconsistent with On-Chain Cash Flows

The trading data JSONL contains a makerPnl (market maker profit and loss) field, which sounds like it’s for calculating PnL. Don’t trust it.

In my observation of market-making data, the sum of makerPnl calculated from the data differs by an order of magnitude from the on-chain cash flow accounting results. The exact multiple varies by scenario, but the direction is consistent: the internal logic of makerPnl doesn’t match the actual USDC flow.

No matter how big the deviation, the conclusion is the same: do not use this field to calculate PnL.

Pit 3: Do Not Deduplicate by txHash Alone

This is counterintuitive.

Multiple records with the same txHash (transaction hash) appear. The normal reaction: duplicate data, remove duplicates.

You can’t do that. PM’s CLOB (on-chain limit order book) can match multiple maker orders within a single on-chain transaction. Multiple records under the same txHash are real, independent fills.

Previously, I deduplicated by txHash + asset, which undercounted buy-side trades by $133. Verified on Polygon chain, a single transaction hash indeed has multiple independent USDC transfer events, each corresponding to a real trade.

Conclusion: do not deduplicate by txHash alone. To calculate PnL, sum the raw data from /activity directly.

Pit 4: Offset Pagination Has a Limit

Paging through /activity with offset? Exceeding 3,000 causes a 400 error. The documentation doesn’t specify this.

All three addresses verified: GET /activity?offset=3100 returns HTTP 400, with error message “max historical activity offset of 3000 exceeded.” Top traders often have tens of thousands of transactions, so 3,000 isn’t enough.

Using the end parameter (passing the timestamp of the last record from the previous page minus 1) for cursor pagination has no limit.

Pit 5: Differences in PnL Definitions in Rankings

After calculating the PnL for an address, comparing it with the ranking API shows a small discrepancy.

Most of the time, the difference is within $10 (due to real-time fluctuations in position market value). But if the difference is significantly larger, possible reasons include: the ranking’s aggregation window, cache refresh delays, or the user binding multiple proxy wallets.

In testing, the PnL calculated via cash flow method closely matches the lb-api response. If your results differ greatly, first check whether pagination is complete (Pit 4), and whether you’re using the correct fields (Pit 1-2).

Correct Approach

After trying various methods, I verified that the most reliable way is to use the Data API cash flow summary. No pre-calculated fields needed; directly calculate fund inflows and outflows from raw transaction records.

Formula:

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + Position Market Value

· TRADE BUY: Spend USDC to buy tokens (expenditure)

· TRADE SELL: Sell tokens to recover USDC (income)

· REDEEM: Redeem winning positions for USDC (income)

· SPLIT: Mint USDC into token pairs (expenditure)

· MERGE: Merge token pairs back into USDC (income)

· MAKER_REBATE: Maker rebates (income)

· REWARD: Rewards / airdrops (income)

· Data source:

GET /activity?user=