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. Das Problem ist, dass 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. Wenn du dein eigenes Skript schreibst? 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 ist nicht nur ein paar Prozentpunkte Unterschied — die Gewinn- und Verlustsymbole sind komplett vertauscht.

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

Fehler 1: cashPnl schließt bereits realisierte Gewinne/Verluste nicht ein

Der naheliegendste Ansatz: Die /positions-API aufrufen, alle cashPnl-Felder summieren.

Mit den Top 15 Adressen im Ranking getestet:

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

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

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

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

Ursache: Die /positions-API gibt das cashPnl-Feld für bereits geschlossene oder eingelöste Positionen nicht aus. Gewinne aus gewinnbringenden Positionen werden automatisch in USDC eingelöst, dann verschwindet diese Position aus der API-Antwort. Es verbleiben nur noch offene Positionen — meist mit unrealisierten Verlusten.

Du denkst, du berechnest alle Gewinne und Verluste, aber in Wirklichkeit hast du nur den offenen Teil erfasst.

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

In den JSONL-Daten der Trades 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 in den Market-Maker-Daten beobachtet, dass die Summe von makerPnl 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: Verwende dieses Feld nicht zur PnL-Berechnung.

Fehler 3: Nicht nur nach txHash deduplizieren

Das ist das unlogischste.

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

Das darf man nicht so machen. Das CLOB (On-Chain-Limit-Orderbook) bei Polymarket kann in einer einzigen 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 habe ich auf der Polygon-Chain 133 USD zu wenig berechnet. Bei der Überprüfung auf Polygon gibt es tatsächlich mehrere unabhängige USDC-Transfer-Events pro txHash, jedes entspricht einem echten Trade.

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 /activity-API mit offset (Versatz) zu paginieren? Bei mehr als 3000 Einträgen gibt es sofort einen 400-Fehler. Das steht nicht in der Dokumentation.

Alle drei Adressen wurden getestet: 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-Definitionen

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

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 folgende Gründe vorliegen: Das Ranking nutzt unterschiedliche Aggregationsfenster, es gibt Cache-Verzögerungen oder der Nutzer hat mehrere Proxy-Wallets verbunden.

In meinen Tests stimmt die PnL, die ich mit der Cashflow-Methode berechnet habe, fast exakt mit den lb-api-Daten überein. Wenn deine Ergebnisse stark abweichen, überprüfe zuerst, ob das Paging vollständig ist (Fehler 4) und ob du die richtigen Felder benutzt hast (Fehler 1-2).

Richtige Vorgehensweise

Nach verschiedenen Versuchen habe ich die zuverlässigste Methode bestätigt: die Cashflow-Zusammenfassung via Data API. Ohne Vorberechnungen, direkt aus den Rohdaten der Trades die Ein- und Auszahlungen berechnen.

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: Gewinnbringende 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=