Polymarket PnL 精准计算：为什么你算的盈亏可能全是错的

五个计算陷阱逐个拆解，附排行榜前 15 实测验证

我在 Polymarket 做量化交易半年，踩过的最大坑不是策略失灵，是连自己赚了多少钱都算不对。

官方 API 给你的数字是错的，第三方分析网站展示的排名也是错的。你自己写脚本算？大概率还是错的。

偏差有多离谱？排行榜第 3 名 kch123，用错误方法算出来亏 $350 万，实际盈利 $1140 万。盈亏符号都反了。

坑 1：Positions API 只剩亏损面

最直觉的做法：拉 /positions 接口，求和 cashPnl 字段。

拿排行榜前 15 的三个地址实测：

用户	cashPnl 求和	排行榜实际 PnL	偏差
swisstony	+$3.5 万	+$560 万	差 158 倍
kch123	-$352 万	+$1140 万	符号反转
gmanas	-$264 万	+$502 万	符号反转

三个地址，两个盈亏符号直接反了。

原因藏在 PM 的自动赎回机制里。赢了的仓位被自动赎回成 USDC，赎回完这个 position 就从 API 里消失了。留下来的全是没结算的、亏的、套牢的。

你以为在算全部盈亏，其实只看到了亏损那一半。

交易数据 JSONL 里有个 makerPnl 字段，看名字就是给你算 PnL 用的。别信。

我拿 H35 策略实测，SUM(makerPnl) 算出来 +$1,270。链上现金流核下来？+$79。

16 倍。这字段的内部逻辑跟链上 USDC 流动对不上，具体原因不清楚，但结论很明确。

同一个 txHash 出现了多条金额一样的记录，正常人第一反应：重复数据，去重。

不对。这些是真实的多笔 maker fill。

我之前按 txHash + asset 去重，BUY 侧少算了 $133。上 Polygon 链验证才发现，一个交易哈希里确实有多个独立的 USDC Transfer event，每条都对应一笔真实成交。PM 的 CLOB 在一笔链上交易里可以撮合多个 maker 订单。

结论：不去重，直接求和。

/activity 接口翻页，用 offset？超过 3000 条直接 400 报错。文档里没写。

头部玩家动辄上万笔交易，3000 条根本不够。

用 end 参数（传上一页最后一条的时间戳 - 1）做游标翻页，没有上限。

你算完一个地址的 PnL，去排行榜一对比，差了好几万。

不是算错了。Leaderboard 把同一个用户名下的所有 proxy wallet 加在一起。头部玩家很多有多个钱包，你只看一个地址，天然对不上。

散户（单钱包）不受影响。

试了各种歪路之后，我验证下来最可靠的方法是 Data API 现金流汇总。不用任何预计算字段，直接从原始交易记录算资金进出。

PnL = SUM(SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(REBATE)
    - SUM(BUY) - SUM(SPLIT)
    + 持仓市值

数据来源：GET /activity?user=<address>&limit=500，用 end 翻页，全量拉取后按类型求和。

持仓市值：GET /positions?user=<address>，size × curPrice。

交叉验证：拿计算结果跟 Polymarket 排行榜 API（lb-api.polymarket.com/profit?window=all&address=X）对比，差 <$10 就算过。

用户	现金流法 PnL	排行榜 PnL	差距
swisstony	+$560.1 万	+$560.1 万	< $10
kch123	+$1139.6 万	+$1139.6 万	< $10
gmanas	+$502.4 万	+$502.4 万	< $10

三个地址误差均在 $10 以内。

做量化的第一步不是找 alpha。是先确认你算得对。

以上全部来自实盘踩坑，不是理论推导。PM 的 API 随时可能调整行为，建议定期用排行榜 API 交叉验证你的计算结果。

Polymarket

预测市场 · 量化交易