Polymarket PnLの正確な計算：なぜあなたの利益と損失の計算が間違っている可能性があるのか？

この記事を読むのに必要な時間は 14 分

Polymarket 取引量化を行う際、最初のステップは戦略を見つけることではなく、自身の収益が正しく計算されているかを確認することです。

原文タイトル：「Polymarket PnL 正確な計算：なぜあなたの利益と損失はすべて間違っている可能性があるのか」
原文著者：Leo，暗号分析家

私は Polymarket で半年間自動取引を行いましたが、最も大きな問題は戦略の失敗ではなく、自分がいくら利益を上げたかさえ正しく計算できなかったことです。

私が下手だったわけではありません。PM の PnL 計算そのものが落とし穴です。公式 API から得られる数字は間違っており、サードパーティの分析サイトに表示されるランキングも誤っています。自分でスクリプトを書いて計算しても？おそらくそれも誤っています。

逸脱はどれくらい酷いかと言うと？ランキング3位の kch123 は、間違った方法で計算すると 350 万ドルの損失となり、実際の利益は 1140 万ドルです。数パーセントのズレではなく、利益と損失の記号がまったく逆転しています。

この記事では、私が直面したすべての問題を詳しく説明しています。取引を行う人、ツールを作成する人、ランキングを見る人は、 sooner or later 直面するでしょう。

落とし穴 1：cashPnl に決済された利益が含まれていない

最も直感的な方法：/positions エンドポイントを呼び出し、cashPnl（キャッシュ利益と損失）フィールドを合計する。

上位15位のランキングから3つのアドレスを実際にテストしてみましょう：

swisstony：cashPnl を合計して +3.5 万ドル、実際のランキングでは +560 万ドル、差は 158 倍

kch123：cashPnl を合計すると -$352 万、実際のランキングでは +$1140 万、記号が逆転

gmanas：cashPnl を合計すると -$264 万、実際のランキングでは +$502 万、記号が逆転

3つのアドレスのうち、2つの利益と損失の記号が完全に逆転していました。

原因：/positions エンドポイントから返される cashPnl には、決済済みの実現された PnL が含まれていません。勝利したポジションは自動的に USDC に償還されると、そのポジションは API レスポンスから消えます。残るのは未決済のポジションであり、しばしば浮動損失が主です。

利益損失をすべて計算していると思っていましたが、実際には未決済の部分しか受け取っていませんでした。

罠 2：makerPnl フィールドとチェーン上のキャッシュフローが一致しない

取引データのJSONLにはmakerPnl（メーカー利益損失）フィールドがあり、名前からしてPnLを計算するためのものだと思われますが、信じてはいけません。

私はメーカー取引データで、SUM(makerPnl) で計算された数字がチェーン上のキャッシュフローの結果と比べて1桁違っていることを観察しました。具体的な倍数はシナリオによって異なるかもしれませんが、方向性は同じです：makerPnlの内部計算ロジックが実際のUSDC流れと一致していません。

偏差がどれほど大きくても、結論は同じです：このフィールドを使用してPnLを計算しないでください。

罠 3：txHash 単独で重複排除できない

これは最も直感に反することです。

同じtxHash（トランザクションハッシュ）が複数のレコードで表示された場合、通常の人の第一反応は重複データを削除することです。

これを行ってはいけません。PMのCLOB（チェーン上のリミットオーダーブック）では、1つのチェーン上取引で複数のメーカーオーダーをマッチングすることができ、同じtxHashの下にある複数のレコードは実際には独立したfillです。

以前、txHash + assetで重複排除を行いましたが、BUY側が$133少なく計上されました。Polygonチェーンで検証したところ、1つのトランザクションハッシュに複数の独立したUSDC転送イベントが実際に存在し、それぞれが実際の取引に対応していました。

結論：単にtxHashだけで重複排除することはできません。PnLを計算するには、直接/activityの元のデータを合計してください。

罠 4：offsetでのページネーションに制限あり

/activityエンドポイントのページネーションには、オフセット（offset）が使用されますか？3000を超えると、直接400のエラーが返されます。ドキュメントには記載されていません。

上記の3つのアドレスをすべて検証しました：GET /activity?offset=3100 はHTTP 400を返し、エラーメッセージはmax historical activity offset of 3000 exceededです。ヘビーユーザーは簡単に1万を超える取引を行いますが、3000件は全然足りません。

end パラメータを使用して（前のページの最後のタイムスタンプ - 1）、カーソルページングを行います。上限はありません。

落とし穴 5：ランキング PnL の口径の違い

あるアドレスの PnL を計算した後、ランキングと比較すると、わずかな違いがあります。

ほとんどの場合、差は $10 以内です（保有ポジションのリアルタイムの価値変動から）。しかし、差がはるかに大きい場合、原因は、ランキングの集計ウィンドウ、キャッシュの更新遅延、またはユーザーが複数のプロキシウォレットをバインドしている可能性があります。

実際のテストでは、キャッシュフロー法を使用して単一アドレスの PnL を算出した場合、lb-api の返り値と非常に一致します。結果に大きな差がある場合、まずページ送りが完全か（落とし穴 4）、誤ったフィールドが使用されていないか（落とし穴 1-2）を確認してください。

正しいアプローチ

さまざまな方法を試した後、私が検証して最も信頼できる方法は Data API のキャッシュフロー集計です。事前計算フィールドを使用せず、元の取引記録から資金の出入りを直接算出します。

式：

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + 保有ポジションの価値

・ TRADE BUY：USDC を使ってトークンを購入（支出）

・ TRADE SELL：トークンを売却して USDC を受け取る（収入）

・ REDEEM：勝ち組のポジションを USDC で償還（収入）

・ SPLIT：USDC をトークンに分割（支出）

・ MERGE：トークンを統合して USDC を受け取る（収入）

・ MAKER_REBATE：Maker リベート（収入）

・ REWARD：報酬／エアドロップ（収入）

· データソース：

GET /activity?user=<アドレス>&limit=500、end を使用してページングし、すべてのデータを取得した後、タイプごとに合計します。

· ホールディングの市場価値：

GET /positions?user=<アドレス>、size × 現在価格。

· クロスチェック：