Оригинальный заголовок: «Точное вычисление PnL на Polymarket: почему ваши расчёты могут быть полностью ошибочными»
Автор оригинала: Лео, аналитик в области криптовалют
Я занимаюсь автоматической торговлей на 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 долларов на стороне покупки. Проверка на Polygon показала, что в одной транзакции действительно есть несколько отдельных USDC Transfer событий, каждое — реальная сделка.
Вывод: нельзя удалять дубли по txHash. Для подсчёта PnL нужно просто суммировать исходные данные /activity.
Ошибка 4: лимит по offset при пагинации
При использовании API /activity для пагинации через offset — при превышении 3000 записей выдаёт ошибку 400. В документации об этом не написано.
Все три проверенных адреса подтвердили: запрос GET /activity?offset=3100 возвращает HTTP 400 с сообщением «максимальный смежный offset — 3000». У крупных игроков бывает десятки тысяч сделок, 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=
&limit=500, пагинация по end, после получения всех данных — суммировать по типам.
· Рыночная стоимость позиции:
GET /positions?user=
, size × текущая цена.
· Верификация:
Сравнить полученный результат с API рейтинга Polymarket (lb-api.polymarket.com/profit?window=all&address=X). Разница менее 10 долларов — считается точным. Разница обусловлена колебаниями стоимости активов.
Проверка: тест на топ-15 адресах
После подсчёта по cash flow, сверка с API рейтинга:
swisstony: +$5,601,000 по методу cash flow, +$5,601,000 в рейтинге, разница < $10
kch123: +$11,396,000 по методу cash flow, +$11,396,000 в рейтинге, разница < $10
gmanas: +$5,024,000 по методу cash flow, +$5,024,000 в рейтинге, разница < $10
Все три адреса показывают расхождения менее 10 долларов, что обусловлено колебаниями стоимости активов.
После того, как метод проверен, я использовал его для анализа сотен топовых адресов — и результаты оказались совсем другими.
Итог
SUM(cashPnl) из /positions — не подходит, не учитывает реализованную прибыль, знак может быть перепутан.
Суммирование по полю makerPnl — не подходит, не совпадает с денежными потоками на блокчейне.
Подсчёт по удалённым дубли по txHash — не подходит, пропускает реальные исполнения, если их несколько.
Пагинация с offset + суммирование — не подходит, данные обрезаются, при более 3000 — ошибка.
Метод через Data API по денежным потокам — самый надёжный на данный момент, погрешность менее 10 долларов.
Первый шаг в квантовых расчетах — не искать альфу. А убедиться, что ваши подсчёты правильные.
Все вышеописанные ошибки — из реальной практики, а не теоретические рассуждения. API Polymarket может менять поведение в любой момент, поэтому рекомендуется регулярно сверять результаты с API рейтинга.
Ссылка на оригинал
Кликните, чтобы узнать о вакансиях в BlockBeats
Присоединяйтесь к официальному сообществу BlockBeats:
Telegram-канал: https://t.me/theblockbeats
Telegram-группа: https://t.me/BlockBeats_App
Официальный аккаунт в Twitter: https://twitter.com/BlockBeatsAsia
Отказ от ответственности: Информация на этой странице может поступать от третьих лиц и не отражает взгляды или мнения Gate. Содержание, представленное на этой странице, предназначено исключительно для справки и не является финансовой, инвестиционной или юридической консультацией. Gate не гарантирует точность или полноту информации и не несет ответственности за любые убытки, возникшие от использования этой информации. Инвестиции в виртуальные активы несут высокие риски и подвержены значительной ценовой волатильности. Вы можете потерять весь инвестированный капитал. Пожалуйста, полностью понимайте соответствующие риски и принимайте разумные решения, исходя из собственного финансового положения и толерантности к риску. Для получения подробностей, пожалуйста, обратитесь к
Отказу от ответственности.
