Событие закончилось, деньги еще нет: как рассчитывается Polymarket

После финального свистка кажется, что контракт на исход матча уже должен стоить ровно $1$ или $0$. Экономически исход мог стать очевиден, но технически это лишь первый из нескольких часов. Правила вопроса должны примениться к фактам, оракул должен пройти свой жизненный цикл, Conditional Tokens должны получить payout-вектор, а держатель должен погасить токены. Между этими шагами деньги могут оставаться заблокированными, хотя спор о матче в баре уже давно закрыт.

Две связанные работы Максима Нечепуренко называют это без лишней поэзии: resolution не равно settlement. Часть I реконструирует adjudication оракула и семантическое управление вопросом; часть II - финальность протокола и наблюдаемое погашение. Различие важно не только для ончейн-археологов: у маркетмейкера и арбитражера разные риски на каждом из переходов.

Событие и формальный исход - не один таймстамп

Возьмем рынок "выиграет ли команда X". Физическое событие заканчивается в момент, когда матч завершен. Но формальный исход определяется не телеведущим и не тем, что видит трейдер, а текстом правил: какой источник считается авторитетным, учитывается ли переигровка, что делать при отмене, какая версия правила была действующей. Поэтому "я знаю результат" и "контракт уже должен платить" - утверждения разной силы.

Работа Part I полезна тем, что раскладывает один расплывчатый глагол "рассчитался" на состояния: версия правила, создание request, proposal, dispute, reset, oracle finality и terminality адаптера. На зафиксированной выборке до блока Polygon 79 721 080 автор декодирует 504 332 события жизненного цикла оракула: 184 148 созданий request, 159 447 proposals, 1 604 disputes и 159 133 settlements. Эти числа описывают записи механизма, а не время, когда внешний источник впервые опубликовал факт.

Это последнее уточнение особенно важно. Медиана от request до первого proposal в legacy-маршруте составила 182 секунды, тогда как в современных маршрутах - от 176 388 до 744 151 секунд. Нельзя прочесть это как "современный оракул медленнее на три порядка": request age не является semantic resolution age, а дизайн исследования прямо не подменяет его временем появления внешнего результата. Данные аккуратно измеряют наблюдаемый жизненный цикл контрактов; они не читают мысли регулятора, спортивной лиги или редакции источника.

Оракул, спор и семантическое управление

Оракул здесь не просто кнопка "YES". Он переводит правило и свидетельство во вход, понятный контракту. Создание запроса фиксирует, что вопрос направлен на adjudication; proposal предлагает ответ; dispute открывает спор; reset может создать последующее поколение request. Из-за этого у одного человеческого вопроса возможна история нескольких попыток, а не один линейный timestamp.

В исследовании 182 671 вопрос имели хотя бы один request, а еще 1 477 были successor generations. Связка с неизменяемыми chain-идентификаторами надежна там, где она точна, но доступна не для всего: стабильные metadata удалось точно связать для 104 032 из 185 550 вопросов, то есть 56,07%; остальные не следует дорисовывать эвристикой только ради более гладкой таблицы. Такая сдержанность - хорошая инженерная привычка: неизвестное происхождение не становится известным от того, что его хочется агрегировать.

Для участника рынка это означает отдельный риск формулировки. Ставка на спортивный результат и ставка на то, как конкретная формулировка свяжет результат с источником, обычно совпадают. Когда они расходятся, ликвидность испаряется не из-за волатильности цены, а из-за неопределенности объекта цены. Держать YES на исход, который кажется очевидным, пока открыт спор, - это не денежный эквивалент держать $1 USDC.

Здесь уместна умеренная бюрократическая ирония: блокчейн умеет дать записи точный порядок, но не умеет сам решить, что именно значило "объявлен победителем" в человеческом языке. Он делает последующие действия проверяемыми. Семантику и процедуру все еще приходится задавать, наблюдать и при необходимости оспаривать.

Protocol settlement и redemption: два следующих шага

После oracle finality протоколу еще нужно записать payout для condition. В терминах Conditional Tokens Framework это отдельное событие ConditionResolution; фактическое обращение держателя за collateral видно как PayoutRedemption. Первое делает позицию погашаемой по правилам протокола, второе показывает конкретное наблюдаемое погашение. Ни одно из них само по себе не является полной оценкой всех экономических прав всех держателей.

Part II связывает 108 638 conditions между набором адаптер-вопросов и протоколом. В снимке до блока Polygon 90 114 204 (2026-07-12 17:11:41 UTC) 99 283 из них имели наблюдаемое protocol-resolution. Среди точно связанных resolved conditions у 92 158 есть redemption любой суммы, а у 91 817 - redemption с положительным payout. Медианы Kaplan-Meier от первого protocol resolution до этих двух наблюдений составили соответственно 182 и 200 секунд.

Это быстрые медианы после уже произошедшего protocol resolution, а не обещание, что любой очевидный исход превратится в деньги примерно за три минуты. В тех же данных есть 9 355 условий без наблюдаемого resolution, а правый цензурированный хвост нельзя трактовать как нулевую задержку. Кроме того, событие redemption сообщает, что кто-то погасил некоторую сумму, но без независимого знаменателя по entitlement не сообщает, какая доля всей доступной выплаты уже востребована.

Практический вывод прост: в журнале операций нужны отдельные поля event_observed_at, oracle_final_at, condition_resolved_at и redeemed_at. Склеить их в один settled_at удобно для дашборда и опасно для риска. Когда вопрос закрыт, но collateral еще не высвобожден, именно эта разница определяет доступный капитал.

Цена времени: капитал, арбитраж и границы вывода

Арбитраж между YES и NO или между площадками часто выглядит как арифметика: если комплект гарантирует $1$, а его можно собрать за $0,97, есть три цента. Но экономически это три цента минус комиссии, неполное исполнение ног, стоимость collateral, задержка resolution и вероятность, что формальная трактовка окажется не той, которую рынок уже мысленно принял. Чем дольше капитал живет в этом промежутке, тем выше требуемая доходность сделки.

Поэтому близкая к $1$ цена "выигравшего" токена до protocol settlement не обязательно ошибка. Это цена почти-денежного требования с конкретным операционным хвостом. Маркетмейкер может попросить за него скидку, потому что не может мгновенно переразместить collateral. Арбитражер может купить ее, если способен профинансировать ожидание и понимает правила. Обе стороны могут быть рациональны; один просто продает время другому.

Нужно также не смешивать этот сюжет с другим техническим слоем. Исследование Ghost-Filled Orders изучает разрыв между offchain принятием или matching ордера и его onchain расчетом: ордер может выглядеть исполненным вне цепочки, а затем не пройти onchain. Это не тот же процесс, что event resolution, oracle adjudication или payout после исхода. Работа анализирует исторический период и архитектурный класс; из нее нельзя делать утверждение о живой уязвимости конкретной текущей системы без отдельной проверки и статуса исправлений.

Хорошая модель риска поэтому рисует не одну линию "событие -> деньги", а четыре очереди: внешнее доказательство, процедура оракула, протокольная запись и действия держателя. В спокойном матче они почти сливаются, и возникает соблазн считать их одним моментом. В спорном, отмененном или просто капиталоемком рынке они становятся ценой сделки. Событие закончилось; бухгалтерия, как обычно, попросила немного времени.

Для мониторинга этого недостаточно одного среднего lag. Нужны перцентили по типу рынка, доля правого цензурирования на дату снимка, число смен поколений request и отдельный список условий с открытым спором. Тогда операционный риск виден до того, как его ошибочно запишут в "необъяснимое проскальзывание". И особенно важно хранить версию правил: смена текста вопроса после позиции - это изменение контракта, а не косметическая правка карточки.

Для сделки полезно заранее записать и условие выхода: что именно считается достаточным доказательством, на каком этапе резервируется капитал и кто имеет право вызвать redemption. Иначе backtest приписывает стратегии мгновенное освобождение средств, а реальный журнал фиксирует ожидание. В бинарном рынке такая разница особенно заметна: номинал короток и понятен, а путь к нему состоит из нескольких независимых систем, каждая из которых живет по своим часам.

Источники

• Resolution Is Not Settlement, Part I: Oracle Adjudication and Semantic Governance on Polymarket
• Resolution Is Not Settlement, Part II: Protocol Finality and Observed Redemption on Polymarket
• Ghost-Filled Orders: Detecting and Testing Atomicity Violations in Non-Custodial Prediction Markets