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

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

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

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

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

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

Найінтуїтивніший спосіб: викликати /positions, підсумувати поле cashPnl (грошовий прибуток/збиток).

На прикладі трьох адрес із топ-15:

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

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

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

Три адреси, у двох випадках знаки прибутку і збитку просто протилежні.

Причина: API /positions повертає cashPnl без врахування вже закритих або викуплених реалізованих PnL. Виграшні позиції автоматично викуповуються у USDC, і ця позиція зникає з відповіді API. Залишаються незакриті позиції — зазвичай з浮亏.

Ви думаєте, що рахуєте весь прибуток і збиток, але насправді враховуєте лише незакриті частини.

Помилка 2: поле makerPnl і реальні грошові потоки у блокчейні не співпадають

У JSONL з даними торгів є поле makerPnl (прибуток/збиток маркетмейкера), назва якого натякає, що воно для розрахунку PnL. Не вірте.

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

Незалежно від розміру похибки, висновок один: не використовуйте це поле для розрахунку PnL.

Помилка 3: не можна просто по txHash видаляти дублікати

Це найінтуїтивніше.

Якщо один і той самий txHash (хеш транзакції) з’являється кілька разів, перша думка — дублікати, потрібно видалити.

Але так робити не можна. У CLOB (on-chain order book) Polymarket у одній транзакції може бути кілька ордерів маркетмейкера, і кожен з них — реальне заповнення (fill). Тому кілька записів з одним txHash — це не дублікати, а окремі реальні операції.

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

У тестах сума PnL, порахована грошовим потоком, дуже близька до значення API 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 × поточна ціна.

· Перевірка:

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

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

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

swisstony: +$5 601 000 (грошовий потік) і +$5 601 000 (рейтинг), різниця < $10

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

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

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

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

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

SUM(cashPnl) з /positions — не підходить, не враховує вже закриті прибутки, може мати протилежний знак.
Сума makerPnl — не підходить, не співпадає з грошовими потоками.
Обчислення за унікальним txHash — не підходить, пропускає реальні заповнення.
Пагінація за 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