Polymarket PnL точний розрахунок: чому ваш облік прибутків і збитків може бути неправильним?

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

Автор оригіналу:律動BlockBeats

Джерело оригіналу:

Перепублікація: Mars Finance

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

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

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

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

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

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

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

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

kch123: сума cashPnl -$352 тисячі, реальний рейтинг +$1,14 мільйона, знак змінено

gmanas: сума cashPnl -$264 тисячі, реальний рейтинг +$502 тисячі, знак змінено

У трьох адресах два випадки, коли знаки прибутку/збитку напряму протилежні.

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

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

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

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

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

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

Помилка 3: не можна просто по txHash робити унікалізацію

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

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

Але так робити не можна. У CLOB (on-chain order book) Polymarket у одній транзакції може бути кілька маркетмейкерських ордерів, і кілька записів з одним 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.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: +$560,1 тисячі, рейтинг +$560,1 тисячі, різниця <$10

kch123: +$1 139,6 тисячі, рейтинг +$1 139,6 тисячі, різниця <$10

gmanas: +$502,4 тисячі, рейтинг +$502,4 тисячі, різниця <$10

Різниця у всіх випадках менше $10, і вона зумовлена коливаннями ринкової вартості.

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

Підсумки

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

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

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

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

Data API за грошовим потоком → найнадійніше, різниця <$10

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

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