Оригінальна назва: «Точний розрахунок 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, підрахована через SUM(makerPnl), відрізняється від результату, отриманого з урахуванням грошових потоків у блокчейні, у кілька разів. Конкретне співвідношення залежить від сценарію, але напрямок однаковий: внутрішня логіка makerPnl не співпадає з реальним рухом USDC.

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

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

Це найпротилежне інтуїції.

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

Але так робити не можна. CLOB (on-chain order book) у 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 (через коливання ринкової вартості позицій). Але якщо різниця суттєва, можливо, причина у: різних вікнах агрегації рейтингу, затримках оновлення кешу або у тому, що користувач прив’язав кілька проксі-гаманців.

У моїх тестах сума 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,6 мільйонів за грошовим потоком, +$5,6 мільйонів у рейтингу, різниця < $10

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

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

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

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

Підсумки

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