Polymarket PnL Accurate Calculation: Why Your Profit and Loss Might Be Incorrect?

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

Author: Rhythm BlockBeats

Source:

Repost: Mars Finance

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 made or lost.

It’s not that I’m bad at it. It’s that the PnL calculation in PM 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. If you write your own scripts to calculate? Most likely still wrong.

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

This article breaks down every pitfall I’ve encountered. Whether you’re trading, building tools, or viewing rankings, you’ll encounter these issues sooner or later.

Pit 1: cashPnl Does Not Include Settled Profits and Losses

Most intuitive approach: call the /positions API, sum the cashPnl (cash profit and loss) field.

Testing three addresses in the top 15 on the leaderboard:

swisstony: sum of cashPnl +$35k, actual leaderboard +$5.6 million, difference of 158 times

kch123: sum of cashPnl -$3.52 million, actual leaderboard +$11.4 million, sign reversed

gmanas: sum of cashPnl -$2.64 million, actual leaderboard +$5.02 million, sign reversed

For these three addresses, two of the profit/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 remains are unsettled positions — often showing unrealized losses.

You think you’re calculating total profit and loss, but you’re only getting the unsettled part.

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

In the JSONL trading data, there’s a makerPnl (market-making profit and loss) field, which seems to be 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 calculations. The exact multiple varies depending on the 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: don’t use this field to calculate PnL.

Pit 3: Cannot Deduplicate by txHash Alone

This is the most counterintuitive.

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

But don’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 genuine independent fills.

Previously, I deduplicated by txHash + asset, which caused the buy side to be undercounted by $133. On Polygon, I verified that a single transaction hash indeed has multiple independent USDC Transfer events, each corresponding to a real trade.

Conclusion: don’t deduplicate by txHash alone. To calculate PnL, sum the raw data from /activity directly.

Pit 4: Offset Pagination Has a Limit

Using offset (offset) for pagination in /activity? If it exceeds 3,000, it returns a 400 error. Not documented.

All three addresses above have been 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 is not 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 a single address’s PnL, compare it with the leaderboard, and there’s a small discrepancy.

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

In testing, the PnL calculated via cash flow matches the lb-api response very closely. If your results differ greatly, first check whether pagination is complete (Pit 4) and whether you used 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’s cash flow summation. No pre-calculated fields, just sum the 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 sources:

GET /activity?user=&limit=500, paginate with end, sum by type after full retrieval.

· Position Market Value:

GET /positions?user=, size × currentPrice.

· Cross-validation:

Compare the calculation results with Polymarket’s leaderboard API (lb-api.polymarket.com/profit?window=all&address=X). If the difference is less than <$10, it’s acceptable. Differences are due to real-time fluctuations in position value.

Validation: Top 15 addresses tested

Using the cash flow method, then cross-verified with the leaderboard API:

swisstony: cash flow +$35k, leaderboard +$5.6M, difference < $10

kch123: cash flow +$5.6M, leaderboard +$11.4M, difference < $10

gmanas: cash flow +$11.4M, leaderboard +$5.02M, difference < $10

All three addresses have discrepancies within $10, mainly due to real-time fluctuations in position value.

Once the method is validated, I used it to analyze the real profit and loss of hundreds of top addresses. That’s a different story.

Summary

SUM(cashPnl) from /positions → Not reliable, excludes settled profits, signs may reverse

Sum of makerPnl field → Not reliable, inconsistent with on-chain cash flows

Deduplicate by txHash then calculate → Not reliable, over $100, removes real fills

Offset pagination + summation → Not reliable, data truncated, errors over 3,000

Data API cash flow method → Currently the most reliable, <$10 discrepancy

For quant trading, the first step isn’t finding alpha. It’s making sure your calculations are correct.

All of the above are based on real trading experience, not theoretical deduction. PM’s API behavior may change at any time, so it’s recommended to regularly cross-verify your results with the leaderboard API.