I've been running self-developed automated trading on Polymarket for half a year, and the biggest pitfall I've encountered isn't strategy failure—it's being unable to accurately calculate how much I actually made.

It's not because I'm incompetent. The PnL calculation within PM itself is a minefield. The numbers provided by the official API are wrong, and rankings displayed on third-party analytics websites are also inaccurate. Writing your own script? Chances are it's still wrong.

How off the mark can it be? The #3 ranked user, kch123, calculated a loss of $3.5M using flawed methodology—but their actual profit was $11.4M. Not a minor percentage deviation—entirely reversed signs.

This article breaks down every trap I've fallen into. Traders, tool developers, and rank viewers will all eventually face them.

The most intuitive approach: fetch the /positions endpoint, sum the cashPnl (cash PnL) field.

Tested on three top-15 addresses:

swisstony: sum of cashPnl = +$35K, actual ranking value = +$5.6M — off by 158x

kch123: sum of cashPnl = -$3.52M, actual ranking value = +$11.4M — sign reversal

gmanas: sum of cashPnl = -$2.64M, actual ranking value = +$5.02M — sign reversal

Out of three addresses, two showed completely inverted profit/loss signs.

Reason: the cashPnl returned by the /positions API does not include realized PnL from positions that have been closed or redeemed. When profitable positions are automatically redeemed into USDC, those positions disappear from the API response. What remains are unsettled open positions—often predominantly in unrealized loss.

You think you're calculating total PnL, but you're only capturing unsettled portions.

The JSONL transaction data contains a makerPnl (market maker PnL) field—appears designed for PnL calculation. Don’t trust it.

In my analysis of market-making data, SUM(makerPnl) differs from on-chain cash flow accounting by an order of magnitude. The exact multiplier varies by scenario, but directionally consistent: the internal logic of makerPnl doesn’t align with actual USDC flows.

No matter how large the discrepancy, the conclusion holds: never use this field to compute PnL.

This one is the most counterintuitive.

A single txHash appears in multiple records. The natural instinct: duplicate data, deduplicate.

Don’t do that. Polymarket’s CLOB (on-chain limit order book) can match multiple maker orders within one on-chain transaction. Multiple records under the same txHash represent real, independent fills.

I previously deduplicated by txHash + asset, missing $133 in BUY-side activity. Verified on Polygon: one txHash indeed contained multiple distinct USDC Transfer events, each corresponding to a genuine trade.

Conclusion: never deduplicate based solely on txHash. To calculate PnL, directly sum the raw /activity data.

Using offset for pagination on /activity? Try offset=3100 → HTTP 400 error. Not documented.

All three addresses were verified: GET /activity?offset=3100 returns HTTP 400 with message "max historical activity offset of 3000 exceeded". Top-tier users conduct thousands of trades—3,000 records are insufficient.

Use the end parameter (pass the timestamp of the last record from the previous page minus 1) for cursor-based pagination—no upper limit.

After computing PnL for one address and comparing with the leaderboard, you notice a small discrepancy.

In most cases, the difference is under $10 (due to real-time fluctuations in position value). But if the gap is significantly larger, possible causes include: leaderboard aggregation window, cache refresh delay, or the user having multiple proxy wallets.

In testing, PnL calculated via cash flow method closely matched lb-api return values. If your result diverges significantly, first verify full pagination (pitfall #4) and correct field usage (pitfalls #1–2).

After exploring various alternative approaches, I’ve validated that the most reliable method is the Data API cash flow aggregation. No precomputed fields—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: spending USDC to buy token (outflow)

· TRADE SELL: selling token to recover USDC (inflow)

· REDEEM: redeeming profitable position for USDC (inflow)

· SPLIT: minting USDC into token pairs (outflow)

· MERGE: merging token pairs back into USDC (inflow)

· MAKER_REBATE: maker rebate (inflow)

· REWARD: rewards/airdrops (inflow)

· Data source:

GET /activity?user=<address>&limit=500, paginate using end parameter, pull all records, then aggregate by type.

· Position Market Value:

GET /positions?user=<address>, multiply size × curPrice.

· Cross-validation:

Compare computed results with Polymarket leaderboard API (lb-api.polymarket.com/profit?window=all&address=X). Difference under $10 counts as valid—variance comes from real-time position valuation changes.

After computing via cash flow method, cross-check with leaderboard API:

swisstony: cash flow method +$5.601M, leaderboard +$5.601M, difference < $10

kch123: cash flow method +$11.396M, leaderboard +$11.396M, difference < $10

gmanas: cash flow method +$5.024M, leaderboard +$5.024M, difference < $10

All three addresses show errors within $10—attributed to real-time fluctuations in position market value.

Once the method is validated, I used it to analyze the true PnL of hundreds of top-tier addresses. That’s another story.

SUM(cashPnl) from /positions → invalid, excludes settled profits, sign may reverse

SUM(makerPnl) → invalid, inconsistent with on-chain cash flow

Deduplication by txHash → invalid, misses $100+ in real fills

Offset pagination + summation → invalid, data truncation, >3000 triggers error

Data API cash flow method → currently most reliable, < $10

The first step in quantitative trading isn’t finding alpha. It’s ensuring your calculations are correct.

All of the above stems from real-world experience—not theoretical deduction. PM’s APIs may change behavior at any time. Regular cross-validation with the leaderboard API is strongly recommended.

Source: BlockBeats