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

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

Es liegt nicht an meiner Unfähigkeit. Es ist, weil die PnL-Berechnung von PM selbst eine Fallgrube ist. Die offiziellen API-Zahlen, die dir angezeigt werden, sind falsch, die Rankings auf Drittanbieter-Websites ebenfalls. Du schreibst dein eigenes Skript? Wahrscheinlich auch falsch.

Wie groß ist die Abweichung? Der Drittplatzierte im Ranking, kch123, hat mit falscher Methode einen Verlust von 3,5 Mio. USD berechnet, tatsächlicher Gewinn sind 11,4 Mio. USD. Es sind keine ein paar Prozentpunkte – die Gewinn- und Verlustsymbole sind sogar umgekehrt.

In diesem Beitrag werde ich jeden Fehler, den ich gemacht habe, aufschlüsseln. Für Trader, Tool-Entwickler und Ranking-Analysten – früher oder später wird man darauf stoßen.

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

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

Praktische Tests mit den Top 15 Adressen im Ranking:

swisstony: cashPnl Summe +35.000 USD, tatsächliches Ranking +5,6 Mio. USD, Differenz um den Faktor 158

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

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

Bei diesen drei Adressen sind zwei Gewinn- und Verlustsymbole direkt vertauscht.

Ursache: Die /positions-API gibt das cashPnl nicht für bereits geschlossene/ eingelöste Positionen zurück. Wenn eine Gewinnposition automatisch in USDC eingelöst 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), der Name deutet an, dass es für die PnL-Berechnung gedacht ist. Aber glaub nicht daran.

Ich habe beobachtet, dass die Summe von makerPnl in den Marktdaten um eine Größenordnung von den tatsächlichen on-chain Cashflows abweicht. 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 – das Fazit bleibt: Dieses Feld nicht für die PnL-Berechnung verwenden.

Fehler 3: Nicht nur nach txHash deduplizieren

Das ist das Gegenteil der Intuition.

Wenn eine txHash (Transaktions-Hash) mehrere Einträge hat, denkt man: Das sind doppelte Daten, man sollte sie entfernen.

Aber so funktioniert es 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, unabhängige Fills.

Ich habe früher nach txHash + Asset dedupliziert, dabei wurden auf der Polygon-Chain 133 USD an Trades nicht mitgezählt. Bei der Überprüfung auf Polygon gibt es tatsächlich mehrere unabhängige USDC-Transfer-Events pro txHash, jeder entspricht einem echten Trade.

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

Fehler 4: Offset-Seitenbegrenzung bei Paginierung

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

Alle drei Adressen wurden überprüft: GET /activity?offset=3100 liefert HTTP 400, die Fehlermeldung lautet „max historical activity offset of 3000 exceeded“. Top-User haben oft Zehntausende Transaktionen, 3000 sind viel zu wenig.

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

Fehler 5: Unterschiede im PnL-Ranking-Standard

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

In den meisten Fällen sind es weniger als 10 USD (durch Schwankungen im Marktwert der Positionen). Aber wenn die Differenz deutlich größer ist, könnten Gründe sein: Das Ranking nutzt unterschiedliche Zeitfenster, Cache-Refresh-Verzögerungen oder der Nutzer hat mehrere Proxy-Wallets verbunden.

In meinen Tests stimmt die PnL, die ich mit der Bargeldfluss-Methode berechnet habe, sehr genau mit den lb-api-Antworten überein. Wenn die Abweichung groß ist, 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 Ansätzen habe ich die zuverlässigste Methode verifiziert: die Bargeldfluss-Zusammenfassung via Data API. Ohne Vorberechnungen, direkt aus den Rohdaten der Transaktionen den Geldfluss ermitteln.

Formel:

PnL = SUM(Trades mit side=SELL) + SUM(Redeem) + SUM(Merge) + SUM(Maker_Rebate) + SUM(Reward) - SUM(Trades mit side=BUY) - SUM(Split) + Positionswert

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

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

· Redeem: Gewinn-Position in USDC einlösen (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=