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

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

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

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

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

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

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

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

swisstony: сумма cashPnl +$3,5 тыс., реальный рейтинг +$560 тыс., разница в 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 (On-chain order book) Polymarket в одной транзакции может быть несколько сделок маркетмейкера, и все эти записи с одним txHash — реальные отдельные исполнения.

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

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

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

При использовании offset в API /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 с точностью до <$10. Разница — из-за текущих колебаний стоимости позиций.

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

После подсчёта по методу cash flow — сравнение с API рейтинга:

swisstony: +$560,1 тыс. (cash flow) и +$560,1 тыс. (рейтинг), разница < $10

kch123: +$1 139,6 тыс. и +$1 139,6 тыс., разница < $10

gmanas: +$502,4 тыс. и +$502,4 тыс., разница < $10

Все три адреса — погрешность менее $10, разница вызвана колебаниями стоимости позиций.

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

Общий вывод

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

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

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

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

Метод cash flow через Data API — самый надёжный на данный момент, с погрешностью <$10.

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

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

Ссылка на оригинал

Нажмите, чтобы узнать о вакансиях в BlockBeats

Присоединяйтесь к официальному сообществу BlockBeats:

Телеграм-канал подписки: https://t.me/theblockbeats

Телеграм-чат: https://t.me/BlockBeats_App

Официальный аккаунт в Твиттере: https://twitter.com/BlockBeatsAsia