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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я спостерігав у даних маркетмейкерів, що сума SUM(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=