Originaltitel: „Polymarket PnL Präzise Berechnung: Warum deine Gewinn- und Verlustrechnung möglicherweise komplett falsch ist“
Originalautor: Leo, Krypto-Analyst

Ich habe ein halbes Jahr lang automatisierten Handel bei Polymarket selbst entwickelt, der größte Fehler war nicht eine Strategie, die versagt, sondern dass ich nicht einmal richtig berechnen konnte, wie viel ich tatsächlich verdient habe.

Ich bin nicht schlecht. Das Problem liegt darin, dass die PnL-Berechnung von PM selbst eine Fallgrube ist. Die offiziellen API-Daten, die du bekommst, sind falsch, die Rankings auf Drittanbieter-Websites ebenfalls. Du schreibst dein eigenes Skript? Wahrscheinlich auch falsch.

Wie groß ist die Abweichung? Der Platz 3 im Ranking, kch123, hat mit einer falschen Methode einen Verlust von 3,5 Mio. USD berechnet, tatsächlicher Gewinn sind 11,4 Mio. USD. Es ist nicht nur ein paar Prozentpunkte Unterschied — die Gewinn- und Verlustsymbole sind sogar vertauscht.

In diesem Beitrag werde ich jeden Fehler, den ich gemacht habe, im Detail erklären. Für Trader, Tool-Entwickler und Ranking-Analysten – früher oder später wirst du auf diese Fallstricke stoßen.

Fehler 1: cashPnl schließt nicht den bereits realisierten Gewinn/Verlust ein

Der naheliegendste Ansatz: Die /positions-API aufrufen, alle cashPnl (Bargeld-Gewinn/-Verlust) Felder summieren.

Praktische Tests mit den Top 3 Adressen im Ranking:

swisstony: Summe cashPnl +$35.000, tatsächliches Ranking +$5,6 Mio., Differenz 158-fach

kch123: Summe cashPnl -$3,52 Mio., tatsächliches Ranking +$11,4 Mio., Vorzeichen vertauscht

gmanas: Summe cashPnl -$2,64 Mio., tatsächliches Ranking +$5,02 Mio., Vorzeichen vertauscht

Bei diesen drei Adressen sind die Gewinn- und Verlustsymbole in zwei Fällen direkt vertauscht.

Ursache: Die cashPnl, die die /positions-API zurückgibt, enthält nicht die bereits geschlossenen/ eingelösten realisierten PnL. Wenn eine Gewinnposition automatisch in USDC ausgezahlt wird, verschwindet diese Position aus der API-Antwort. Es verbleiben nur noch offene Positionen – meist mit unrealisiertem Verlust.

Du denkst, du berechnest den gesamten Gewinn/Verlust, aber in Wirklichkeit hast du nur den noch offenen Teil erfasst.

Fehler 2: Das Feld makerPnl stimmt nicht mit den on-chain Cashflows überein

In den JSONL-Handelsdaten gibt es ein Feld makerPnl (Market Maker Gewinn/Verlust), das nach dem Namen für die PnL-Berechnung gedacht ist. Glaub nicht daran.

Ich habe in den Market-Making-Daten beobachtet, dass die Summe von makerPnl deutlich von den auf der Chain erfassten Cashflows abweicht – um eine Größenordnung. Die genaue Differenz hängt vom Szenario ab, aber die Richtung ist immer gleich: Die interne Logik von makerPnl stimmt nicht mit den tatsächlichen USDC-Flows überein.

Egal wie groß die Abweichung ist: Verwende dieses Feld nicht zur PnL-Berechnung.

Fehler 3: Nicht nur anhand von txHash deduplizieren

Das ist das unlogischste.

Wenn eine txHash (Transaktions-Hash) mehrfach vorkommt, denkt man: Das sind doppelte Daten, entfernen.

Das funktioniert nicht. Das CLOB (On-Chain-Limit-Orderbuch) bei PM kann in einer Transaktion mehrere Maker-Orders ausführen. Mehrere Einträge mit demselben txHash sind echte, separate Fills.

Ich habe früher nach txHash + Asset dedupliziert, dabei wurden auf der BUY-Seite 133 USD zu wenig berechnet. Auf Polygon habe ich bestätigt, dass eine Transaktion tatsächlich mehrere unabhängige USDC-Transfer-Events enthält, die jeweils eine echte Transaktion darstellen.

Fazit: Nicht nur nach txHash deduplizieren. Für die PnL-Berechnung direkt die Rohdaten aus /activity summieren.

Fehler 4: Offset-Seitenbegrenzung bei Paginierung

Bei der Paginierung der /activity-API mit offset? Überschreitet man 3000 Einträge, gibt es direkt einen 400-Fehler. Das steht nicht in der Dokumentation.

Alle drei oben genannten Adressen haben das bestätigt: GET /activity?offset=3100 liefert HTTP 400, die Fehlermeldung lautet „max historical activity offset of 3000 exceeded“. Top-User haben oft Zehntausende Transaktionen, 3000 Zeilen reichen nicht aus.

Mit dem end-Parameter (letzte Zeile minus 1) als Cursor gibt es kein Limit.

Fehler 5: Unterschiede im PnL-Ranking-Definitionen

Wenn du das PnL einer Adresse berechnest und es mit dem Ranking vergleichst, gibt es manchmal Abweichungen.

Meistens sind es weniger als 10 USD (durch Schwankungen im Marktwert der Positionen). Bei größeren Differenzen könnten Gründe sein: Das Ranking nutzt andere Zeitfenster, Cache-Refresh-Delay oder der Nutzer hat mehrere Proxy-Wallets verbunden.

In meinen Tests stimmt die PnL, die mit der Bargeldfluss-Methode berechnet wurde, sehr genau mit den lb-api-Daten überein. Wenn deine Ergebnisse stark abweichen, prüfe zuerst, ob das Paginieren vollständig ist (Fehler 4) und ob du die richtigen Felder benutzt hast (Fehler 1-2).

Korrekte Vorgehensweise

Nach verschiedenen Versuchen habe ich die zuverlässigste Methode bestätigt: die Summierung der Cashflows über die Data API. Ohne Vorberechnete Felder, direkt aus den Rohdaten der Transaktionen.

Formel:

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + Positionswert

· TRADE BUY: USDC ausgeben, um Token zu kaufen (Ausgabe)

· TRADE SELL: Token verkaufen, USDC zurückerhalten (Einnahme)

· REDEEM: Gewinn-Position in USDC umwandeln (Einnahme)

· SPLIT: USDC in Token umwandeln (Ausgabe)

· MERGE: Token in USDC umwandeln (Einnahme)

· MAKER_REBATE: Maker-Rückvergütung (Einnahme)

· REWARD: Belohnungen / Airdrops (Einnahme)

· Datenquelle:

GET /activity?user=