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

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

Це не через мою некомпетентність. Сам розрахунок PnL у PM — це мінне поле. Офіційний API дає неправильні цифри, сторонні аналітичні сайти показують неправильний рейтинг. Ви пишете скрипт для підрахунку? Велика ймовірність, що теж помилитеся.

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

У цій статті я розберу кожну помилку, яку я зробив. Торгівці, розробники інструментів, ті, хто дивиться на рейтинги — рано чи пізно з цим стикнуться.

Помилка 1: cashPnl не враховує вже закриті прибутки і збитки

Найінтуїтивніший спосіб: викликати /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 + asset, і через це недорахував $133 на BUY-стороні. Перевірка на Polygon показала, що у кожній транзакції справді є кілька окремих USDC Transfer подій, кожна з яких відповідає реальній угоді.

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

Помилка 4: пагінація за offset має обмеження

Пагінація у /activity — через offset? Якщо більше 3000 записів — помилка 400. У документації про це не написано.

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

Замість цього можна використовувати параметр end (час останньої транзакції попередньої сторінки - 1), і тоді обмежень немає.

Помилка 5: різниця у підрахунках PnL у рейтингах

Після підрахунку PnL для однієї адреси і порівняння з рейтингом — різниця.

У більшості випадків різниця — до $10 (через коливання ринкової вартості позицій). Але якщо різниця суттєва, можливо, причина у: різних вікнах агрегації у рейтингу, затримках оновлення кешу або прив’язаних кількох проксі-гаманцях користувачів.

У тестах сума, порахована за методом грошового потоку, збігається з результатом lb-api. Якщо різниця велика — перевірте, чи повністю пройшли пагінацію (пункт 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 × currentPrice.

· Перевірка:

Порівнюєте результати з API рейтингу Polymarket (lb-api.polymarket.com/profit?window=all&address=X), різниця — <$10. Різниця — через коливання ринкової вартості.

Перевірка: топ-15 у реальних даних

Після підрахунку за методом грошового потоку — порівнюємо з API рейтингу:

swisstony: +$5,6 мільйонів за методом грошового потоку, +$5,6 мільйонів у рейтингу, різниця < $10

kch123: +$11,4 мільйонів за методом грошового потоку, +$11,4 мільйонів у рейтингу, різниця < $10

gmanas: +$5,02 мільйонів за методом грошового потоку, +$5,02 мільйонів у рейтингу, різниця < $10

Усі три адреси мають різницю у <$10, що зумовлено коливаннями ринкової вартості.

Після запуску цього методу я проаналізував сотні топових адрес і їх реальний PnL — це вже інша історія.

Загальні висновки

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

Сума поля makerPnl — не підходить, не співпадає з потоком грошових коштів у блокчейні.

Обчислення за унікальним txHash — не підходить, понад $100 — реальні виконання втрачаються.

Пагінація за offset + підрахунок — не підходить, дані обмежені, >3000 — помилка.

Метод грошового потоку через Data API — найнадійніший наразі, <$10.

Перший крок у квантовій торгівлі — не шукати альфу. Спершу переконайтеся, що ви рахуєте правильно.

Все вище — це реальні помилки, допущені у реальній практиці, а не теорія. API PM може змінювати поведінку будь-коли, тому рекомендується регулярно перевіряти свої розрахунки через API рейтингу.

Посилання на оригінал

Дізнайтеся про вакансії у BlockBeats

Запрошуємо приєднатися до офіційної спільноти BlockBeats:

Telegram-канал: https://t.me/theblockbeats

Telegram-група: https://t.me/BlockBeats_App

Офіційний акаунт у Twitter: https://twitter.com/BlockBeatsAsia