Polymarket PnL точный расчет: почему ваша прибыль и убытки могут быть неправильными?

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

Автор оригинала: BlockBeats

Источник оригинала:

Репост: Mars Finance

Я занимаюсь автоматизированной торговлей на 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 по данным маркетмейкера отличается от результатов по цепочке USDC примерно в один порядок. Точный множитель зависит от сценария, но направление — одинаковое: внутренняя логика makerPnl не совпадает с реальными потоками USDC.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На практике, при использовании метода по денежным потокам, результаты по одному адресу совпадают с API lb-api.polymarket.com/profit?window=all&address=X — разница менее 10 долларов. Если есть большие расхождения — проверьте, правильно ли вы сделали пагинацию (ошибка 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=&limit=500, пагинация по end, собирайте все и суммируйте по типам.

· Рыночная стоимость позиции:

GET /positions?user=, размер × текущая цена.

· Верификация:

сравните полученные результаты с API рейтинга Polymarket (lb-api.polymarket.com/profit?window=all&address=X), разница менее 10 долларов — считается правильным. Разница обусловлена колебаниями стоимости позиций.

Проверка: топ-15 адресов

После подсчёта по денежным потокам и сравнения с API рейтинга:

swisstony: +$5,601,000, разница < $10

kch123: +$11,396,000, разница < $10

gmanas: +$5,024,000, разница < $10

Все три адреса показывают расхождения менее 10 долларов, что обусловлено колебаниями стоимости позиций.

Когда метод проверен, я использовал его для анализа сотен топовых адресов — и результаты оказались совсем другими.

Итог

SUM(cashPnl) из /positions — не подходит, не включает реализованный PnL, знак может быть перепутан

Суммирование по полю makerPnl — не подходит, не совпадает с цепочными потоками

Подсчёт по дублирующим txHash — не подходит, убирает реальные сделки

Пагинация с offset + суммирование — не подходит, данные обрезаются, при >3000 — ошибка

Метод по денежным потокам через Data API — самый надёжный, разница менее 10 долларов

Первый шаг для квантовика — не искать альфу. А убедиться, что ваши расчёты правильные.

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