Оригинальный заголовок: «Точное вычисление PnL на Polymarket: почему ваши расчёты могут быть полностью ошибочными»
Автор оригинала: Leo, аналитик по криптовалютам

Я полгода занимаюсь автоматической торговлей на Polymarket, и самая большая ошибка, которую я совершил, — это не сбой стратегии, а то, что я неправильно посчитал, сколько именно заработал или потерял.

Это не из-за моей некомпетентности. Само вычисление PnL в PM — это минное поле. Официальный API даёт неверные цифры, сторонние аналитические сайты показывают неправильные рейтинги. Вы пишете скрипт для подсчёта? Скорее всего, тоже ошибаетесь.

Насколько сильно отклонения? Третье место в рейтинге, kch123, по ошибочной методике посчитал убыток в 3,5 миллиона долларов, а фактическая прибыль — 11,4 миллиона долларов. Не на несколько процентов — даже знак прибыли и убытка перепутан.

В этой статье я подробно разберу каждую ошибку, которую я совершил. Трейдерам, разработчикам инструментов, следящим за рейтингами — рано или поздно столкнутся.

Ошибка 1: cashPnl не включает уже закрытую прибыль

Самый очевидный способ: взять API /positions, просуммировать поле cashPnl (наличные прибыль и убытки).

На практике проверил на трёх адресах из топ-15:

swisstony: сумма cashPnl +$35 000, реальный рейтинг +$5,6 миллиона, разница в 158 раз

kch123: сумма cashPnl —$3,52 миллиона, реальный рейтинг +$11,4 миллиона, знак перепутан

gmanas: сумма cashPnl —$2,64 миллиона, реальный рейтинг +$5,02 миллиона, знак перепутан

Три адреса, два случая, когда знак прибыли и убытка просто перепутан.

Причина: API /positions возвращает cashPnl без учёта уже закрытых/выкупленных реализованных PnL. Если выигравшая позиция автоматически выкупается в USDC, эта позиция исчезает из ответа API. Остаются только незакрытые позиции — зачастую с нереализованным убытком.

Вы думаете, что считаете всю прибыль и убыток, а на самом деле — только незакрытую часть.

Ошибка 2: поле makerPnl не совпадает с денежными потоками на блокчейне

В JSONL с данными о сделках есть поле makerPnl (прибыль/убыток маркетмейкера), по названию — для подсчёта PnL. Не верьте.

Я заметил, что сумма makerPnl по сценарию не совпадает с результатом по денежным потокам на блокчейне — разница в порядке величины. Конкретное соотношение зависит от ситуации, но направление одинаковое: внутренняя логика makerPnl не совпадает с реальным движением USDC.

Независимо от размера отклонения, вывод один: не используйте это поле для подсчёта PnL.

Ошибка 3: нельзя считать по txHash, удаляя дубли

Это самое противоинтуитивное.

Один и тот же txHash (хеш транзакции) может встречаться несколько раз. Обычно реакция — дубли, их нужно удалять.

Но так делать нельзя. В CLOB Polymarket (ончейн-ордербук) в одной транзакции могут совпадать несколько ордеров маркетмейкеров, и все эти записи с одним txHash — реальные отдельные исполнения.

Ранее я удалял дубли по txHash + активу, из-за этого недосчитался $133 на стороне BUY. Проверка на Polygon показала, что в одной транзакции действительно есть несколько отдельных USDC Transfer событий, каждое — реальная сделка.

Вывод: нельзя удалять дубли только по txHash. Для подсчёта PnL нужно просто суммировать исходные данные /activity.

Ошибка 4: лимит по offset при пагинации

При использовании offset для пагинации в /activity — при превышении 3000 записей выдаёт ошибку 400. В документации об этом не написано.

Все три проверенных адреса подтвердили: запрос GET /activity?offset=3100 возвращает HTTP 400, сообщение — max historical activity offset of 3000 exceeded. У крупных игроков бывает десятки тысяч транзакций, 3000 — недостаточно.

Использование параметра end (указание времени последней записи предыдущей страницы минус 1) в качестве курсора — без лимита.

Ошибка 5: различия в методиках подсчёта PnL в рейтинге

После подсчёта PnL для одного адреса и сравнения с рейтингом — есть расхождения.

В большинстве случаев разница — менее $10 (из-за колебаний стоимости позиций). Но если разница заметно больше, возможные причины: разные окна агрегации в рейтинге, задержки обновления кеша или привязка нескольких прокси-кошельков к одному аккаунту.

На практике, результаты по cash flow очень совпадают с API lb-api.polymarket.com/profit?window=all&address=X. Если есть существенные расхождения — сначала проверьте полноту пагинации (ошибка 4), правильность используемых полей (ошибки 1-2).

Правильный подход

После экспериментов я пришёл к выводу, что самый надёжный способ — использовать Data API для суммирования по денежным потокам. Не нужны предварительные вычисления — просто считаем входящие и исходящие средства по исходным транзакциям.

Формула:

PnL = SUM(TRADE, где side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE, где side=BUY) - SUM(SPLIT) + рыночная стоимость позиций

· TRADE BUY: покупка токена за USDC (расход)

· TRADE SELL: продажа токена и возврат USDC (доход)

· REDEEM: выкуп выигранной позиции за USDC (доход)

· SPLIT: создание токена из USDC (расход)

· MERGE: объединение токенов обратно в USDC (доход)

· MAKER_REBATE: вознаграждение маркетмейкера (доход)

· REWARD: награды/аирдропы (доход)

· Источник данных:

GET /activity?user=