原文タイトル：《Polymarket PnL 精密計算：なぜあなたの損益計算はすべて間違っている可能性があるのか》 原文作者：Leo、暗号分析師
原文作者：律動BlockBeats
原文出典：
転載：火星财经
私はPolymarketで自作の自動取引を半年間行ってきたが、最大の落とし穴は戦略の失敗ではなく、自分がいくら儲けたかすら正しく計算できていなかったことだ。
私が下手なわけではない。問題はPMのPnL計算自体が落とし穴だということだ。公式APIが提供する数字は誤っているし、サードパーティの分析サイトが表示するランキングも誤っている。自分でスクリプトを書いて計算？それもほぼ間違っている可能性が高い。
偏差はどれほど離れているのか？ランキング第3位のkch123は誤った方法で計算し、損失を$350万と出したが、実際の利益は$1140万だった。差は数ポイントではなく、損益の符号すら逆になっている。
この記事では、私が経験した落とし穴を一つ一つ解説する。取引を行う人、ツールを作る人、ランキングを見る人、いずれも早晩直面するだろう。
落とし穴1：cashPnlは決済済みの利益を含まない
最も直感的な方法：/positionsインターフェースからcashPnl（現金損益）フィールドを合計する。
ランキング上位15のアドレス3つで実測：
swisstony：cashPnl合計 +$3.5万、実際のランキング +$560万、差は158倍
kch123：cashPnl合計 -$352万、実際のランキング +$1140万、符号が逆
gmanas：cashPnl合計 -$264万、実際のランキング +$502万、符号が逆
この3つのアドレスのうち、2つは損益の符号が逆になっている。
原因：/positions APIが返すcashPnlは、既にクローズまたは償還された実現損益（realized PnL）を含んでいないためだ。勝ったポジションは自動的にUSDCに償還されると、そのポジションはAPIのレスポンスから消える。残るのは未決済のポジションであり、これが多くの場合、含み損を抱えている。
あなたは全ての損益を計算していると思っているかもしれないが、実際には未決済部分だけを取得しているに過ぎない。
落とし穴2：makerPnlフィールドとオンチェーンのキャッシュフローが一致しない
取引データのJSONLにはmakerPnl（マーケットメイカーの損益）というフィールドがあるが、名前からして損益計算用だと思うだろう。だが、信じてはいけない。
私はマーケットデータを観察していて、SUM(makerPnl)で算出した数字とオンチェーンのキャッシュフローの結果とでは、桁違いの差があることに気づいた。具体的な倍率はシナリオによって異なるが、方向性は一貫している：makerPnlの内部計算ロジックは、実際のUSDCの流動と一致していない。
どれだけ偏差が大きくても、結論は同じ：このフィールドを使って損益を計算すべきではない。
落とし穴3：txHashだけで重複を除去してはいけない
これが最も直感に反する。
同じtxHash（取引ハッシュ）が複数のレコードとして出てきた場合、普通は「重複データだから除外しよう」と考えるだろう。しかし、そうしてはいけない。PMのCLOB（チェーン上のリミットオーダーブック）は、一つの取引内で複数のmaker注文をマッチさせることができる。同じtxHashの複数レコードは、実際にはそれぞれが独立した執行（fill）である。
私は以前、txHash +資産で重複除去を行ったが、その結果、BUY側の損益が$133少なくなった。Polygonチェーンで検証したところ、一つの取引ハッシュには複数のUSDC Transferイベントが存在し、それぞれが実際の取引に対応していることが確認できた。
結論：txHashだけで重複除去を行うのは誤り。損益を計算するには、/activityの生データをそのまま合計すべきだ。
落とし穴4：offsetによるページングには上限がある
/activityインターフェースのページングでoffset（オフセット）を使うと、3000件を超えると直接400エラーになる。ドキュメントには記載されていない。
上記の3つのアドレスで検証済み：GET /activity?offset=3100はHTTP 400を返し、「最大の過去活動オフセットは3000」とエラーメッセージが出る。トッププレイヤーは何万件もの取引を行っているため、3000件では全然足りない。
代わりに、endパラメータ（前ページの最後の取引のタイムスタンプ-1）を使ったカーソルページングは上限なし。
落とし穴5：ランキングの損益口径の違い
あるアドレスの損益を計算し、ランキングと比較すると、少し差が出る。
大半の場合、その差は$10以内（ポジションの時価総額のリアルタイム変動による）だが、差が大きい場合、その原因として考えられるのは：ランキングの集計ウィンドウ、キャッシュの更新遅延、または複数のproxy walletをユーザーが紐付けているケースなどだ。
実測では、キャッシュフロー法で計算した単一アドレスの損益は、lb-apiの返す値とほぼ一致している。もし差が大きい場合は、まずページングの完全性（落とし穴4）や誤ったフィールドの使用（落とし穴1-2）を確認すべきだ。
正しいやり方
さまざまな方法を試した結果、最も信頼できるのはData APIのキャッシュフロー集計だ。事前に計算されたフィールドに頼らず、原始的な取引記録から資金の流入出を直接算出する。
計算式：
損益 = SUM(売り取引) + SUM(償還) + SUM(マージ) + SUM(メーカーリベート) + SUM(報酬) - SUM(買い取引) - SUM(スプリット) + ポジションの時価総額
· TRADE BUY：USDCを使ってトークンを購入（支出）
· TRADE SELL：トークンを売ってUSDCを回収（収入）
· REDEEM：勝ったポジションのUSDC償還（収入）
· SPLIT：USDCをトークンに鋳造（支出）
· MERGE：トークンをUSDCに合併（収入）
· MAKER_REBATE：メーカーのリベート（収入）
· REWARD：報酬・エアドロップ（収入）
· データ取得：
GET /activity?user=&limit=500をendでページングし、全て取得後にタイプ別に合計。
· ポジションの時価総額：
GET /positions?user=、size×現在価格。
· クロス検証：
計算結果とPolymarketのランキングAPI（lb-api.polymarket.com/profit?window=all&address=X）を比較し、差が<$10なら合格。差はポジションの時価総額のリアルタイム変動による。
検証：ランキング上位15の実測
キャッシュフロー法で計算後、ランキングAPIとクロス検証：
swisstony：キャッシュフロー +$560.1万、ランキング +$560.1万、差 <$10
kch123：キャッシュフロー +$1139.6万、ランキング +$1139.6万、差 <$10
gmanas：キャッシュフロー +$502.4万、ランキング +$502.4万、差 <$10
これらのアドレスの誤差はすべて$10以内であり、差はポジションの時価総額のリアルタイム変動による。
この方法を使って、私は何百ものトップアドレスの実損益を分析した。これは別次元の話だ。
まとめ
SUM(cashPnl) from /positions → 不可、既に決済済みの利益を含まず、符号も逆になる可能性あり
makerPnlフィールドの合計 → 不可、オンチェーンのキャッシュフローと一致しない
txHashだけで重複除去 → 不可、$100超の取引も削除されてしまう
offsetページング＋合計 → 不可、データが切り捨てられ、3000超でエラー
Data APIのキャッシュフロー集計 → 現時点で最も信頼できる、<$10
量的分析を始める第一歩は、アルファを探すことではない。まずは自分の計算が正しいことを確認することだ。
これらはすべて実盤での失敗から得た教訓であり、理論的な推論ではない。PMのAPIは随時仕様変更される可能性があるため、定期的にランキングAPIと照合して計算結果を検証することを推奨する。
489.61K 人気度
58.72M 人気度
37.69K 人気度
1M 人気度
32.36K 人気度
Polymarket PnL正確計算：為什麼你算的盈虧可能是錯的？
原文タイトル：《Polymarket PnL 精密計算：なぜあなたの損益計算はすべて間違っている可能性があるのか》
原文作者：Leo、暗号分析師
原文作者：律動BlockBeats
原文出典：
転載：火星财经
私はPolymarketで自作の自動取引を半年間行ってきたが、最大の落とし穴は戦略の失敗ではなく、自分がいくら儲けたかすら正しく計算できていなかったことだ。
私が下手なわけではない。問題はPMのPnL計算自体が落とし穴だということだ。公式APIが提供する数字は誤っているし、サードパーティの分析サイトが表示するランキングも誤っている。自分でスクリプトを書いて計算？それもほぼ間違っている可能性が高い。
偏差はどれほど離れているのか？ランキング第3位のkch123は誤った方法で計算し、損失を$350万と出したが、実際の利益は$1140万だった。差は数ポイントではなく、損益の符号すら逆になっている。
この記事では、私が経験した落とし穴を一つ一つ解説する。取引を行う人、ツールを作る人、ランキングを見る人、いずれも早晩直面するだろう。
落とし穴1：cashPnlは決済済みの利益を含まない
最も直感的な方法：/positionsインターフェースからcashPnl（現金損益）フィールドを合計する。
ランキング上位15のアドレス3つで実測：
swisstony：cashPnl合計 +$3.5万、実際のランキング +$560万、差は158倍
kch123：cashPnl合計 -$352万、実際のランキング +$1140万、符号が逆
gmanas：cashPnl合計 -$264万、実際のランキング +$502万、符号が逆
この3つのアドレスのうち、2つは損益の符号が逆になっている。
原因：/positions APIが返すcashPnlは、既にクローズまたは償還された実現損益（realized PnL）を含んでいないためだ。勝ったポジションは自動的にUSDCに償還されると、そのポジションはAPIのレスポンスから消える。残るのは未決済のポジションであり、これが多くの場合、含み損を抱えている。
あなたは全ての損益を計算していると思っているかもしれないが、実際には未決済部分だけを取得しているに過ぎない。
落とし穴2：makerPnlフィールドとオンチェーンのキャッシュフローが一致しない
取引データのJSONLにはmakerPnl（マーケットメイカーの損益）というフィールドがあるが、名前からして損益計算用だと思うだろう。だが、信じてはいけない。
私はマーケットデータを観察していて、SUM(makerPnl)で算出した数字とオンチェーンのキャッシュフローの結果とでは、桁違いの差があることに気づいた。具体的な倍率はシナリオによって異なるが、方向性は一貫している：makerPnlの内部計算ロジックは、実際のUSDCの流動と一致していない。
どれだけ偏差が大きくても、結論は同じ：このフィールドを使って損益を計算すべきではない。
落とし穴3：txHashだけで重複を除去してはいけない
これが最も直感に反する。
同じtxHash（取引ハッシュ）が複数のレコードとして出てきた場合、普通は「重複データだから除外しよう」と考えるだろう。しかし、そうしてはいけない。PMのCLOB（チェーン上のリミットオーダーブック）は、一つの取引内で複数のmaker注文をマッチさせることができる。同じtxHashの複数レコードは、実際にはそれぞれが独立した執行（fill）である。
私は以前、txHash +資産で重複除去を行ったが、その結果、BUY側の損益が$133少なくなった。Polygonチェーンで検証したところ、一つの取引ハッシュには複数のUSDC Transferイベントが存在し、それぞれが実際の取引に対応していることが確認できた。
結論：txHashだけで重複除去を行うのは誤り。損益を計算するには、/activityの生データをそのまま合計すべきだ。
落とし穴4：offsetによるページングには上限がある
/activityインターフェースのページングでoffset（オフセット）を使うと、3000件を超えると直接400エラーになる。ドキュメントには記載されていない。
上記の3つのアドレスで検証済み：GET /activity?offset=3100はHTTP 400を返し、「最大の過去活動オフセットは3000」とエラーメッセージが出る。トッププレイヤーは何万件もの取引を行っているため、3000件では全然足りない。
代わりに、endパラメータ（前ページの最後の取引のタイムスタンプ-1）を使ったカーソルページングは上限なし。
落とし穴5：ランキングの損益口径の違い
あるアドレスの損益を計算し、ランキングと比較すると、少し差が出る。
大半の場合、その差は$10以内（ポジションの時価総額のリアルタイム変動による）だが、差が大きい場合、その原因として考えられるのは：ランキングの集計ウィンドウ、キャッシュの更新遅延、または複数のproxy walletをユーザーが紐付けているケースなどだ。
実測では、キャッシュフロー法で計算した単一アドレスの損益は、lb-apiの返す値とほぼ一致している。もし差が大きい場合は、まずページングの完全性（落とし穴4）や誤ったフィールドの使用（落とし穴1-2）を確認すべきだ。
正しいやり方
さまざまな方法を試した結果、最も信頼できるのはData APIのキャッシュフロー集計だ。事前に計算されたフィールドに頼らず、原始的な取引記録から資金の流入出を直接算出する。
計算式：
損益 = SUM(売り取引) + SUM(償還) + SUM(マージ) + SUM(メーカーリベート) + SUM(報酬) - SUM(買い取引) - SUM(スプリット) + ポジションの時価総額
· TRADE BUY：USDCを使ってトークンを購入（支出）
· TRADE SELL：トークンを売ってUSDCを回収（収入）
· REDEEM：勝ったポジションのUSDC償還（収入）
· SPLIT：USDCをトークンに鋳造（支出）
· MERGE：トークンをUSDCに合併（収入）
· MAKER_REBATE：メーカーのリベート（収入）
· REWARD：報酬・エアドロップ（収入）
· データ取得：
GET /activity?user=&limit=500をendでページングし、全て取得後にタイプ別に合計。
· ポジションの時価総額：
GET /positions?user=、size×現在価格。
· クロス検証：
計算結果とPolymarketのランキングAPI（lb-api.polymarket.com/profit?window=all&address=X）を比較し、差が<$10なら合格。差はポジションの時価総額のリアルタイム変動による。
検証：ランキング上位15の実測
キャッシュフロー法で計算後、ランキングAPIとクロス検証：
swisstony：キャッシュフロー +$560.1万、ランキング +$560.1万、差 <$10
kch123：キャッシュフロー +$1139.6万、ランキング +$1139.6万、差 <$10
gmanas：キャッシュフロー +$502.4万、ランキング +$502.4万、差 <$10
これらのアドレスの誤差はすべて$10以内であり、差はポジションの時価総額のリアルタイム変動による。
この方法を使って、私は何百ものトップアドレスの実損益を分析した。これは別次元の話だ。
まとめ
SUM(cashPnl) from /positions → 不可、既に決済済みの利益を含まず、符号も逆になる可能性あり
makerPnlフィールドの合計 → 不可、オンチェーンのキャッシュフローと一致しない
txHashだけで重複除去 → 不可、$100超の取引も削除されてしまう
offsetページング＋合計 → 不可、データが切り捨てられ、3000超でエラー
Data APIのキャッシュフロー集計 → 現時点で最も信頼できる、<$10
量的分析を始める第一歩は、アルファを探すことではない。まずは自分の計算が正しいことを確認することだ。
これらはすべて実盤での失敗から得た教訓であり、理論的な推論ではない。PMのAPIは随時仕様変更される可能性があるため、定期的にランキングAPIと照合して計算結果を検証することを推奨する。