Polymarket – рынок прогнозов, где участники покупают и продают токены, соответствующие исходам реальных событий. Цена доли находится между нулём и единицей и может читаться как рыночная оценка вероятности, но это не статистический прогноз и не гарантия результата. Она отражает текущий баланс заявок, доступную ликвидность, правила конкретного рынка и ограничения участников.
Технически Polymarket соединяет токенизацию исходов на Polygon, гибридную книгу заявок и механизм разрешения споров через UMA. В апреле 2026 года торговая инфраструктура перешла на CLOB V2 и pUSD. Поэтому старые описания с USDC.e, прежними контрактами и клиентами V1 уже не соответствуют production.
Что представляет собой рынок прогнозов
Обычный бинарный рынок задаёт проверяемый вопрос и два исхода – Yes и No. Полный комплект из двух токенов обеспечен одной единицей залога. После разрешения победивший токен погашается по единице залога, проигравший – по нулю. Пока событие не завершено, обе стороны свободно торгуются.
Если Yes покупают по 0,63 pUSD, рынок условно показывает вероятность около 63%. Это удобная интерпретация, но не объективная частота. Крупная заявка способна сдвинуть тонкий рынок, участники могут иметь одинаковые источники информации, а географические ограничения меняют состав трейдеров.
Event и market – разные сущности. Одно событие может объединять несколько бинарных вопросов. Например, набор вариантов победителя представлен отдельными рынками, каждый со своими Yes и No. Это важно для понимания Negative Risk, где взаимно исключающие исходы связываются экономически.
CTF и токены исходов
Outcome tokens выпускаются по стандарту ERC1155 через Conditional Tokens Framework, первоначально разработанный в экосистеме Gnosis. У каждого рынка есть condition ID, question ID и два token ID. Баланс пользователя хранится on-chain, а не в закрытой базе биржи.
Операция split блокирует единицу pUSD и создаёт полный комплект Yes плюс No. Merge уничтожает равное количество обоих исходов и возвращает залог. После финального ответа redeem сжигает выигравшие токены и выдаёт соответствующую долю collateral. Именно эта обратимость удерживает сумму цен близко к единице, когда арбитраж экономически оправдан.
Полное обеспечение не устраняет рыночный риск. Пользователь, купивший один исход, не владеет отдельным долларом в сейфе. Он держит условный ERC1155 asset, стоимость которого зависит от ответа oracle и исправности контрактов CTF, адаптеров и collateral.
pUSD и переход с USDC.e
В CLOB V2 залогом служит Polymarket USD, или pUSD. Это ERC20 token в Polygon, обеспеченный USDC через on-chain механизм. Интерфейс может автоматически выполнять обёртывание и обратную операцию, но технически pUSD не следует путать с нативным USDC или старым bridged USDC.e.
До обновления основной системой был CLOB V1 и USDC.e. 28 апреля 2026 года production перешёл на новые exchange contracts, новую backend architecture и pUSD. Старые SDK и подписи V1 перестали поддерживаться, а незакрытые старые заявки не переносились. Текущую интеграцию нужно проверять по контрактам V2, а не по гайдам прошлых лет.
Обеспечение pUSD снижает трение внутри торговой системы, но добавляет ещё один контрактный слой. Риск включает reserve asset, wrapper, права администрирования, Polygon и корректность адаптеров между залогом и CTF.
Как устроен CLOB
Polymarket использует central limit order book с гибридной архитектурой. Заявки подписываются пользователями и хранятся и сопоставляются off-chain. Когда встречаются совместимые цены, exchange contract атомарно проводит расчёт on-chain. Это быстрее и дешевле, чем записывать каждую отмену и перестановку заявки в блокчейн.
Ордер подписывается по EIP-712 и задаёт токен, сторону, цену, объём и служебные параметры. Matching operator не получает право произвольно списать активы или изменить подписанную цену. Однако он управляет доступностью книги, последовательностью обработки и публикацией совпавших заявок. Поэтому non-custodial settlement не означает полностью децентрализованное исполнение.
Limit order добавляет ликвидность, если не исполняется сразу. Marketable order забирает лучшие доступные уровни. Интерфейс может показывать одну ожидаемую цену, но крупный объём проходит по нескольким уровням и получает среднюю цену хуже верхней котировки. В тонких рынках spread и price impact важнее номинальной вероятности.
Что изменил CLOB V2
V2 переписал exchange contracts и backend components, включая order manager, ledger, executor и balance checks. В структуре заявки timestamp заменил прежний nonce, а параметры комиссии больше не подписываются самим пользователем – протокол применяет конфигурацию рынка в момент match. Builder code связывает поток с конкретной интеграцией.
Production endpoint сохранился, но пакеты SDK изменились и обратной совместимости с V1 нет. Для обычного пользователя миграция в основном скрыта интерфейсом. Для bot, market maker или разработчика это принципиальное обновление схемы подписи, domain version, collateral и адресов exchange.
Аудит V2 снижает вероятность известных ошибок, но не доказывает отсутствие уязвимостей. Кроме exchange остаются CTF, Neg Risk Adapter, UMA integration, pUSD и relayer. Безопасность всей позиции определяется цепочкой, а не одним отчётом.
Negative Risk
В multi-outcome event отдельные бинарные рынки могут описывать взаимоисключающие варианты. Если победить способен только один кандидат, покупка No на один вариант экономически связана с набором Yes на остальные. Negative Risk Adapter позволяет конвертировать позиции и использовать это соотношение для более эффективной ликвидности.
Механизм полезен для арбитража между всеми исходами, но требует корректно сформированного набора. Категория «другое», возможность нескольких победителей или неодинаковые правила разрушат предпосылку взаимной исключительности. Поэтому флаг negRisk – не декоративное свойство интерфейса, а отдельная схема расчёта и отдельный exchange contract.
Разрешение рынка через UMA
У каждого рынка заранее опубликованы resolution rules: формулировка вопроса, дата, указанный источник результата и порядок обработки спорных случаев. Заголовок служит кратким описанием, но юридически и экономически значима полная формулировка. Если бытовое понимание события расходится с правилами, oracle должен следовать правилам.
Когда результат известен, любой участник может предложить ответ и внести bond. Начинается challenge period. Если возражений нет, предложение подтверждается. Если ответ оспорен, проводится следующий раунд, а повторный спор передаётся в Data Verification Mechanism UMA для голосования держателей токена UMA.
В действующей документации стандартный бесспорный период составляет два часа, а типичный bond указывается около 750 pUSD. Эти параметры могут меняться для конкретного рынка и не являются обещанием постоянных условий. При эскалации обсуждение и голосование DVM растягивают разрешение на несколько дней.
Oracle не устанавливает рыночную цену до окончания события. Он отвечает только на сформулированный вопрос. Редкий ответ Unknown или равное разрешение приводит к погашению обоих токенов по половине залога. Это не возврат по цене покупки: трейдер мог войти выше или ниже 0,50.
Комиссии и maker rebates
В текущем V2 комиссии включены не для всех рынков и задаются по категориям. Maker не платит trading fee, taker fee зависит от цены доли и максимальна около середины диапазона вероятности. Собранные суммы финансируют maker rebates, которые стимулируют плотные котировки.
Историческое утверждение «Polymarket всегда без комиссий» больше неверно. Некоторые категории остаются без fee, а другие используют собственный rate. Перед сделкой нужно смотреть конфигурацию конкретного market object. Дополнительно возможны расходы стороннего onramp, bridge или сети, которые не являются комиссией Polymarket.
Ликвидность и формирование цены
Market makers выставляют две стороны и зарабатывают на spread, инвентарном управлении и rebate. Они рискуют информационным преимуществом taker: если новость уже появилась, медленная котировка будет исполнена первой. Чем ближе развязка, тем сильнее цена реагирует на новый факт.
Арбитраж поддерживает связи Yes плюс No и взаимно исключающих рынков, но не гарантирует мгновенной эффективности. Залог, лимиты, задержка перевода, риск oracle и стоимость капитала создают коридор. Цена может долго выглядеть нелогичной, если невозможно безопасно исполнить все legs.
Holding rewards и программы liquidity incentives существуют только для отмеченных рынков и меняются. Их нельзя считать базовой доходностью любого токена исхода. Reward может компенсировать часть opportunity cost, но не ошибочный прогноз или неудачное разрешение.
Токен и управление
У Polymarket нет публично задокументированного нативного governance token, который был бы обязательной частью CTF, торговли или resolution. Outcome tokens относятся к отдельным событиям и не являются долей платформы. pUSD – collateral, а не governance asset.
Слухи о возможном token, airdrop или будущей децентрализации нельзя смешивать с действующей системой. Пока параметры frontend, market creation, matching infrastructure и часть operational policy контролируются оператором платформы. UMA управляет собственным oracle layer, но не всей системой Polymarket.
История
Polymarket запущен в 2020 году как on-chain prediction market. Ранние версии использовали Polygon, CTF и USDC, а рост особенно ускорился на политических, макроэкономических и криптовалютных событиях. Формат вероятности сделал рынки удобным публичным индикатором, а книга заявок дала знакомый трейдерам способ исполнения.
В 2022 году компания урегулировала претензии CFTC в США относительно работы незарегистрированных event contracts и изменила доступ по юрисдикциям. Позднее регулирование, инфраструктура американского рынка и международная площадка развивались раздельно. Пользователь обязан проверять доступность для своей страны, а не обходить ограничения.
В 2024–2025 годах Polymarket стал заметным источником рыночных ожиданий во время выборов и крупных новостей. 2026 год принёс наиболее существенное техническое обновление – CLOB V2, pUSD, новые exchange contracts и изменённую fee model. Поэтому дата документации для этого проекта особенно важна.
Команда
Основатель и руководитель Polymarket – Shayne Coplan. Проект развивает компания с командами exchange infrastructure, markets, compliance, product и developer tooling. Публичная узнаваемость основателя не отменяет того, что существенные компоненты создаются внешними экосистемами.
CTF происходит из Gnosis, UMA обслуживает optimistic resolution, Polygon даёт execution layer, а market makers формируют котировки. Эти участники не подчиняются одному governance. Сбой или изменение одного слоя может затронуть рынок независимо от качества работы остальных.
Роли участников
- Traders. Покупают или продают исходы и принимают риск события, цены и ликвидности.
- Market makers. Поддерживают книгу, управляют inventory и могут получать rebates.
- Split и merge arbitrageurs. Создают и объединяют полные комплекты, выравнивая стоимость исходов.
- Market operator. Формирует рынки, правила, frontend и off-chain matching infrastructure.
- Proposers и disputers. Вносят bond и участвуют в optimistic resolution.
- UMA voters. Разрешают эскалированные споры через DVM.
- Builders. Используют API и SDK для аналитики, интерфейсов и торговых систем.
Практическое применение
Polymarket используют для выражения позиции на событие, хеджирования специфического риска и наблюдения за агрегированными ожиданиями. Исследователь может сравнить движение цены с опросами или новостями. Трейдер может закрыть позицию до разрешения, не дожидаясь погашения.
Prediction market не заменяет первичный источник. Он показывает цену, по которой ограниченный круг участников готов торговать при конкретных правилах. Для крупных решений полезно оценивать depth, spread, историю движения и формулировку, а не смотреть только крупную цифру вероятности.
Основные риски
- Формулировка. Разговорное понимание вопроса может отличаться от resolution rules.
- Oracle. Неверное предложение, спор или ошибочное голосование UMA способны изменить выплату.
- Ликвидность. Тонкая книга увеличивает spread, slippage и стоимость выхода.
- Централизация исполнения. Matching и доступность API зависят от off-chain operator.
- Смарт-контракты. Уязвимость CTF, exchange, pUSD или adapter угрожает залогу.
- Сеть. Сбой Polygon, RPC или relayer затрудняет settlement и redemption.
- Регулирование. Доступ и набор продуктов зависят от юрисдикции и могут измениться.
- Collateral. pUSD добавляет wrapper risk поверх базового USDC.
- Информационный риск. Цена может быть манипулируемой или просто ошибочной.
- Миграция. Использование контрактов и SDK CLOB V1 после перехода на V2 не работает.
Как проверять рынок перед сделкой
Сначала нужно прочитать полный вопрос, resolution source, end date и edge cases. Затем проверить, является ли рынок обычным или Negative Risk, какая collateral используется и включена ли fee. В книге важны доступный объём на каждом уровне и реальная цена исполнения всего ордера.
Для on-chain проверки нужны актуальные адреса V2 и Polygon. Участие в споре требует отдельного понимания Optimistic Oracle, а не только уверенности в событии. Сравнение с ценовыми oracle вроде Chainlink полезно концептуально: Chainlink обычно передаёт числовое значение, тогда как UMA разрешает сформулированное утверждение через стимулы и dispute.
Итог
Polymarket – не букмекерский баланс и не обычный AMM. Это система полностью обеспеченных outcome tokens, гибридного CLOB и optimistic resolution. CTF делает позиции on-chain, книга заявок обеспечивает гибкое ценообразование, а UMA определяет финальный ответ при споре.
Главная сила проекта – ликвидный рынок для информации. Главная сложность – многослойность доверия: правила, off-chain matcher, Polygon, pUSD, CTF и UMA. С 2026 года анализ должен опираться именно на CLOB V2. Старые инструкции с USDC.e и V1 описывают уже не действующую production architecture.
