Сайт рынка прогнозов — вход в систему с несколькими задачами. Интерфейс показывает рынок, торговая система сопоставляет заявки, контракты проводят расчёты и перемещение активов, а сервисы данных делают результат читаемым. Оракул предоставляет окончательный ответ через настроенную процедуру определения исхода.
Эти задачи выполняются в разных местах. Нажатие кнопки, принятие заявки и завершение расчётов по сделке — разные этапы. Их границы объясняют, почему рынок виден, но торговля недоступна, или почему завершённая транзакция появляется в портфеле с задержкой.
Это вторая статья серии «Как работают Polymarket и Kuest». Если цены и выплаты пока незнакомы, начните с того, что означает цена рынка прогнозов.
Четыре слоя, четыре обязанности
| Слой | Роль |
|---|---|
| Интерфейс | Показывать вопросы, правила и управление аккаунтом |
| Торговая система | Проверять заявки и находить совместимый спрос и предложение |
| Контракты | Обеспечивать правила активов и разрешений выбранного маршрута |
| Сервисы данных | Организовывать метаданные, балансы и активность для приложений |
Обзор API Polymarket отражает это разделение: Gamma помогает находить рынки, CLOB работает с заявками и текущим состоянием рынка, Data API — с активностью аккаунтов и рынков. WebSocket передаёт обновления, но не заменяет базовые правила расчётов.
Страница — не идентификатор позиции
Событие объединяет связанные рынки для отображения. Бинарный рынок задаёт конкретный вопрос с определяемым ответом и предлагает отдельные исходы YES и NO. Одно событие может содержать несколько рынков, поэтому адреса страницы недостаточно для указания заявки. См. модель рынков и событий Polymarket.
В Conditional Tokens Framework, или CTF, идентификатор вопроса обозначает входные данные определения исхода. Идентификатор условия выводится из адреса оракула, идентификатора вопроса и количества слотов исходов. Идентификатор позиции исхода зависит также от обеспечения и пути коллекции. Эти идентификаторы нельзя без проверки подменять друг другом.
Это схема группировки, а не формула хеширования. Перед чтением стакана или подачей заявки выберите точный рынок и исход.
Руководство Polymarket по данным блокчейна отличает эти способы построения CTF от идентификаторов Protocol V2. Совпадающий заголовок на другом сайте не доказывает совпадение актива.
Проследите одну заявку через систему
Сначала интерфейс находит рынок и получает идентификаторы исходов и торговые настройки. Клиент формирует заявку, а соответствующий подписант одобряет её условия. Подписание заявки и отправка транзакции в блокчейн — разные действия.
Подписанная инструкция поступает в центральный стакан лимитных заявок, или CLOB. Сервис проверяет допустимость и ищет совместимые заявки. Принятая заявка может остаться открытой, если немедленное исполнение невозможно. Сопоставление означает согласование сделки по правилам системы, но ещё не доказывает передачу активов.
Затем идут расчёты. Сервис исполнения отправляет транзакцию соответствующим контрактам в Polygon. Расчётный маршрут проверяет одобренную сделку и обновляет активы при успешном исполнении. Неудачная транзакция не становится успешной покупкой только потому, что API ранее сообщил о совпадении заявок.
Сплошные стрелки показывают путь инструкции к расчётам. Пунктир — возвращение записанных данных в интерфейс; он не перемещает обеспечение.
Polymarket описывает жизненный цикл заявки и отдельно предлагает интеграторам дождаться расчётов по исполнению, прежде чем проверять полученную позицию. Важны включение транзакции и необходимое подтверждение; одного идентификатора заявки недостаточно.
Наконец, индексаторы обрабатывают записанные изменения, а API отдаёт обновлённые представления. Теперь интерфейс может показать позицию и активность. Этим этапам нужны отдельные статусы вместо одного неоднозначного «успешно».
Контракты — несколько семейств, а не один блок
Система на CTF распределяет обязанности между несколькими семействами контрактов. Названия ниже обозначают роли; конкретные контракты и разрешения зависят от маршрута.
Это карта обязанностей. Она не означает, что каждая транзакция вызывает все пять семейств.
| Семейство | Роль |
|---|---|
| Кошельки, фабрики и инфраструктура обновления | Хранить активы и применять правила владения, подписания и реализации |
| CTF Exchange или торговый маршрут отрицательного риска | Проверять соответствующие сопоставленные заявки и проводить расчёты по ним |
| Conditional Tokens | Учитывать балансы исходов CTF и поддерживать разделение, объединение и погашение |
| Адаптеры оракула и маршруты определения исхода | Связывать принятый ответ с выплатой, записанной для условия |
| Поддержка комиссий, вознаграждений и эскроу | Выполнять дополнительные операции учёта, стимулирования или финансирования, если они настроены |
Расчёты и определение исхода отвечают на разные вопросы. Расчёты выясняют, может ли эта сделка переместить активы. Определение исхода — какую выплату подразумевают правила рынка. Текущая документация Polymarket по исходам отличает рынки на UMA от рынков роста и падения на Chainlink TWAP. Механизм сопоставления не определяет результат выбором цены сделки.
Версия имеет значение. Polymarket сейчас описывает системы позиций CTF и Protocol V2. Protocol V2 использует PositionManager, CTF — Conditional Tokens. В реестре контрактов перечислены разные расчётные компоненты. «Exchange V2» нельзя считать синонимом «Protocol V2»: всегда устанавливайте версию рынка, реестр активов и маршрут вместе.
Данные делают реестр удобным, но могут отставать
Индексатор превращает события контрактов в записи, доступные для запросов. API может объединять их с метаданными рынка, ценами или расчётами. Эти данные полезны приложению, но время их обновления может отличаться от квитанции транзакции или прямого потока заявок.
Руководство Polymarket по данным блокчейна описывает события переводов и исполнения сделок. Эти записи не содержат каждую внеблокчейновую заявку, остающуюся в стакане. Название «подграф стакана» тоже не превращает индексатор в актуальный стакан. Текущая котировка и историческое исполнение — разные записи.
Если портфель выглядит устаревшим, сравните время обновления с транзакцией и соответствующим реестром. Если котировка исчезла, исследуйте текущий стакан. Это разные проверки: обновление каталога не доказывает ни неисполненную заявку, ни пропавшие средства.
Ретранслятор помогает отправке, но не устраняет зависимости
Ретранслятор может отправлять поддерживаемые операции кошелька, например развёртывание или разрешения. Документация Polymarket по кошелькам описывает оплату таких действий другой стороной: аккаунту не нужен собственный нативный токен газа для этих вызовов. Газ всё равно расходуется, его оплачивают из другого источника.
У ретранслятора кошелька и сервисов сопоставления и расчётов разные задачи. Важны доступность, поддерживаемые вызовы и правила оплаты. Не предполагайте, что каждая сделка проходит через ретранслятор кошелька или что оплата третьей стороной доказывает что-либо о хранении, полномочиях обновления или правильности оракула.
Отличие Kuest: бренд меняется, маршрут может быть общим
Публичное руководство Kuest по архитектуре отделяет бренд и каталог оператора от общей торговой инфраструктуры. Операторы могут подбирать рынки для своей аудитории и пользоваться совместимыми общими сервисами исполнения.
Общее исполнение требует совпадения сервисов, сети и активов. Отдельный бренд не создаёт и не гарантирует ликвидность.
Два брендированных сайта с одинаковыми сервисами и активами Kuest могут показывать разные каталоги и обращаться к общим заявкам. Для оператора это означает повторное использование инфраструктуры исполнения при создании целенаправленного опыта для своей аудитории.
Оператор представляет рынок трейдерам, а маркетмейкер предоставляет торговый спрос и предложение через заявки. Эти роли участников отличаются от сервисов, сопоставляющих сделки и проводящих расчёты. Само создание рынка не даёт готовых контрагентов или исполнимого объёма.
Общие сервисы Kuest не объединяют её стакан со стаканом Polymarket, а зеркальный вопрос не делает балансы переносимыми между площадками.
Семейства контрактов выше объясняют обязанности, а не полный состав развёртывания. Перед запуском проверьте реальную сеть, адреса контрактов, опубликованный код, разрешения и поддерживаемую систему позиций. Аудит исходного проекта не охватывает автоматически другое развёртывание или собственные изменения.
Оператору полезна конкретная проверка: какие рыночные активы показывает сайт, какие сервисы принимают заявки, какие контракты проводят расчёты и насколько свежи показанные записи? Новый бренд должен делать эти ответы понятнее.
Хотите построить такой опыт для своей аудитории? Создайте собственный рынок прогнозов через пошаговую настройку Kuest.